feat: add OrcaRouter as a first-class provider

[nissrin2020ali-ux]

Summary

LeanCTX describes itself as an AI Value Gate for AI coding agents — it sits on the wire path between your agent and the model, compressing and metering every request. It is model-agnostic ("swap OpenAI/Anthropic/Gemini freely"), and its universal provider registry already treats OpenAI-compatible gateways such as OpenRouter as first-class citizens.

This PR adds OrcaRouter the same way: as a named provider that mirrors the existing OpenRouter wiring, rather than something a user has to bolt on as an anonymous custom base URL.

OrcaRouter is an OpenAI-compatible AI gateway built for both models and agents. Like OpenRouter, it exposes a provider/model namespace across many models — but it also combines adaptive routing, automatic failover, zero-markup inference, observability, guardrails, and agent-tool governance behind the same endpoint. Adding orcarouter as a first-class provider means lean-ctx users can use that stack directly, without treating OrcaRouter as an anonymous custom base URL. It also runs gateway-level, zero-trust security for AI agents on the same endpoint — screening every prompt/response and governing every tool call on a default-deny basis, with no application code changes.

Parallel to the existing OpenRouter wiring

Every change below is the OrcaRouter twin of an existing OpenRouter branch:

File	OpenRouter (existing)	OrcaRouter (this PR)
rust/src/core/llm_enhance.rs	LlmBackend::OpenRouter → base URL https://openrouter.ai/api, OPENROUTER_API_KEY, OpenAI chat-completions path	LlmBackend::OrcaRouter → base URL https://api.orcarouter.ai, ORCAROUTER_API_KEY, same call_openai_compatible path
rust/src/core/context_kernel/token_envelope.rs	ProviderKind::OpenRouter	ProviderKind::OrcaRouter + parse_provider entry
rust/src/core/context_kernel/provider_parity.rs	URL detect openrouter.ai, OpenAI-dialect usage mapping, display name "OpenRouter"	URL detect orcarouter.ai, same OpenAI-dialect mapping (incl. usage.cost), display name "OrcaRouter"
rust/src/core/context_kernel/provider_normalization.rs	canonical_provider("openrouter") → OpenAI shape, keeps provider label	canonical_provider("orcarouter") → same
rust/src/proxy/usage_parity.rs	label containing "openrouter" → ProviderKind::OpenRouter	label containing "orcarouter" → ProviderKind::OrcaRouter
rust/src/core/config/schema/sections_advanced.rs	llm.backend enum includes openrouter	enum includes orcarouter
docs/reference/generated/config-keys.md	backend enum + api-key description	synced (generated reference)

Test plan

• cd rust && cargo fmt --check — passed
• cd rust && cargo test -- --test-threads=1 — not runnable in this container (no C toolchain / cargo network unavailable); CI will run the full suite
• cd rust && cargo clippy --all-targets --all-features -- -D warnings — same environment limitation
• Live API check against OrcaRouter with the real gateway key:
  • GET /v1/models → 200 (models listed in vendor/model form, e.g. anthropic/claude-fable-5, orcarouter/auto)
  • POST /v1/chat/completions → 200, OpenAI-shaped response whose usage carries cost, cost_details, prompt_tokens_details.cached_tokens and cache_write_tokens — exactly the OpenRouter usage dialect the lean-ctx OpenAI absorbers already parse

Notes for reviewers

• Risk areas / edge cases: none beyond the mirrored OpenRouter branches; usage.include opt-in injection stays OpenRouter-only (OrcaRouter already reports billed usage.cost without it).
• Backwards compatibility: additive only — new enum variants, new config enum value, no existing behavior changes. Existing stored ProviderKind values deserialize unchanged.
• Docs updated: docs/reference/generated/config-keys.md synced with the schema change.

Contributor License Agreement

I have read the CLA Document and I hereby sign the CLA.

---

I'm an engineer on the OrcaRouter team.

Discord: discord.gg/YEubt8enRA · X: https://x.com/OrcaRouter

[github-actions]

👋 Thanks for the contribution — we would love to merge it!

One one-time step remains: please sign our CLA. It takes ~5 seconds, you sign once, and every future PR is then accepted automatically. The CLA keeps lean-ctx Apache-2.0 and free for individual developers (guaranteed in §8) while still allowing a hosted/commercial plane.

To sign: reply to this PR with a comment containing exactly:

I have read the CLA Document and I hereby sign the CLA

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}

[yvgude]

Thanks for the work — the patch itself is clean, and I checked it properly: no new dependencies, no build script, no workflow changes, the default backend stays ollama, the key comes from its own ORCAROUTER_API_KEY and no other provider's credentials are read. Your compatibility note is also correct: ProviderKind never goes through postcard, so inserting a variant mid-enum is safe, and all three match sites plus the SUPPORTED array are updated.

I'm closing it anyway, for two reasons that aren't about code quality.

It doesn't add a capability. LlmConfig::effective_base_url() returns self.base_url whenever it is set, so anyone can point lean-ctx at OrcaRouter today with llm.base_url = "https://api.orcarouter.ai" and llm.backend = "openrouter". What this PR adds is a brand name in the config enum, the schema, and the generated reference — not new reach.

Named providers are an editorial commitment. Listing a gateway next to OpenAI, Anthropic and Gemini tells users we vouch for it. The bar for that is a track record I can verify independently, and OrcaRouter doesn't have one yet — the domain and the account opening this PR are both days old. That's a "not yet", not a judgement about the service.

If OrcaRouter picks up real adoption among lean-ctx users, this is an easy PR to revive — the wiring is right.

One note that may be useful to you regardless: llm.api_key is documented as the key for the OpenRouter/Anthropic backends, but nothing reads it — api_key() only consults environment variables. That's a pre-existing bug on our side, not something you introduced; I'm tracking it separately.