[Feature] Make CopilotKit Intelligence optional for self-hosted deployments

[baksha97]

What outcome should OpenMuse handle?

I'd like to self-host OpenMuse with my own model provider and local conversation storage, without requiring hosted Intelligence or a commercial self-hosted Intelligence license.

The README introduction makes Rich Threads sound optional, but the current implementation requires CPK_INTELLIGENCE_API_KEY at startup.

References:

• PR #15 required Intelligence for live deployments.
• PR #38 extended that requirement to every mode and removed the branches that skipped Intelligence.
• config.ts:108 requires the key unconditionally.
• app.ts still contains local /api/conversation GET/PUT endpoints, and chat.tsx retains a local-history path. I have not verified that these work without Intelligence.

Proposed behavior

Would you support an explicit local-persistence mode? A single saved conversation would be enough initially; Intelligence-specific thread management could remain disabled.

The mode should start without an Intelligence key and use a separately configured model provider. Authentication, token encryption, action approvals, browser tools, and background tasks should retain their existing behavior.

When Intelligence is selected, its existing behavior should remain, including errors rather than silently falling back to local storage.

If Intelligence is intentionally mandatory, could the README explain why local-only operation was removed and distinguish self-hosting OpenMuse from self-hosting its required persistence service?

How would we verify it works?

• Start without an Intelligence key and confirm no Intelligence requests are made.
• Complete a conversation using a separately configured model provider.
• Preserve history across server restarts and web/iOS client reloads, without silent overwrites between clients.
• Verify authentication, token encryption, action approvals, browser tools, and background tasks remain functional.
• Confirm existing Intelligence thread operations still work when that mode is selected.

Source inspection is based on commit 205cc386b75aae1a862f3fdd43104b570c8d0911; no local-only deployment was tested.

[jose-dias-fernandes]

+1 on this. I'm interested in using OpenMuse, but only if it can run fully locally, with conversation data kept on my own infrastructure. I'd be glad to help implement it if the maintainers want it.

I looked at what the runtime already supports (@copilotkit/runtime 1.70.1, the version pinned on main):

• CopilotRuntime accepts a runner?: AgentRunner in place of intelligence. AgentRunner and InMemoryAgentRunner are public exports of @copilotkit/runtime/v2.
• A runner that implements the local thread endpoint contract (supportsLocalThreadEndpoints) makes the runtime serve thread list and inspect itself (handlers/get-runtime-info). Thread mutations (rename/archive/restore) and realtime metadata remain Intelligence-only, so the conversation menu would need to hide those actions in a local mode.
• The contract is marked ɵ, so I'd treat it as semi-internal. Would you prefer depending on it, or keeping local mode to a single main conversation that doesn't use it at all?

A possible scope, keeping Intelligence the default:

1. An explicit THREADS_BACKEND=intelligence|local (default intelligence). With intelligence, behavior is unchanged: missing or failing Intelligence still errors, never a silent fallback to local.
2. With local, an AgentRunner that persists runs in the existing database (PGlite locally, Postgres via DATABASE_URL), scoped to the owner. First step: one main conversation, as suggested above; menu actions that local mode can't support are hidden rather than faked.
3. The demo entry (apps/server/src/demo/entry.ts) follows the same setting.
4. Tests for outcomes, reusing the verification list in this issue: start without a key and make no Intelligence requests; history survives an API restart and client reloads; approvals, browser tools and background tasks behave the same; Intelligence mode still passes its existing tests.

Questions before any code:

1. Is a local mode something you'd accept upstream, given feat: require CopilotKit Intelligence in every mode #38 made Intelligence required in every mode? If it's intentionally mandatory, a README note explaining why would already help.
2. If yes, is a single main conversation enough for a first PR, with multi-thread local support as a follow-up?
3. Any preference on the setting name or on where local persistence should live?

Happy to open a PR once there's agreement on scope.