3 ms·

Good question. Linggen itself always runs locally. When using Claude Desktop, it connects to Linggen via a local MCP server (localhost), so indexing and memory

by linggen 10mo ago

Good question. Linggen itself always runs locally. When using Claude Desktop, it connects to Linggen via a local MCP server (localhost), so indexing and memory stay on-device. The LLM can query that local context, but Linggen doesn’t push your data to the cloud. Claude’s web UI doesn’t support local MCP today — if it ever does, it would just be a localhost URL.

ithkuil 10mo ago
Of course, parts of the context (as decided by the MCP server, based on the context, no pun intended) are returned to claude which processes them on their servers.
- linggen 10mo ago
  Yes, that’s correct — the model only sees the retrieved slices that the MCP server explicitly returns, similar to pasting selected context into a prompt. The distinction I’m trying to make is that Linggen itself doesn’t sync or store project data in the cloud; retrieval and indexing stay local, and exposure to the LLM is scoped and intentional.
  - Y_Y 10mo ago
    That's fine, but it's a very different claim to the one you made at first. In particular, I don't know which parts of my data might get sent to Claude, so even if I hope it's only a small fraction, anything could in principle be transmitted.
    - linggen 10mo ago
      That’s true — Linggen can’t control the behavior of Claude or any other cloud LLM. What it can control is the retrieval boundary: what gets selected locally and exposed to the model. If nothing is returned, nothing is sent. If a strict zero-exfiltration setup is required, then a fully local model would indeed be the right option.
    - linggen 10mo ago
      I do have a local model path (Qwen3-4B) for testing. The tradeoff is simply model quality vs locality, which is why Linggen focuses on controlling retrieval rather than claiming zero data ever leaves the device. Using a local LLM is straightforward if that’s the requirement.

by linggen 10mo ago

ithkuil 10mo ago

Of course, parts of the context (as decided by the MCP server, based on the context, no pun intended) are returned to claude which processes them on their servers.

linggen 10mo ago
Yes, that’s correct — the model only sees the retrieved slices that the MCP server explicitly returns, similar to pasting selected context into a prompt. The distinction I’m trying to make is that Linggen itself doesn’t sync or store project data in the cloud; retrieval and indexing stay local, and exposure to the LLM is scoped and intentional.
- Y_Y 10mo ago
  That's fine, but it's a very different claim to the one you made at first. In particular, I don't know which parts of my data might get sent to Claude, so even if I hope it's only a small fraction, anything could in principle be transmitted.
  - linggen 10mo ago
    That’s true — Linggen can’t control the behavior of Claude or any other cloud LLM. What it can control is the retrieval boundary: what gets selected locally and exposed to the model. If nothing is returned, nothing is sent. If a strict zero-exfiltration setup is required, then a fully local model would indeed be the right option.
  - linggen 10mo ago
    I do have a local model path (Qwen3-4B) for testing. The tradeoff is simply model quality vs locality, which is why Linggen focuses on controlling retrieval rather than claiming zero data ever leaves the device. Using a local LLM is straightforward if that’s the requirement.