Known Issues

Real limitations found through real testing, not a generic disclaimer

Two things worth knowing about before you run into them, both specific to running a small model fully on-device rather than a symptom of anything actually broken in LocalLM Lab itself. Neither is fixed by adding server-side workarounds that quietly rewrite what the model sees or says — that would break the raw in, raw out design this app is built around.

📉 Enabling many connectors/MCP tools at once can exhaust the context window

Guideline available

Apple's on-device model has a small context window (4096 tokens). Every connector and MCP tool you enable adds its schema to that budget before the model has even seen your prompt — with several connectors and a few MCP servers all turned on simultaneously, the schemas alone can consume nearly the entire budget, leaving almost no room for a real answer. When that happens, a request fails outright with a context-window error rather than degrading gracefully.

Guideline: enable only what a given task actually needs. A handful of connectors work reliably together; turning on everything at once (every connector plus several MCP servers) is the scenario most likely to hit this ceiling. If a request fails with a context-window error, the fix is almost always to disable connectors or MCP tools you're not using for that particular prompt, in Local AI Settings — not to shorten your prompt, since the schemas are usually the larger share of the budget, not your own words.

👤 Updating a Contact can occasionally set an unrequested field

Mitigated, not eliminated

When asked to change one specific field on an existing contact (e.g. "update the organization"), the model can occasionally also set a different field to a copied value it was never asked to change — observed live, it copied the new organization into the contact's family name field on one run. This only affects updateContact (Full Access required), and only sometimes; most update requests behave correctly.

The tool's description already tells the model explicitly not to do this — "each new* field is independently optional... never copy a value from one field into another" — and that measurably reduces how often it happens, but a small on-device model doesn't follow instructions with perfect reliability, and no guardrail on our side can catch this without filtering what the model actually writes, which we've deliberately chosen not to do. If you use Contacts' Full Access write capability, it's worth glancing at the result rather than assuming only the field you asked about changed.

Contact

Run into something not listed here? Contact neuron@thisbrain.ai or join our Discord.