Lynkr: an HTTP proxy that compresses tool output and routes Claude Code traffic by task complexity
Streamline your workflow with Lynkr, a CLI tool that acts as an HTTP proxy for efficient code interactions using Claude Code CLI.
At a glance
- What is it?
- Lynkr sits between an AI coding tool and its model provider, trimming tool payloads and picking a tier per request. The README's headline numbers come from the project's own benchmark, so the interesting question is what the proxy actually does and where it stops being worth the hop.
- Who is it for?
- Lynkr is worth trying if you already run Ollama or hold a Claude Pro/Max subscription and want simple requests to stop consuming it, and the fastest way to find out is lynkr init followed by lynkr wrap claude. It is the wrong tool if you need a gateway whose routing you can explain to an auditor, or if your traffic is mostly long reasoning turns with little tool output, where the compression path has nothing to bite on.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Lynkr targets: raw tokens and one provider per tool
AI coding assistants send every token to one provider. A grep result, a file read, a test log and a tool schema all travel at full size, and the model that answers a one-line question is the same model that answers a refactor. Lynkr is a local HTTP proxy that intercepts that traffic and changes both halves. The README states the framing directly: AI coding tools lock you into one provider and send every token raw, and Lynkr breaks both locks. The audience is developers running Claude Code, Cursor, Codex, Cline or Continue who either pay per token or hold a subscription with a usage ceiling. The pitch is that no application code changes, only the base URL the tool points at. That is a narrow, concrete claim and it is the reason the project exists rather than being another model abstraction library.
What happens to a request between the tool and the provider
The README's diagram lists five stages in order: strip unused tools, compress JSON blobs, semantic cache, route by complexity, learn from outcomes. A tool call arrives at the proxy, unused tool definitions are removed from the payload, large JSON tool results are compressed, and repeated queries are served from a semantic cache the README describes as returning in under 300ms with zero tokens billed. If the request is not cached, a tier decision is made. The routing layer is described as kNN plus a bandit with auto-calibration, and the README says tier thresholds re-calibrate nightly from your own traffic. Sessions stick to one model until the task outgrows it, using content fingerprinting, with escalation on demand. The output side then goes to one of the configured providers. The compression claims are specific: 84% fewer tokens on JSON tool results, 53% on tool-heavy requests. The README attributes both to a bundled benchmark against LiteLLM on identical free local backends and tells you to run node benchmark-tier-routing.js yourself, which is the honest way to present a self-reported number.
Wrap mode is the part that matters for subscription users
The most consequential feature is not the proxy itself but lynkr wrap claude. Instead of pointing an editor at the proxy by hand, wrap mode puts Lynkr in front of an existing AI coding tool so that tier routing and compression apply to sessions you already run. The README lists what wrapping gives you: tier routing that sends simple tasks to free Ollama and complex ones to your subscription or API, sticky sessions with automatic escalation, TOON/RTK compression, semantic caching, and the claim that your subscription is used only where it counts. It supports OAuth providers (Claude, Copilot, Cursor) and API keys (Aider, Codex). The trade-off is implicit in the design: sticky sessions mean one routing decision per conversation, so a session that starts simple and becomes hard escalates rather than re-routing every turn. That reduces churn and cost, and it also means the first decision carries weight for the whole conversation.
Getting it running: install, wizard, and the two connection paths
Installation is npm install -g lynkr, which the README notes requires Node 20 or later. The recommended configuration path is lynkr init, an interactive wizard that asks four questions: usage mode (Claude Pro/Max via wrap, or direct API keys), tier picks for SIMPLE, MEDIUM, COMPLEX and REASONING across the supported providers, credentials for what you chose, and routing-intelligence knobs. It then writes a populated .env with defaults for caching, compression, policy budgets, the MCP sandbox and rate limiting. lynkr init --force overwrites an existing .env. Manual configuration is still supported by copying .env.example. For a free local setup the README gives ollama pull qwen2.5-coder:latest, then lynkr start. Connecting a tool is a base URL change: Cursor takes http://localhost:8081/v1 under Settings, Models, Override Base URL with any API key value, and Codex CLI takes a model_provider block in ~/.codex/config.toml pointing base_url at the same address with wire_api set to responses. Tier keys look like TIER_SIMPLE=ollama:qwen2.5-coder:latest, repeated for each tier. Health is a single curl http://localhost:8081/ returning a JSON object with service, version and status fields.
Failure modes the README itself documents
The troubleshooting section is unusually candid and worth reading as a list of things that break. Running a version older than 9.3.0 produces an error about being unable to determine a transport target for pino-pretty; the fix is upgrading or setting NODE_ENV=production. A missing tier configuration emits a warning that the README explicitly says you can ignore, because tier routing is optional. Enabling a fallback provider without credentials produces a warning naming databricks, resolved by setting FALLBACK_ENABLED=false. If Ollama is not running, requests fail with ECONNREFUSED on port 11434, fixed by ollama serve in a separate terminal. A connection refused or 404 from the tool usually means Lynkr is not running or is on another port. The larger structural limitation is not in that list: everything depends on the proxy being up and on the tier configuration being sane. A misconfigured tier sends work to a model that cannot do it, and the README's own warning about missing tier configuration suggests that state is common enough to deserve a dedicated message. Anyone whose tolerance for a local daemon in the request path is low should weigh that before adopting.
LiteLLM and the difference in approach
The comparison the project makes is with LiteLLM, and the README is specific about the setup: the bundled benchmark runs against LiteLLM on identical free local backends, and MODE=routing runs a routing-only head-to-head that judges both proxies on the same acceptable-tier sets, including LiteLLM's Auto Router v2. The architectural difference is where the optimisation lives. LiteLLM is a provider-normalisation and routing layer: it presents many backends behind one interface and lets you define fallbacks and budgets. Lynkr adds a payload stage in front of that, stripping unused tool definitions and compressing JSON tool results before the request leaves your machine, and it keeps a learning loop that adjusts tier thresholds from observed outcomes. If your cost problem is provider sprawl and key management, LiteLLM addresses it directly. If your cost problem is that tool output is enormous and most requests are easy, Lynkr's compression and tiering are aimed at that instead. They are not mutually exclusive, but running both means two hops and two configuration surfaces.
Maintenance, release cadence and what the licence permits
The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved, and it includes an explicit patent grant. That is a permissive choice with no copyleft obligation on your own code. It is not legal advice; if you redistribute Lynkr inside a product, read the NOTICE and licence text. On maintenance, the release history is uneven and worth noting. The most recent release in the supplied material is v9.6.0, dated 2026-06-23 and titled Routing resilience and output quality. The release before it is 0.1.0, a Windows release dated 2025-12-04. The last push to the default branch is 2026-09-09, so the repository is active, but the jump from 0.1.0 to 9.6.0 in about six months, with only two releases listed, suggests a versioning scheme that does not map cleanly onto a public changelog. Anyone pinning a version should read the release notes for 9.6.0 rather than assuming the numbering implies a long stable series. Upgrading is an npm global install, which means the .env you configured survives but the defaults the wizard writes may change between versions.
What to check before you point your editor at it
The README leans on a third-party benchmark hosted at RouterArena, an ICLR 2026 evaluation the project says covers 8,400 queries, with results of 67.65 arena score, 68.41% accuracy at $0.29 per 1K queries and 92.38 robustness, positioned above GPT-5's built-in router and NotDiamond. Those are the project's characterisation of someone else's numbers, and the README links methodology and caveats in docs/routerarena-benchmark.md. Read that document before treating the figures as settled, and treat the bundled benchmark the same way: node benchmark-tier-routing.js is described as a 19-scenario routing regression harness with 12 of 12 correctness checks currently passing, which is a small sample for a routing claim. The practical verification is cheaper anyway. Run lynkr init, inspect the .env it writes, start the proxy, curl http://localhost:8081/ to confirm it is alive, then send one real session through lynkr wrap claude and compare token counts against a session without it. If the compression path never fires because your work is mostly long reasoning with little tool output, the hop is cost without benefit.
Editorial conclusion
Lynkr is worth trying if you already run Ollama or hold a Claude Pro/Max subscription and want simple requests to stop consuming it, and the fastest way to find out is lynkr init followed by lynkr wrap claude. It is the wrong tool if you need a gateway whose routing you can explain to an auditor, or if your traffic is mostly long reasoning turns with little tool output, where the compression path has nothing to bite on. Before committing, check the .env the wizard writes, confirm FALLBACK_ENABLED matches credentials you actually hold, and run node benchmark-tier-routing.js yourself, because the 84% and 53% figures are the project's own and the README says so.
Community notes