[linggen]

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]

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]

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]

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]

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]

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.