Appreciation
Lynkr takes a problem every Claude Code or Cursor user feels but few tools attack directly: the harness locks you to one provider and ships every token raw. What stands out is that the fix is a drop-in HTTP proxy with zero code changes — point Cursor's base URL or Codex's model_providers.lynkr at localhost:8081/v1 and you get tier routing keyed off TIER_SIMPLE/TIER_COMPLEX, sticky content-fingerprint sessions, and TOON compression on large JSON tool output.
For the developers this serves, that matters because it turns "which model am I paying for" into a routing decision instead of a rewrite. Your stated 84% token reduction on JSON tool results and sub-300ms semantic cache hits are exactly the levers that make a Claude Code session affordable to run all day.
Proposal: add OrcaRouter as an optional provider
I'd like to propose OrcaRouter as an additional, entirely optional provider. It would not replace or alter any existing provider — Ollama, OpenRouter, Bedrock, Databricks, Atlas Cloud and the rest stay exactly as they are. This is a request for maintainer feedback, not a claim of finished work.
A few capabilities that line up with Lynkr's users specifically:
- Multiple chat, reasoning, image, and video models behind one endpoint, so tier targets like
TIER_REASONING can reach a broader model set without a new adapter per vendor.
- Automatic model routing and provider failover, which complements (and stays independent of) Lynkr's own complexity router and its
FALLBACK_PROVIDER ladder.
- Prompt caching, relevant to Lynkr's existing
PROMPT_CACHE_ENABLED work and its cache-aware routing economics.
- Usage tracking and budgets, useful alongside your telemetry store, dashboard spend view, and
POLICY_MAX_* knobs.
Integration surface: OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. That matches a shape Lynkr already supports — OPENROUTER_ENDPOINT=https://openrouter.ai/api/v1/chat/completions with OPENROUTER_API_KEY/OPENROUTER_MODEL, the per-provider adapter modules under src/clients/ (e.g. openrouter-utils.js), and the existing OpenAI-format-to-Anthropic SSE transform path. A new provider entry plus an adapter following that convention is the expected touch point. Nothing here is implemented or tested yet.
OrcaRouter is already in the open-source ecosystem — for example RAGFlow, Dify, goose, promptfoo, DB-GPT, and CAMEL have related integrations.
Transparency: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from usage attributed to their integration. Participating is not a prerequisite for an integration, and I'm happy to follow Lynkr's disclosure and governance expectations either way.
More detail: https://www.orcarouter.ai/built-with
I'm an engineer on the OrcaRouter team. If this is a direction you'd consider, I'd welcome your take on the right shape and would be glad to open an implementation PR once you're comfortable with it.
Appreciation
Lynkr takes a problem every Claude Code or Cursor user feels but few tools attack directly: the harness locks you to one provider and ships every token raw. What stands out is that the fix is a drop-in HTTP proxy with zero code changes — point Cursor's base URL or Codex's
model_providers.lynkratlocalhost:8081/v1and you get tier routing keyed offTIER_SIMPLE/TIER_COMPLEX, sticky content-fingerprint sessions, and TOON compression on large JSON tool output.For the developers this serves, that matters because it turns "which model am I paying for" into a routing decision instead of a rewrite. Your stated 84% token reduction on JSON tool results and sub-300ms semantic cache hits are exactly the levers that make a Claude Code session affordable to run all day.
Proposal: add OrcaRouter as an optional provider
I'd like to propose OrcaRouter as an additional, entirely optional provider. It would not replace or alter any existing provider — Ollama, OpenRouter, Bedrock, Databricks, Atlas Cloud and the rest stay exactly as they are. This is a request for maintainer feedback, not a claim of finished work.
A few capabilities that line up with Lynkr's users specifically:
TIER_REASONINGcan reach a broader model set without a new adapter per vendor.FALLBACK_PROVIDERladder.PROMPT_CACHE_ENABLEDwork and its cache-aware routing economics.POLICY_MAX_*knobs.Integration surface: OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. That matches a shape Lynkr already supports —
OPENROUTER_ENDPOINT=https://openrouter.ai/api/v1/chat/completionswithOPENROUTER_API_KEY/OPENROUTER_MODEL, the per-provider adapter modules undersrc/clients/(e.g.openrouter-utils.js), and the existing OpenAI-format-to-Anthropic SSE transform path. A new provider entry plus an adapter following that convention is the expected touch point. Nothing here is implemented or tested yet.OrcaRouter is already in the open-source ecosystem — for example RAGFlow, Dify, goose, promptfoo, DB-GPT, and CAMEL have related integrations.
Transparency: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from usage attributed to their integration. Participating is not a prerequisite for an integration, and I'm happy to follow Lynkr's disclosure and governance expectations either way.
More detail: https://www.orcarouter.ai/built-with
I'm an engineer on the OrcaRouter team. If this is a direction you'd consider, I'd welcome your take on the right shape and would be glad to open an implementation PR once you're comfortable with it.