Kanna is a polished web UI for the Claude Code and Codex CLIs, and it is the clearest attempt I have seen at treating terminal coding agents as a first-class, project-oriented workspace. Auto-discovering projects from local Claude and Codex history, grouping chats under projects with live status indicators, and resuming sessions with full context make the daily loop of juggling several agent sessions far more manageable.
Kanna's ProviderCatalog and Model Registry already put provider choice at the center of the experience, and the bundled Pi agent can point at OpenRouter, OpenAI, or any custom OpenAI-compatible endpoint. That makes Kanna a natural home for more model options: users already switch providers from the chat input, so a new endpoint fits the existing mental model.
I'd like to propose adding OrcaRouter as an optional provider for Kanna. I'm an engineer on the OrcaRouter team, and I want to be transparent about that. OrcaRouter would complement the existing Claude, Codex, Cursor, and Pi providers rather than replace or alter any of them: no one would see it unless they add an OrcaRouter API key in settings.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. On the Kanna side, the expected integration point is the existing provider/endpoint abstraction, the same Model Registry surface that already lets the bundled Pi agent target any custom OpenAI-compatible endpoint. This is a proposal, not finished work: nothing is implemented or tested yet.
A few OrcaRouter capabilities are especially relevant to Kanna users:
- Many models through one endpoint: a single key can expose Claude, OpenAI, Google, and other chat and reasoning model families through the existing model picker, with no per-provider setup.
- Usage tracking and budgets: visibility into spend across the models used from the UI, useful for developers who want to keep an eye on cost.
- Automatic routing and provider failover: a complement to Kanna's own fallback-style behavior (for example, quick structured queries) when a particular model is unavailable.
OrcaRouter is already showing up in the open-source ecosystem, with promptfoo, OpenCode (models.dev), and goose among the projects that have integrations, suggesting this provider pattern fits developer-facing tools like Kanna.
One disclosure: OrcaRouter runs an optional open-source partner program under which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a precondition for adding the provider, and I am happy to follow whatever disclosure or governance requirements the project prefers. More context is at https://www.orcarouter.ai/built-with.
I'd welcome your thoughts on whether this fits Kanna's direction. If maintainers are open to it, I would be glad to submit an implementation PR following the project's conventions.
Kanna is a polished web UI for the Claude Code and Codex CLIs, and it is the clearest attempt I have seen at treating terminal coding agents as a first-class, project-oriented workspace. Auto-discovering projects from local Claude and Codex history, grouping chats under projects with live status indicators, and resuming sessions with full context make the daily loop of juggling several agent sessions far more manageable.
Kanna's ProviderCatalog and Model Registry already put provider choice at the center of the experience, and the bundled Pi agent can point at OpenRouter, OpenAI, or any custom OpenAI-compatible endpoint. That makes Kanna a natural home for more model options: users already switch providers from the chat input, so a new endpoint fits the existing mental model.
I'd like to propose adding OrcaRouter as an optional provider for Kanna. I'm an engineer on the OrcaRouter team, and I want to be transparent about that. OrcaRouter would complement the existing Claude, Codex, Cursor, and Pi providers rather than replace or alter any of them: no one would see it unless they add an OrcaRouter API key in settings.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. On the Kanna side, the expected integration point is the existing provider/endpoint abstraction, the same Model Registry surface that already lets the bundled Pi agent target any custom OpenAI-compatible endpoint. This is a proposal, not finished work: nothing is implemented or tested yet.
A few OrcaRouter capabilities are especially relevant to Kanna users:
OrcaRouter is already showing up in the open-source ecosystem, with promptfoo, OpenCode (models.dev), and goose among the projects that have integrations, suggesting this provider pattern fits developer-facing tools like Kanna.
One disclosure: OrcaRouter runs an optional open-source partner program under which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a precondition for adding the provider, and I am happy to follow whatever disclosure or governance requirements the project prefers. More context is at https://www.orcarouter.ai/built-with.
I'd welcome your thoughts on whether this fits Kanna's direction. If maintainers are open to it, I would be glad to submit an implementation PR following the project's conventions.