DEV Community: Lynkr

How to Configure LibreChat with Lynkr Using a Custom OpenAI-Compatible Endpoint

Lynkr — Tue, 16 Jun 2026 05:02:25 +0000

How to Configure LibreChat with Lynkr Using a Custom OpenAI-Compatible Endpoint

LibreChat is one of the best open-source AI chat and agent surfaces for teams that want self-hosting, MCP support, flexible model backends, and a real product surface instead of a demo UI.

Lynkr is an open-source LLM gateway built for coding assistants, agents, and MCP-heavy workflows. It gives you one OpenAI-compatible endpoint in front of multiple providers, with routing, caching, and cleaner model infrastructure behind it.

Put together, they make a clean split:

LibreChat handles the app layer: chat UI, agents, files, MCP, user workflows
Lynkr handles the gateway layer: routing, provider switching, fallback, caching, and model control

That is why this pairing works so well. LibreChat already supports custom OpenAI-compatible endpoints, and Lynkr is a strong fit for the kind of multi-provider, tool-using, agentic traffic LibreChat users actually generate.

This article is the practical follow-up to the architecture case: the goal here is to get LibreChat talking to Lynkr with a minimal working setup.

I built Lynkr, so founder disclosure applies. I’m keeping this grounded to what LibreChat and Lynkr support today.

Why Lynkr fits LibreChat especially well

There are plenty of tools that can sit between an app and a model provider, but Lynkr is a particularly strong fit for LibreChat for a few reasons:

OpenAI-compatible endpoint: LibreChat already has a clean seam for custom OpenAI-compatible APIs, which makes Lynkr easy to drop in underneath it
Built for agentic traffic: LibreChat is not just plain chat. It supports agents, MCP, tools, and more complex request patterns. Lynkr is designed for those heavier workflows, not just one-shot completions
Routing + caching in one place: if you want LibreChat to stay clean at the product layer while the backend evolves, Lynkr gives you a better home for that logic
Provider portability: you can keep LibreChat stable while moving between Ollama, OpenRouter, Bedrock, OpenAI, and others behind the gateway
Good fit for MCP and coding workflows: Lynkr was built around the kind of traffic these users actually generate

That means this setup is not just “put any proxy in front of LibreChat.” It is specifically about using a gateway that matches the workload.

What you need

Before starting, you need:

a running LibreChat instance
Node.js 20+ for Lynkr
at least one backend provider configured in Lynkr
one LibreChat endpoint that points to Lynkr instead of directly to a provider

Repo references:

LibreChat: github.com/danny-avila/LibreChat
Lynkr: github.com/Fast-Editor/Lynkr

Two details matter here:

LibreChat explicitly supports custom OpenAI-compatible APIs
Lynkr exposes an OpenAI-compatible /v1 endpoint

That’s the seam we’re using.

The target architecture

The setup we want looks like this:

Browser
  ↓
LibreChat
  ↓
Lynkr (OpenAI-compatible endpoint)
  ↓
OpenAI / Bedrock / OpenRouter / Ollama / Anthropic-compatible backends / others

In other words:

LibreChat owns the chat UI, agents, MCP, files, and workflows
Lynkr owns routing, caching, and model-side control

Step 1: Install and start Lynkr

Install Lynkr globally:

npm install -g lynkr

Now create a minimal .env for Lynkr.

Example A: local testing with Ollama

MODEL_PROVIDER=ollama
OLLAMA_ENDPOINT=http://localhost:11434
OLLAMA_MODEL=qwen2.5-coder:latest
FALLBACK_ENABLED=false
PORT=8081
PROMPT_CACHE_ENABLED=true
SEMANTIC_CACHE_ENABLED=true

Then start Lynkr:

lynkr start

Example B: cloud setup with OpenRouter

MODEL_PROVIDER=openrouter
OPENROUTER_API_KEY=your_openrouter_key
FALLBACK_ENABLED=false
PORT=8081
PROMPT_CACHE_ENABLED=true
SEMANTIC_CACHE_ENABLED=true

Then start it:

lynkr start

Optional direct smoke test against Lynkr

Before touching LibreChat, you can test Lynkr directly with a simple OpenAI-compatible request:

curl http://localhost:8081/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer dummy-key" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role": "user", "content": "Say hello in one sentence."}]
  }'

If that succeeds, the gateway path is working before LibreChat is added on top.

Quick health check

Once Lynkr is running, verify the endpoint responds:

curl http://localhost:8081/

You should get a JSON response showing the service is running.

At this point, Lynkr should expose an OpenAI-compatible base URL at:

http://localhost:8081/v1

That is the URL LibreChat should talk to.

Step 2: Decide how LibreChat should see Lynkr

LibreChat supports custom endpoints and also lets users provide a custom baseURL for supported endpoint flows.

For this setup, the important part is simple:

LibreChat should send requests to Lynkr’s /v1 base URL
LibreChat should use a model name that Lynkr will accept and route
LibreChat should not need to know which upstream provider you finally use behind Lynkr

So the mental model is:

LibreChat config → one base URL → Lynkr
Lynkr config → actual providers, routing, fallback, cache

That separation is the whole point.

Step 3: Add Lynkr as the LibreChat custom endpoint

The exact UI path can differ depending on how you run LibreChat and how you expose custom endpoints, but the working shape is the same.

In LibreChat, configure a custom OpenAI-compatible endpoint with:

Base URL: http://localhost:8081/v1
API key: any value Lynkr accepts for your setup, or the key your deployment expects
Model: a model string that Lynkr can map or forward

Minimal example values

Endpoint Type: Custom OpenAI-compatible endpoint
Base URL: http://localhost:8081/v1
API Key: dummy-key
Model: gpt-4o-mini

If your LibreChat instance and Lynkr instance run on different hosts, replace localhost with the actual reachable host:

http://lynkr.internal:8081/v1

https://lynkr.yourdomain.com/v1

If you are running LibreChat in Docker and Lynkr on the host machine, you may need to use a host-reachable name rather than localhost, for example:

http://host.docker.internal:8081/v1

That’s one of the most common gotchas.

Step 4: Pick a model name strategy

This part trips people up more than it should.

LibreChat wants a model name. Lynkr also needs to know what to do with that model name.

There are two clean ways to handle this.

Option 1: pass through a real model name

Use a model name that corresponds to the backend you want Lynkr to use.

Example:

gpt-4o-mini

claude-3-5-sonnet

This is the simplest starting point if Lynkr is forwarding traffic in a straightforward way.

Option 2: use stable logical model names in LibreChat

A better long-term pattern is to let LibreChat use a stable name like:

chat-fast

chat-quality

Then map those choices in the gateway layer.

That way:

LibreChat users keep the same model choices
Lynkr can change the real backend later
you can move from OpenRouter to Bedrock or from cloud to local without rewriting the app-side model menu

Even if you do not formalize that on day one, this is the direction I’d recommend.

Step 5: Run a smoke test from LibreChat

Once the endpoint is configured, test a simple chat request first.

Use something cheap and easy to inspect, like:

Write a Python function that reverses a string.

If that works, test a second request that makes backend behavior easier to reason about, like:

Summarize the difference between Redis and PostgreSQL in 5 bullets.

What you’re looking for:

LibreChat sends successfully to Lynkr
Lynkr forwards successfully to the configured provider
the response comes back normally in LibreChat

If this works, the base integration is done.

Step 6: Add one routing policy behind Lynkr

This is where the setup becomes more useful than direct provider wiring.

A good first pattern is:

route lightweight general chat to a cheaper model
route harder reasoning or code-heavy work to a stronger model

Conceptually, the setup looks like this:

LibreChat user chooses: chat-fast
  → Lynkr routes to cheaper tier

LibreChat user chooses: chat-quality
  → Lynkr routes to stronger tier

Even without exposing every provider in LibreChat, you still get flexibility behind the gateway.

That’s cleaner than giving end users six raw vendor choices and expecting them to know when each one is appropriate.

Step 7: Add fallback once the happy path works

Do not start with fallback complexity on the first try. Get one provider working first.

After that, the next useful improvement is fallback.

Example pattern:

primary backend: OpenRouter
fallback backend: Bedrock

primary backend: local Ollama model
fallback backend: stronger cloud model

This gives you a much better operational story than “LibreChat is hardwired to one provider and breaks when that provider has a bad day.”

That’s one of the clearest reasons to keep failover logic below the app layer.

A concrete request flow example

Here’s what this looks like in practice.

Without Lynkr

LibreChat → OpenAI directly

If you want to change providers, add fallback, or introduce routing, those concerns start leaking into the app layer.

With Lynkr

LibreChat → Lynkr → OpenRouter
                    ↘ Bedrock fallback

LibreChat stays pointed at one endpoint.

That means:

less config churn in the app
easier backend changes
cleaner rollout of new models
a better place to add caching and routing

Common gotchas

Here are the ones most likely to waste your time.

1. Wrong base URL

If you point LibreChat at:

http://localhost:8081

instead of:

http://localhost:8081/v1

you may hit endpoint mismatches depending on how the OpenAI-compatible client path is built.

Use the /v1 base URL.

2. Docker networking confusion

If LibreChat runs in Docker, localhost usually means the container itself, not your host machine.

Use a network-reachable host such as:

http://host.docker.internal:8081/v1

or a proper internal hostname.

3. Model name mismatch

If LibreChat sends a model string Lynkr does not recognize or route correctly, requests will fail even though the endpoint is reachable.

When debugging, simplify:

pick one known model string
use one provider
get one request working
only then layer routing or aliases on top

4. Starting with too much complexity

Don’t try to validate all of these at once:

custom endpoint
multiple providers
fallback
caching
routing
agents
MCP tools

Get the base chat completion path working first.

Then expand.

5. Treating LibreChat like the provider control plane

LibreChat is excellent at the user/product layer.

But if you keep using the app layer to own provider switching, cost control, and failover, you lose the main architectural benefit of using a gateway underneath it.

Keep the responsibilities split.

Why this setup is worth it

Even the minimal version gives you a better foundation than direct provider wiring.

You get:

one stable endpoint in LibreChat
provider portability behind the scenes
a better place for routing
a better place for fallback
a better place for caching
a cleaner path from simple chat UI to broader agent infrastructure

And as your setup grows, that separation only gets more valuable.

Minimal checklist

If you just want the shortest possible version, this is it:

Install Lynkr
Start Lynkr on port 8081
Verify http://localhost:8081/v1 is reachable
In LibreChat, add a custom OpenAI-compatible endpoint
Set the base URL to http://localhost:8081/v1
Use a model string Lynkr can route
Run one smoke-test prompt
Only after that, add routing and fallback

Final take

LibreChat already gives you the hard part: a good open-source surface for chat, agents, MCP, and self-hosting.

Lynkr gives you the missing infrastructure layer under it.

That combination is stronger than pushing all model concerns into the app itself.

If you’re building a self-hosted AI stack that needs to survive provider churn, model changes, and growing workflow complexity, this is the shape I’d use.

LibreChat: github.com/danny-avila/LibreChat
Lynkr: github.com/Fast-Editor/Lynkr

If this article was useful, star the repos and let me know if you want the next one to go deeper on:

LibreChat + Lynkr with Docker Compose
model aliases and routing strategy
using LibreChat agents on top of a Lynkr-backed stack

How to Cut Microsoft Agent Framework Costs With a Gateway Layer

Lynkr — Sun, 14 Jun 2026 09:19:54 +0000

Microsoft Agent Framework is built for production multi-agent systems, which is exactly why its LLM bill can grow faster than expected. If you are running workflows with retries, handoffs, tools, and checkpoints, the easiest savings do not come from prompting harder — they come from adding a gateway layer under the framework.

I built Lynkr, so obvious founder disclosure: this article uses Lynkr as the gateway example. I’ll keep it practical and focus on where the cost actually shows up in Microsoft Agent Framework workloads.

Why this is a real Microsoft Agent Framework problem

The current Microsoft Agent Framework README positions it as a production-grade framework for Python and .NET, with:

multi-agent workflows
sequential, concurrent, handoff, and group collaboration patterns
middleware
observability
provider flexibility
checkpointing and human-in-the-loop flows

That is exactly the kind of stack where token usage grows quietly.

A single prompt-response app is easy to reason about. A production workflow is not. Once you add routing, retries, multiple agents, MCP tools, and long-lived execution state, the same context starts getting resent over and over.

That creates four predictable cost leaks.

Where the spend comes from in Microsoft Agent Framework workloads

1. Repeated shared context across agents

Multi-agent systems reuse a lot of the same context:

task instructions
tool definitions
previous messages
workflow state
grounding context

Even when the framework orchestrates cleanly, the model provider still sees repeated input tokens.

2. Tool-heavy steps explode prompt size

Once agents start using tools, responses stop looking like simple chat. You get:

search results
file reads
JSON blobs
browser outputs
execution traces

Those payloads are often much larger than the user’s actual request.

3. Every task does not need the same model

A workflow step that says “classify this,” “summarize these logs,” or “extract the next action” does not need the same model as “resolve a hard bug across four files.”

Without a routing layer, teams overpay by sending too much easy work to premium models.

4. Retries and loops multiply waste

Production agent systems do retries, fallbacks, approvals, and re-runs. That is good engineering. It is also how token bills get weird at the end of the month.

The gateway pattern that fits Microsoft Agent Framework

The cleanest setup is:

Microsoft Agent Framework app
        ↓
     Lynkr gateway
        ↓
OpenAI / Azure OpenAI / Bedrock / OpenRouter / Ollama / Databricks

The framework keeps doing orchestration. The gateway handles cost control under it.

That split matters because you do not want cost logic duplicated across every agent, every workflow node, and every environment.

What Lynkr changes underneath the framework

Lynkr is a self-hosted LLM gateway for Claude Code, Cursor, Codex, and general OpenAI-compatible workloads. In the current README and benchmark report, the grounded claims I can safely use here are:

version 9.5.0
13+ providers
zero code changes at the app layer once the base URL points at the gateway
benchmarked token reductions from smart tool selection and JSON compression
semantic cache hits around 171ms in the published benchmark report

The part that makes it useful for Microsoft Agent Framework is not “one more abstraction layer.” It is that the framework keeps its orchestration role while the gateway centralizes the three cost levers that matter most.

1. Prompt and semantic caching

Agent workflows repeat themselves more than most teams realize.

A classification step comes back with the same shape.
A retry asks nearly the same thing again.
A second agent gets almost the same upstream context.
A human-in-the-loop resume often replays the same state plus one decision.

Caching is how you stop paying full price for near-duplicate work.

In Lynkr’s published benchmark report, semantic cache hits returned in 171ms. That speed matters in production workflows because lower latency compounds with lower spend.

2. Tool payload compression

This is the least talked-about savings lever, and one of the most useful.

Microsoft Agent Framework makes it easier to build workflows that use tools. But once tools start returning structured output, your bottleneck becomes payload size, not just model choice.

Lynkr’s benchmark report shows:

53% fewer tokens on tool-heavy requests through smart tool selection
87.6% compression on large JSON tool results in the benchmarked scenario

That maps well to framework workloads that push around logs, traces, extracted documents, or structured tool responses.

3. Tier routing

Not every orchestration step should hit the same model.

A practical tiering setup looks like this:

simple extraction or classification → cheaper fast model
normal agent work → balanced model
deep reasoning or hard refactors → premium model

That is the difference between “we support multiple providers” and “we actively spend less.”

Microsoft Agent Framework already gives you the orchestration surface. A gateway adds the policy layer under it.

A concrete use case: customer support triage agents

This is the use case I think is under-covered and a very good fit for Lynkr.

Imagine a support workflow built with Microsoft Agent Framework:

ingest a new ticket
classify product area and urgency
summarize the issue
search internal docs or run retrieval
draft a response
escalate only ambiguous or risky cases to a stronger model or a human

Most of those steps are not equally hard.

If every one of them uses the same premium model, you pay premium price for:

classification
deduplication
templated summaries
known-answer lookups
low-risk drafts

That is exactly where a gateway helps.

Why this works especially well

Support triage has all three patterns a gateway can optimize:

repeated ticket shapes → cacheable
structured tool results from retrieval/search → compressible
mixed difficulty across workflow steps → routable

So instead of baking cost logic into each agent, you let the framework orchestrate and let the gateway decide how expensive each turn should be.

Example architecture

from openai import OpenAI

client = OpenAI(
    api_key="dummy",
    base_url="http://localhost:8081/v1"
)

# Your Microsoft Agent Framework components can keep using an OpenAI-compatible endpoint
# while Lynkr handles routing, caching, and payload optimization underneath.

The point is not this exact snippet. The point is the boundary:

your agents keep their workflow logic
your framework keeps orchestration
your gateway handles provider choice, caching, and token reduction

What I would route differently in this workload

If I were wiring Microsoft Agent Framework for support triage, I would usually do this:

ticket classification → cheap fast model
FAQ / known-issue matching → cheap fast model plus cache
retrieval-grounded answer draft → mid-tier model
escalation for ambiguous, legal, or high-risk cases → strongest model
repeat follow-up questions on the same issue → let cache catch them where possible

That is a much stronger operating model than “default everything to the best model and hope prompt engineering saves us later.”

Where competitors can still win

Fairness note: if your top priority is enterprise dashboards, centralized governance, or deeper out-of-the-box observability, other gateway products can be stronger on those axes.

But for Microsoft Agent Framework teams trying to reduce the cost of agentic workloads without rewriting the app, the combination I care about is simpler:

keep the framework for orchestration
insert a gateway once
let caching, compression, and tier routing do the cost work globally

The practical takeaway

Microsoft Agent Framework makes it easier to build serious agent systems. That also means it makes it easier to accidentally overpay for them.

The underused pattern is not “choose a cheaper model.” It is putting a gateway layer under the framework so repeated context, oversized tool payloads, and easy workflow steps stop being billed like hard reasoning.

That is the real use case for Lynkr here: production multi-agent workflows where the waste comes from orchestration overhead, not just model price.

If you want, I can write a follow-up with a full Microsoft Agent Framework example using a support triage workflow and a concrete Lynkr routing setup.

GitHub: https://github.com/Fast-Editor/Lynkr

LiteLLM vs Lynkr for AI Coding Workflows: Where the Token Savings Actually Come From

Lynkr — Wed, 10 Jun 2026 20:58:28 +0000

Most LLM gateways promise the same thing: one endpoint, many providers. That part is useful, but it is not where the real savings come from in AI coding workflows.

The expensive part is what happens inside repeated coding sessions: oversized tool schemas, large JSON tool results, repeated context, and using expensive models for turns that do not need them.

I built Lynkr, so take this as a founder comparison. I’ll keep it honest: LiteLLM is a solid provider abstraction layer. But if your goal is specifically to reduce spend in Claude Code, Cursor, or Codex-style workflows, the difference is not “which gateway supports more providers.” The difference is whether the gateway cuts tokens before they reach the model.

The problem with most “gateway savings” claims

There are a few common ways gateways claim to save money:

route to cheaper models
add fallbacks
centralize traffic
track budgets
cache exact repeated prompts

All of that helps.

But coding workflows have a different cost shape:

the same repo context is sent over and over
tool definitions balloon every request
tool outputs can be huge
not every turn deserves the strongest model
agent loops magnify small inefficiencies into large bills

That is why “multi-provider support” is not enough. You need token reduction at the gateway layer.

What I benchmarked

I recently ran a benchmark comparing Lynkr and LiteLLM on the same backend providers:

Ollama local
Moonshot
Azure OpenAI

The benchmark covered 9 scenarios across 4 feature categories, including:

tool-heavy requests
large JSON tool outputs
paraphrased cache hits
simple vs complex routing decisions

Full report:
https://github.com/Fast-Editor/Lynkr/blob/main/BENCHMARK_REPORT.md

1. Smart tool selection: 53% fewer tokens

One of the easiest ways to waste tokens is forwarding every possible tool definition on every request.

A read-only question does not need write, edit, bash, or git tools. But that still happens in a lot of setups.

Lynkr classifies the request and strips irrelevant tool schemas before forwarding.

Benchmark result

Proxy	Tokens billed	Cost
Lynkr	959	$0.0044
LiteLLM	2,085	$0.0091

Result: 53% fewer tokens, 52% cheaper on the same model and prompt.

That matters because coding sessions are not one-shot prompts. If every turn is carrying unnecessary tool baggage, your costs quietly double.

2. Large JSON tool results: 87.6% fewer tokens

Another hidden cost is tool output.

If a bash command, grep, file read, or agent step returns a large structured JSON payload, that payload gets forwarded to the model. And that gets expensive fast.

Lynkr uses TOON compression for large JSON tool results before sending them upstream.

Benchmark result

Proxy	Tokens billed	Cost	Latency
Lynkr	427	$0.009	12s
LiteLLM	3,458	$0.018	12s

Result: 87.6% compression and 50% cheaper, with the same latency in this benchmark.

That is the kind of optimization that matters in real agent workflows, because those systems often generate verbose intermediate outputs.

3. Semantic cache: 171ms responses, 0 billed tokens on cache hit

Exact-match caching is useful, but coding workflows often produce near-duplicate prompts rather than byte-for-byte repeats.

For example:

“Explain TCP vs UDP”
“What is the difference between TCP and UDP?”

Lynkr uses semantic caching, so paraphrased prompts can hit cache too.

Benchmark result

Scenario	Tokens billed	Response time
First call (cold)	2,857	1,891ms
Second call (paraphrased cache hit)	0	171ms

Result: 171ms response time and 0 billed tokens on cache hit.

That is the kind of win that changes the economics of repeated team usage.

4. Tier routing: not every prompt deserves the same model

Routing to the cheapest available model is not the same thing as routing correctly.

If someone asks:

“What does git stash do?” → local/free model is fine
“Design a secure JWT vs cookie architecture for banking auth” → that should escalate

Lynkr scores requests across 15 dimensions including:

token count
code complexity
reasoning markers
risk patterns
agentic signals

Then it routes automatically.

Benchmark result

Request	Lynkr	LiteLLM
“What does git stash do?”	local/free tier	local/free tier
JWT vs cookies security analysis	cloud model	cheapest local model

That difference matters. Cheap routing is only good when it is still the right call.

Monthly cost projection

The benchmark includes a simple cost projection for 100,000 requests/month using a tool-heavy agentic workload:

Proxy	Monthly cost
LiteLLM	~$818
Lynkr	~$409

That is roughly 50% cheaper on the same backend.

This is the key point: if you compare gateways fairly on equal footing, the savings do not come from magic. They come from removing waste before tokens ever hit the provider.

Where LiteLLM is still strong

LiteLLM is still a strong product if your main need is:

provider abstraction
budget controls
standard proxy behavior
existing Python-heavy infra

If you want a broad proxy layer and do not care much about coding-workflow-specific token optimization, LiteLLM is a reasonable choice.

Where Lynkr is different

Lynkr is built around AI coding and agent workflows specifically.

That means it focuses on:

smart tool selection
TOON compression for large JSON outputs
semantic cache
automatic complexity-based tier routing
MCP integration
Code Mode
long-term memory
drop-in compatibility for Claude Code, Cursor, and Codex

It has:

13+ providers supported
Code Mode reduces MCP tool-definition overhead by ~96%
0 code changes required for drop-in integration

The real takeaway

If all you want is “many providers behind one API,” a gateway like LiteLLM covers that.

But if your actual goal is to make AI coding infrastructure materially cheaper, the important question is:

Does the gateway reduce tokens before they reach the model?

That is where the biggest savings come from.

For AI coding workflows, the biggest cost levers are usually:

removing irrelevant tools
compressing tool output
caching semantically similar turns
routing simple requests to cheap models and escalating only when needed

That is the layer I built Lynkr around.

If you want to look at the benchmark or try it yourself:

GitHub: https://github.com/Fast-Editor/Lynkr
Benchmark report: https://github.com/Fast-Editor/Lynkr/blob/main/BENCHMARK_REPORT.md

If you are building around Claude Code, Cursor, Codex, or MCP workflows, I’d be curious what your biggest source of token waste has been.

How Efficient Model Routing can save upto 80% in AI costs without compromising the quality of the output

Lynkr — Wed, 10 Jun 2026 04:01:33 +0000

Why did this workflow get cheaper last week?

Why did support quality drop after a routing change?

Was the failure caused by the model, the router, or the task decomposition?

Most multi-model systems can route for cost. Very few can explain why a task was sent to a specific model, what tradeoff was made, and whether the cheaper path was actually justified.

That is not just a research gap. It is an operational one.

Once an agent stack starts making economic decisions on every turn, developers need routing decisions they can inspect, replay, and override. In production, the only layer positioned to provide that is the gateway.

I went through the paper Explainable Model Routing for Agentic Workflows (arXiv:2604.03527). It introduces Topaz, a routing framework built around a useful idea: model routing should be interpretable by humans, not just optimized in the background.

That matters because explainable routing is only valuable if it is attached to the layer that actually sees the real levers in production: cost, quality sensitivity, cache behavior, fallback paths, provider performance, and per-step policy decisions.

That layer is the gateway.

Topaz in one minute

Topaz keeps the core routing loop simple and interpretable:

Skill-based model profiles: models are represented through capabilities like logic, code generation, tool use, factual knowledge, writing quality, instruction following, and summarization.
Explicit cost-quality optimization: routing decisions are made through visible optimization logic instead of opaque heuristics alone.
Developer-facing explanations: the system turns those decisions into plain-language reasoning a human can audit.

That is the right direction. A routed system is only trustworthy if a developer can tell the difference between intelligent specialization and silent quality regression.

The real production takeaway

The paper is framed as a routing contribution, but the more important implication is where explainability has to live in practice.

A router can score tasks. A gateway can explain the system.

That distinction matters.

The gateway is the only layer with enough visibility to answer the questions teams actually ask after launch:

which provider and model handled each step?
did the system downgrade because the task was low risk or because the budget threshold fired?
was there a cache hit or miss?
did the request escalate because of tool complexity?
did a fallback trigger because of timeout, rate limit, or policy?
which step is safe to replay under a different routing policy?
which user-visible step should be pinned to a stronger model no matter what?

If explainability stops at “the router chose model B because skill-match was 0.81,” it is not enough.

In production, teams need a trace they can debug.

They need to know:

what happened
why it happened
what it cost
what would have happened under a different policy
what should be overridden next time

That is gateway territory.

A concrete example

Take a simple support workflow with four steps:

Classify the incoming issue → cheap model
Generate a fix plan → strong reasoning model
Execute tool-heavy actions → model optimized for tool use
Write the final customer-facing response → premium model

A production-grade explanation layer should not just say “the system routed efficiently.” It should explain each step in operational terms.

For example:

Issue classification: routed to a cheaper model because quality sensitivity was low and the task profile was narrow
Fix planning: escalated because the task required stronger reasoning and a downgrade increased regression risk
Tool-heavy execution: assigned to a tool-optimized model because the step depended on multiple tool calls and fallback risk was higher on weaker models
Final response: pinned to a premium model because it was user-visible and policy disallowed aggressive downgrades
Fallback event: rerouted after timeout or rate-limit threshold was hit
Cost note: cache miss on shared context increased input cost for this run

That is the kind of explanation developers can work with.

It tells them whether the system behaved correctly, where cost increased, where quality was protected, and what policy they may want to change.

Routing alone is not enough

Routing is only one part of the cost stack.

For real agent and coding workflows, the bigger savings usually come from three levers working together at the gateway layer.

1. Prompt caching

A lot of agent loops resend the same long context: repo maps, attached files, prior tool traces, or repeated instructions.

If the gateway can preserve or inject provider-side caching correctly, it cuts repeated input cost before routing even starts.

Without gateway visibility, teams cannot explain whether a run was cheaper because the router made a better choice or because the system got a cache hit.

2. Tier routing

Not every step deserves the expensive model.

Low-risk classification, formatting, and shallow transformations can route down. Hard reasoning, recovery paths, and user-visible outputs should stay higher.

But those choices need replay and override. A team has to be able to inspect a downgrade decision and say: this was safe, this was too aggressive, this customer-facing step should never go below tier X.

3. Tool-flow compression

In agent systems, the tool loop itself becomes expensive. Every extra round trip can resend context, increase latency, and amplify token waste.

That is why patterns like MCP Code Mode matter. Compressing tool-heavy work into fewer round trips changes the economics of the whole system.

Again, the gateway is where that becomes observable:

round-trip count
tool-heavy vs plain completion flow
token growth across steps
fallback behavior during execution
total cost deltas after policy changes

That is why explainable routing belongs next to gateway observability, not as a thin layer on top of a black-box router.

The skepticism this space needs

There is a real failure mode here: “explainable routing” can turn into theater.

A few reasons to be skeptical:

skill taxonomies drift: the categories used to profile models can stop matching real workloads
explanations can become post-hoc: a clean trace is useless if it is not faithful to the actual decision path
quality sensitivity is hard to label: teams often underestimate which steps are truly user-visible or regression-sensitive
pretty traces are not enough: developers need replay, policy override, and audit logs, not just a narrative

That is why the standard should be higher.

An explanation system should be judged on whether it helps a team debug regressions, justify cost changes, and safely tighten routing policy over time.

If it cannot support replay and override, it is not operationally complete.

Why this matters for Lynkr

I built Lynkr, so the obvious disclosure is that I read Topaz through the lens of what an LLM gateway should expose in production.

The core idea is straightforward: the gateway is where cost, quality, fallback, caching, and provider behavior meet. That makes it the natural home for explainable routing.

For Lynkr specifically, that means explainability should connect to the things that actually drive outcomes:

provider/model selection
prompt caching behavior
tier routing policy
tool-heavy vs standard completion paths
fallback events
cache hit/miss impact
downgrade risk on user-visible steps
replay and override of routing decisions

That is also why routing by itself is not enough.

The real win is stacking levers:

prompt caching to cut repeated input cost
tier routing to reserve premium models for the steps that justify them
tool-flow compression to reduce waste across agent loops
observability strong enough to explain where savings came from and where quality risk entered the system

That is the difference between “we routed to a cheaper model” and “we know exactly why this workflow cost less, where the risk moved, and which policy we want to change next.”

The actual shift

The shift is not just from single-model apps to multi-model systems.

It is from opaque orchestration to auditable orchestration.

Topaz is useful because it pushes routing toward human-interpretable decisions. The stronger takeaway is that explainability belongs at the gateway layer, because that is the only place with enough visibility to audit cost, quality, fallback, caching, and provider behavior across the whole system.

That is where production routing gets real.

If you are building multi-model or agentic systems, this is the right question to ask next:

not just can the system route?

but can the system explain, replay, and override the route when something breaks?

Paper: Explainable Model Routing for Agentic Workflows
Lynkr: github.com/Fast-Editor/Lynkr

If you want, I can next turn this into a stronger LinkedIn post or write the follow-up piece on what explainable routing looks like for coding agents specifically.

How to Make PydanticAI Agents Cheaper with Lynkr

Lynkr — Tue, 09 Jun 2026 04:59:04 +0000

PydanticAI is one of the cleanest ways to build structured LLM agents in Python. But once those agents start doing real work — tool calls, validation retries, structured outputs, and multi-step flows — the token bill climbs faster than most teams expect.

Lynkr fits underneath that stack as an LLM gateway. It does not replace PydanticAI. It makes the model layer under it cheaper and easier to control with tier routing, prompt caching, and provider flexibility.

Founder disclosure: I built Lynkr, so take that into account. I’ll keep this practical and focus on where the fit is real.

Why PydanticAI is compelling in the first place

I spent time going through PydanticAI because it solves a problem a lot of Python agent frameworks make messy: keeping agent code structured without giving up flexibility.

What stood out to me is that PydanticAI is built around the same things Python teams already care about in production:

typed agents
structured outputs
dependency injection
tool calling
model/provider flexibility
observability and eval-friendly workflows
graph support for more complex control flow

The repo positions it as a production-grade Python agent framework, and that shows up quickly in the design. The README emphasizes model-agnostic support across OpenAI, Anthropic, Gemini, Bedrock, Ollama, Groq, OpenRouter, LiteLLM, and more. It also leans heavily into typed outputs, MCP integration, durable execution, and validation-driven retries.

That combination makes PydanticAI attractive for teams that want agent workflows to feel more like real Python systems and less like prompt spaghetti.

Where the token spend starts to leak

The part that matters economically is not whether the framework is good. PydanticAI is good.

The problem is that good structure does not automatically mean cheap execution.

In practice, cost starts leaking in a few predictable places:

repeated system instructions across multiple runs
the same output schema getting sent over and over
validation failures triggering retries
tools being selected or called in multiple rounds
expensive models getting used for easy intermediate steps
long workflows carrying too much repeated context forward

PydanticAI’s strengths can actually make this more visible.

If you use typed outputs, the model may need another pass when validation fails.
If you use tools, there can be multiple model turns around those tools.
If you use graphs or longer agent flows, repeated context starts compounding.
If you keep one premium model as the default for everything, simple steps inherit premium-model pricing for no good reason.

None of that is a PydanticAI flaw. It is just what happens when a framework makes it easier to build richer agent workflows.

Where Lynkr fits

The right way to understand Lynkr here is simple:

PydanticAI stays the application layer
Lynkr becomes the gateway layer underneath it

That means your Python agent logic does not need to become a mess of provider-specific conditionals just to get better economics.

You keep using PydanticAI for:

agent structure
typed outputs
tools
graphs
retries
application logic

And you use Lynkr for:

model routing
prompt caching
provider switching
centralized cost control

That separation matters because most teams do not want to rebuild their agent code every time they want to try a cheaper provider, add routing, or move one class of requests off an expensive model.

1. Route easy turns to cheaper models

One of the easiest ways to overspend in agent systems is to treat every turn like frontier reasoning.

A lot of PydanticAI work is not actually frontier reasoning.

Examples:

classification before the main task
extraction from predictable text
tool selection
formatting into a structured schema
intermediate planning
low-risk follow-up steps after a strong first pass

Those steps often do not need the best model in your stack.

Lynkr helps by putting routing under the agent, so easier turns can go to cheaper models while harder turns still escalate when they need to.

That is a much better cost shape than paying premium-model rates for every structured substep just because the app has one default model configured.

2. Stop paying repeatedly for the same context

This is the biggest recurring waste pattern in real agent systems.

A PydanticAI workflow often reuses a lot of stable prompt material:

system instructions
output schemas
tool descriptions
dependency-derived context
conversation framing that barely changes between turns

If that prompt material is sent again and again, the system keeps paying for mostly the same input.

This is where Lynkr’s caching layer matters.

Instead of treating every call as fully fresh, the gateway can cut down repeated prompt spend underneath the workflow. That matters more as the workflow gets longer, as the schema gets larger, or as the tool surface grows.

For small toy demos, this does not matter much.
For real agent workloads, it matters a lot.

3. Keep the app stable while changing the economics

One reason teams tolerate waste for too long is that optimizing the stack usually means rewriting too much application code.

PydanticAI already gives you a clean framework for the agent logic. The useful part of Lynkr is that it lets you change the economics without ripping that logic apart.

That gives you room to:

compare providers more easily
reduce lock-in
shift easy steps to cheaper models
keep premium models for the parts that actually need them
centralize model behavior across multiple agent workflows

So the win is not just lower cost. It is lower cost without turning your Python codebase into provider-routing glue.

Example: structured extraction plus tools

A simple example makes the fit clearer.

Say you have a PydanticAI workflow that does this:

user submits messy unstructured text
agent extracts typed fields into a schema
validation fails on one field and triggers a retry
agent calls a tool to enrich one part of the result
final typed response is returned to the app

That is a perfectly reasonable workflow.

It is also exactly the kind of flow where hidden waste appears:

the schema is repeated
instructions are repeated
the retry adds another paid turn
the tool step adds more model interaction
the same premium model may be used for all five stages

Under Lynkr, that workflow can be made cheaper in the places that usually do not need the strongest model every time.

The extraction/classification layer can be routed down.
Repeated prompt material can be cached.
The harder step can still route up if needed.

That is the real value: not changing what the workflow does, but changing how expensively it gets there.

What the integration shape looks like

I am intentionally keeping this part conceptual instead of pretending exact config syntax from memory.

The practical setup is:

PydanticAI points to the Lynkr base URL
Lynkr handles provider and routing behavior underneath
your agent code stays mostly the same

That is the integration story that matters.

The point is not “replace your framework.”
The point is “keep your framework, improve the model layer under it.”

Where Lynkr does not replace framework-level discipline

This part matters because it is where a lot of gateway writing becomes dishonest.

Lynkr can cut model cost and make provider switching easier, but it does not fix a badly designed agent workflow.

If a PydanticAI app is looping too much, retrying too aggressively, or making unnecessary tool calls, those problems still exist. The gateway can reduce the price of those mistakes. It does not remove them.

What Lynkr helps with is the economics and control layer around the workflow:

route cheaper models to simpler steps
keep expensive models for the calls that actually need them
cache repeated work
avoid getting locked to one provider
standardize how requests move across providers

What it does not do on its own:

redesign weak prompts
stop bad retry logic
fix overly chatty agent graphs
choose the right tool boundaries for your app
replace evaluation and tracing discipline

That matters because a lot of agent cost does not come from one expensive call. It comes from repeated mediocre decisions across a workflow.

PydanticAI is useful because it gives structure to the application layer. Lynkr is useful because it gives control to the model-routing layer. They solve different problems, and they work better together than separately.

Who should care

PydanticAI + Lynkr is a strong fit if:

you are running a meaningful number of agent calls
you want structured workflows in Python
you care about typed outputs and tool use
your workflows retry or branch often enough for costs to become visible
you want provider flexibility without constantly changing application code

Closing thought

PydanticAI solves the structure problem well. Lynkr helps solve the economics problem underneath it.

If you are building typed Python agents and starting to notice that retries, tools, and repeated context are quietly inflating cost, this is a very practical combination to test.

GitHub: https://github.com/Fast-Editor/Lynkr

If you are already using PydanticAI, I’d be curious where the spend is showing up first in your workflow.

Run CrewAI With 50% Lower LLM Cost Using Lynkr

Lynkr — Sun, 07 Jun 2026 19:24:01 +0000

If you are building multi-agent systems in Python, CrewAI is one of the biggest frameworks you need to know.

And if your CrewAI workloads are starting to get expensive, the simplest way to control that spend is to put an LLM gateway in front of them instead of wiring every agent directly to one provider.

In this article, I’ll explain what CrewAI is, why it got so popular, and how to use it with Lynkr so your agents can run with better model routing, caching, and lower cost.

I built Lynkr, so that part comes with the obvious founder disclosure. Still, CrewAI is worth understanding on its own because it has become one of the main entry points for people building agent systems in Python.

What is CrewAI?

CrewAI is an open-source Python framework for orchestrating multiple AI agents.

At the time of writing, the GitHub repo has 53k stars.

The project describes itself as a:

Fast and Flexible Multi-Agent Automation Framework

Its core idea is simple:

define agents with roles and goals
define tasks
decide how they collaborate
run them as a system instead of a single prompt chain

That is the mental model behind the name CrewAI: not one agent, but a crew of specialized agents working together.

Why CrewAI matters

A lot of agent demos are still just one prompt plus one tool call.

CrewAI matters because it pushes people toward more structured systems:

researcher agent
writer agent
reviewer agent
planner agent
execution agent

Each one can have a different role, context, and tool setup.

That makes it useful for:

research pipelines
content workflows
internal business automation
data gathering + summarization flows
agent handoff patterns
more production-style orchestration than “just call the model again”

The reason it got traction is that it sits in a nice middle ground:

higher-level than wiring every agent loop yourself
more concrete than vague "agent platform" marketing
easy enough for Python developers to start with quickly

The two big concepts in CrewAI: Crews and Flows

From the current repo README, CrewAI emphasizes two core concepts.

1. Crews

Crews are teams of agents collaborating with autonomy.

This is the “multi-agent” part most people think of first:

specialized roles
role-based collaboration
delegation
agents working together toward a result

2. Flows

Flows are the more controlled, event-driven side.

This is where CrewAI becomes more production-friendly:

execution paths
state management
conditional logic
integration with normal Python code
more deterministic orchestration when you need it

That combination is a big part of the pitch:

Crews for agent autonomy
Flows for production control

Why CrewAI gets expensive fast

This part usually becomes obvious after the first real project.

A single-agent script is one thing.

A multi-agent system is different.

Costs grow because you now have:

multiple agents making separate LLM calls
handoffs between agents
intermediate summaries
retries
reflection/replanning
tool use across several steps
repeated context being passed around the system

So the problem is not just “what model am I using?”

It becomes:

do all agents need the same expensive model?
should the planner use the same model as the formatter?
how much repeated context is being resent?
can simple routing/classification work go to cheaper models?
can repeated flows benefit from cache hits?

That is exactly the kind of workload where a gateway layer starts making sense.

Where Lynkr fits

If CrewAI is the orchestration layer, Lynkr can sit underneath it as the LLM gateway.

That means your architecture becomes:

CrewAI agents / flows
        ↓
      Lynkr
        ↓
Ollama / OpenRouter / Bedrock / OpenAI / Azure / Databricks / others

Instead of wiring each agent stack directly to one provider, you point your model traffic at one gateway endpoint and let that layer decide what happens next.

Why use Lynkr with CrewAI?

This is the important part.

The real benefit is not just “use any provider.”

That is table stakes now.

The better reason is that Lynkr gives you three strong levers for agent workloads:

1. Prompt caching

Multi-agent systems resend a lot of context.

That can include:

system prompts
task descriptions
agent roles and backstories
previous step context
the same instructions reused across repeated runs

Lynkr’s caching layer helps reduce the amount of repeated input you pay for.

For agent systems, that matters a lot more than it does in one-off chat prompts.

2. Tier routing

Not every step in a CrewAI workflow deserves your strongest model.

Examples:

Use a cheaper/faster model for:

classification
routing
formatting
deterministic transformation
simple extraction
narrow sub-tasks

Use a stronger model for:

planning
reasoning-heavy synthesis
ambiguous task decomposition
final high-stakes output

This is exactly what tier routing is for.

3. One stable model endpoint

Once your agents grow from a prototype into a system, you usually want:

one model boundary
one place to switch providers
one place to add failover
one place to add policy and cost control

That is what a gateway layer gives you.

What Lynkr says it does well today

From the current Lynkr README, the main cost/performance claims are:

53% fewer tokens on tool-heavy requests
87.6% compression on large JSON tool results
171ms semantic cache hits
automatic tier routing
zero code changes at the client boundary once the endpoint is swapped

Those numbers come from coding-tool workloads, not specifically a published CrewAI benchmark.

So the honest framing is:

I am not claiming a public CrewAI benchmark showing exactly 50% lower cost on every workload
I am saying CrewAI has the exact kind of multi-step agent workload where these levers matter most

That is why “50% lower cost” is a fair headline shape for the category, but the actual result will depend on how your CrewAI system is built.

How to get started with CrewAI

From the current CrewAI README, installation starts like this:

uv pip install crewai

If you also want the tools extras:

uv pip install 'crewai[tools]'

The project also provides a CLI starter for creating a new crew project:

crewai create crew <project_name>

That scaffolds a project with:

main.py
crew.py
agents.yaml
tasks.yaml
.env

So CrewAI is designed to be used as a real project structure, not just a single script.

A simple mental model for CrewAI code

A better way to think about CrewAI is:

define who each agent is
define what each task needs done
define how work moves between agents
then execute the whole workflow as one coordinated system

That is the real shift from a normal single-agent app.

You are not just prompting one model repeatedly.
You are designing a small working system with roles, handoffs, and outputs.

A minimal conceptual example looks like:

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Researcher",
    goal="Find the best information on a topic",
    backstory="You are great at gathering relevant details"
)

writer = Agent(
    role="Writer",
    goal="Turn research into a clear output",
    backstory="You write concise, structured summaries"
)

research_task = Task(
    description="Research the latest browser agent frameworks",
    agent=researcher
)

write_task = Task(
    description="Write a short technical summary from the research",
    agent=writer
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task]
)

result = crew.kickoff()
print(result)

That is not copied from their exact starter file, but it reflects the basic CrewAI model:

roles
tasks
orchestration

How to use CrewAI with Lynkr

The practical pattern is straightforward:

install CrewAI
install and start Lynkr
point the model calls used by your CrewAI stack at Lynkr instead of directly at one provider
let Lynkr handle routing/caching/provider flexibility underneath

1. Install Lynkr

npm install -g lynkr

2. Configure Lynkr

A simple cloud-backed setup from the current Lynkr README looks like this:

# .env
MODEL_PROVIDER=openrouter
OPENROUTER_API_KEY=your-key
FALLBACK_ENABLED=false
PORT=8081
PROMPT_CACHE_ENABLED=true
SEMANTIC_CACHE_ENABLED=true

Then start Lynkr:

lynkr start

If you want local-first testing, Lynkr also supports local backends like:

Ollama
llama.cpp
LM Studio

That is useful for CrewAI because some low-value steps can run cheaply or locally, while harder reasoning tasks can still escalate.

3. Route CrewAI’s model traffic through Lynkr

The exact code depends on which model client you use with CrewAI.

The architecture is the important part:

CrewAI model client → Lynkr base URL → actual provider(s)

Because Lynkr gives you an OpenAI-compatible gateway surface, the integration is most natural when your CrewAI model configuration can target an OpenAI-style endpoint.

That lets you keep CrewAI as the orchestration layer while Lynkr becomes the control plane for model choice and cost behavior.

A better way to think about model assignment in CrewAI

Here is where most teams leave money on the table.

They do this:

planner agent → expensive model
researcher agent → same expensive model
formatter agent → same expensive model
reviewer agent → same expensive model

That is easy, but wasteful.

A better shape is:

planner → strong reasoning model
researcher → medium model
summarizer → medium or cheap model
formatter → cheap model
repeated workflows → cached through gateway

The point is not that every step should be cheap.

The point is that different agent roles have different model requirements.

CrewAI already encourages role specialization.

Lynkr makes it easier to pair that with cost specialization.

A concrete example

Imagine a CrewAI workflow for market research.

You have:

one agent gathering raw sources
one agent extracting facts
one agent writing the report
one agent reviewing for quality

Without a gateway, teams often default to one premium model for all four.

With Lynkr underneath, the better pattern is:

gather/extract → cheaper tier
writing → medium tier
review/final reasoning → stronger tier
repeated report skeleton/context → cache where possible

That is a much more rational cost shape.

Why this matters more for CrewAI than normal apps

A normal app may only hit the LLM a few times.

A CrewAI system can explode the number of calls because the framework is designed around multiple agents and structured orchestration.

So the value of a gateway grows with:

number of agents
number of task handoffs
amount of repeated context
number of production runs
number of providers you want to evaluate

That is why CrewAI is such a good fit for the “put a gateway underneath it” pattern.

What Lynkr does not replace

Important distinction:

CrewAI is still the orchestration framework
Lynkr is still the LLM gateway

Lynkr does not replace CrewAI’s agent/task/flow model.

It complements it by making the model layer cheaper and more flexible.

Honest tradeoffs

It is worth being direct here.

A gateway adds another infrastructure layer.

That is worth it when:

you have multiple agents
you care about spend
you want provider flexibility
you are moving toward production usage

It may not be worth it when:

you are just learning CrewAI
you are running a toy example once
simplicity matters more than control

So I would not tell every beginner to add a gateway on day one.

But once your CrewAI project becomes real, the gateway question shows up quickly.

Final take

CrewAI is one of the most important open-source frameworks in the multi-agent Python ecosystem right now.

It gives you a useful structure for building agent systems with:

roles
tasks
crews
flows
production-style orchestration

And if those systems are getting expensive, Lynkr is a practical way to put a cost-and-routing layer underneath them.

That gives you:

one stable model endpoint
provider flexibility
caching for repeated context
tier routing for different agent roles
a better chance of keeping multi-agent systems affordable as they scale

If you want to try the stack:

CrewAI: https://github.com/crewAIInc/crewAI
Lynkr: https://github.com/Fast-Editor/Lynkr

If you are already running CrewAI in production, I think the right question is not:

“What is the best model?”

It is:

“Which parts of my agent system actually deserve the expensive model?”

What Is browser-use? And How to save 50% of tokens while using it.

Lynkr — Sun, 07 Jun 2026 07:31:07 +0000

If you are building AI agents that can actually do things on websites, browser-use is one of the most important open-source projects to understand right now.

And if you want to use it without being locked into a single model path, Lynkr is a clean way to put a gateway between your browser agent and whichever LLMs you want behind it.

I built Lynkr, so take the integration section with that disclosure in mind. Still, browser-use is genuinely one of the most interesting repos in the agent stack right now, and it is worth understanding on its own.

What is browser-use?

browser-use is an open-source framework for giving LLM agents access to a real browser.

In plain English:

it opens a browser
lets an agent inspect the current page state
click buttons
type into inputs
extract information
navigate across sites
and complete real browser workflows from a prompt

The project’s GitHub description is:

Make websites accessible for AI agents. Automate tasks online with ease.

At the time of writing, the repo has 97.5k stars, which tells you this is not some niche experiment anymore.

Why browser-use blew up

A lot of “AI agents” stop at text generation.

browser-use matters because it pushes into the next step: agents that can interact with software the same way a user does.

That means you can build workflows like:

filling out forms
pulling data out of dashboards
logging into tools and clicking through UI flows
checking prices, calendars, tickets, or inventory
testing internal tools
handling repetitive browser tasks that don’t have a clean API

That’s the real appeal: many businesses do not need another chatbot. They need automation for systems that only really exist behind a browser.

What browser-use gives you

From the repo and quickstart, the project gives you a few things that make it practical:

an open-source Python agent framework
a browser abstraction the agent can control
examples for common browser tasks
a CLI for persistent browser automation
optional cloud/browser infrastructure from the Browser Use team
support for multiple LLM backends in its quickstart examples

Their human quickstart shows the core pattern:

from browser_use import Agent, Browser, ChatBrowserUse
import asyncio

async def main():
    browser = Browser()

    agent = Agent(
        task="Find the number of stars of the browser-use repo",
        llm=ChatBrowserUse(),
        browser=browser,
    )
    await agent.run()

if __name__ == "__main__":
    asyncio.run(main())

The important concept is simple:

Browser() handles the browser session
Agent(...) handles the goal and step-by-step decisions
llm=... controls which model layer is making those decisions

That last part is exactly where Lynkr becomes useful.

Where Lynkr fits

If browser-use is the browser-side execution layer, Lynkr can sit under it as the LLM gateway.

That gives you one stable endpoint between your browser agent and the actual providers behind it.

Instead of hard-wiring one provider path everywhere, you can put this in the middle:

browser-use agent
      ↓
    Lynkr
      ↓
Ollama / OpenRouter / Bedrock / OpenAI / Azure / Databricks / others

That matters because browser agents are usually:

multi-step
tool-heavy
iterative
expensive when they retry or explore a page

And those are exactly the workloads where routing and token optimization matter.

Why use Lynkr with browser-use?

The basic answer is: browser agents create lots of LLM calls, and Lynkr helps you control that cost and flexibility.
Lynkr has tiered routing which can help you save 50-60% of your token usage.

From the current Lynkr README, the relevant levers are:
---- all these values are compared to LiteLLM

53% fewer tokens on tool-heavy requests
87.6% compression on large JSON/tool outputs
171ms semantic cache hits
automatic tier routing
zero code changes at the client boundary once the endpoint is swapped

Even though those numbers come from coding-tool workloads, the shape maps well to browser agents too:

page-state dumps can get large
repeated task loops can benefit from cache hits
simple browser steps do not always need your most expensive model
hard navigation/reasoning steps can be escalated to a stronger model

So the win is not just “use another model.”

It is:

one gateway endpoint
provider flexibility
routing cheap vs expensive work differently
lower spend on repetitive agent loops

When this combination makes sense

Using browser-use with Lynkr makes the most sense if you are doing any of these:

running browser agents repeatedly in production
experimenting with multiple providers for reliability or cost
mixing local and cloud models
trying to avoid hard vendor lock-in
building internal automations where cost per workflow matters
wanting one OpenAI-compatible gateway for several agent systems, not just browser-use

If you are just trying one script once, direct provider setup is fine.

If you are building a real browser-agent workflow that you will run over and over, putting a gateway in front of it starts to make more sense.

How to use browser-use

The project’s quickstart uses uv and Python 3.11+.

1. Install browser-use

uv init
uv add browser-use
uv sync

If Chromium is not already installed, their repo also mentions:

uvx browser-use install

2. Create a simple browser-use script

Start with a minimal example.

from browser_use import Agent, Browser, ChatBrowserUse
import asyncio

async def main():
    browser = Browser()

    agent = Agent(
        task="Open GitHub and find the number of stars on the browser-use repository",
        llm=ChatBrowserUse(),
        browser=browser,
    )

    result = await agent.run()
    print(result)

if __name__ == "__main__":
    asyncio.run(main())

This verifies that:

Python is set up correctly
the browser launches
the agent can take a goal and act on it

That gets you the baseline.

3. Install Lynkr

Now add the gateway layer.

npm install -g lynkr

4. Start Lynkr with a provider behind it

For a simple cloud setup, the current Lynkr README shows OpenRouter like this:

# .env
MODEL_PROVIDER=openrouter
OPENROUTER_API_KEY=your-key
FALLBACK_ENABLED=false
PORT=8081
PROMPT_CACHE_ENABLED=true
SEMANTIC_CACHE_ENABLED=true

Then start Lynkr:

lynkr start

For a free/local path, Lynkr also supports local providers like:

Ollama
llama.cpp
LM Studio

That means you can test browser agents locally first, then move harder tasks to cloud models later.

5. Point browser-use at Lynkr

This is the part that depends on which LLM wrapper you use inside browser-use.

The repo’s README shows examples like:

ChatBrowserUse()
ChatGoogle(...)
ChatAnthropic(...)

The general pattern is:

if your selected browser-use model wrapper supports a custom base URL / OpenAI-compatible endpoint, point it at Lynkr
Lynkr then forwards the request to the actual backend provider you configured

The integration idea is the same as any other app using a gateway:

browser-use LLM client → Lynkr base URL → chosen providers

Because Lynkr exposes an OpenAI-compatible surface and already supports routing clients like Claude Code, Cursor, Codex, Cline, and Continue, the practical fit is strongest when your browser-use stack can talk through an OpenAI-style endpoint.

A practical architecture to think about

If you are building a serious browser automation system, this is the architecture I would use:

Your app / worker
      ↓
 browser-use
      ↓
   Lynkr
      ↓
Simple tasks → cheap/local model
Hard tasks   → stronger cloud model
Retries      → cached/routed through same gateway

That gives you a few operational wins:

one place to change providers
one place to add caching/routing
one place to enforce model policy
one place to swap local/cloud behavior

What kinds of browser-use tasks benefit most?

The biggest benefit is not “every browser step becomes cheap.”

The biggest benefit is that not every step deserves the same model.

Examples:

Good candidates for cheaper tiers

page classification
checking whether an element exists
extracting a small piece of text
moving through obvious deterministic UI steps
repeated workflows you run every day

Good candidates for stronger models

ambiguous navigation
dense multi-step forms
recovery after unexpected UI changes
reasoning-heavy extraction tasks
flows with messy instructions from users

This is exactly why a gateway helps. Browser agents are not one homogeneous workload.

A realistic example

Say you are automating a support workflow:

log into admin panel
search user account
open billing page
check subscription state
update a field
confirm success
export some result back to your app

Without a gateway, every step may go to the same expensive provider.

With Lynkr in the middle, you can move toward:

cheap model for straightforward navigation
stronger model when the page layout becomes ambiguous
cache/reuse repeated context patterns
preserve one integration point in your app

That’s a much better shape as soon as workflows become frequent.

What Lynkr does not replace here

Important distinction:

browser-use is still the browser automation layer
Lynkr is still the LLM gateway layer

Lynkr does not replace the actual browser agent runtime.

It sits underneath it and makes the model side more flexible.

That is why this pairing is interesting: they are complementary, not redundant.

Tradeoffs and honesty section

Since I built Lynkr, it is worth stating the tradeoffs plainly.

Using a gateway adds another layer to operate.

That is worth it when you care about:

provider control
cost routing
caching
consistent integration across multiple tools

It is not automatically worth it for:

one-off experiments
tiny local scripts you run once a week
very early prototypes where simplicity matters more than control

So the right mental model is not “everyone needs a gateway.”

It is “browser agents become more infrastructure-like very quickly, and gateway control starts paying off once that happens.”

Why browser-use is worth learning even if you do not use Lynkr

Even without the Lynkr angle, browser-use matters because it represents a bigger shift:

we are moving from LLMs that answer questions to LLM systems that can operate software.

That changes the shape of automation.

The future stack is not just:

prompt in
text out

It is increasingly:

goal in
browser actions
tool calls
retries
extraction
completion

And browser-use is one of the clearest open-source projects showing that shift.

Final take

If you want to understand modern browser agents, start with browser-use.

If you want to run those agents with more control over cost, routing, and provider choice, put Lynkr underneath them as the LLM gateway.

That combination gives you:

browser automation on top
provider flexibility underneath
one stable endpoint for your model layer
a cleaner path to scaling beyond a single hard-wired provider

If you want to try it, start here:

browser-use: https://github.com/browser-use/browser-use
Lynkr: https://github.com/Fast-Editor/Lynkr

If you’re already using browser-use, I’d be curious about one thing:

would you rather optimize for the strongest possible model on every step, or route browser-agent work by difficulty and cost?

I Benchmarked Lynkr Against LiteLLM on the Same Backends.

Lynkr — Sat, 06 Jun 2026 00:14:18 +0000

I Benchmarked Lynkr Against LiteLLM on the Same Backends. Lynkr Was Cheaper for Tool-Heavy Workloads

Founder disclosure: I built Lynkr, so take this as a technical benchmark write-up, not a neutral industry report. The numbers below come from the same backend providers on both gateways.

If you're routing AI coding traffic through a gateway, just switching providers is not enough. The real savings come from reducing the tokens that ever reach the model in the first place.

I ran Lynkr and LiteLLM against the same backends — Ollama locally, Moonshot, and Azure OpenAI — across 9 scenarios. On the scenarios that actually look like agentic coding work, Lynkr was cheaper because it does three things before forwarding the request upstream: smart tool selection, TOON compression, and semantic caching.

The short version

Lynkr was measurably better on the cost-sensitive parts of the workload:

Smart tool selection: 53% fewer input tokens, 52% lower cost
TOON JSON compression: 87.6% fewer billed tokens on a large tool result, 50% lower cost
Semantic cache: 171ms cache-hit response vs 3,282ms on the repeat query path
Tier routing: escalated hard prompts to stronger models instead of blindly sending everything to the cheapest route

Area	Lynkr result	Why it mattered
Tool selection	53% fewer tokens	Removes irrelevant tool schemas
TOON compression	87.6% fewer tokens	Shrinks large JSON tool outputs
Semantic cache	171ms cache hit	Avoids repeat model calls
Tier routing	Escalates hard prompts	Doesn’t over-optimize for cheapest path

This matters if you're running Claude Code, Codex, Cursor, or similar agent workflows where tools, file reads, grep output, and repeated context dominate your token bill.

Setup

Same benchmark inputs, same providers, same request shape.

Machine: macOS on Apple Silicon
Lynkr: v9.3.2 on Node 20
LiteLLM: v1.87.1 on Python 3.12
Backends used: Ollama local, Moonshot, Azure OpenAI
Scenarios: 9 total across simple prompts, tools, history, cache, and routing

Each scenario sent the same HTTP request to both gateways at POST /v1/messages.

Where Lynkr wins

1) Smart tool selection

A lot of coding requests are read-only, but the model still gets handed the full tool universe: write, edit, bash, git, file ops, everything.

Lynkr classifies the request first and strips irrelevant tool schemas before forwarding upstream. So a read-only question does not pay to carry write-capable tools.

Benchmark setup: 14 tool definitions attached to every request, which is pretty realistic for a Claude Code or Cursor style session.

Lynkr: 959 billed input tokens, $0.0044
LiteLLM: 2,085 billed input tokens, $0.0091

Result: 53% fewer input tokens and 52% lower cost on the same model and prompt.

This is the kind of optimization that compounds because it happens before every downstream model call.

2) TOON compression for tool results

Tool-heavy workflows often blow up because of structured JSON, not because the user wrote a long prompt.

Lynkr's TOON path compresses large JSON payloads before they hit the provider. Plain text goes through unchanged. The useful effect is that file reads, grep arrays, tool traces, and other structured outputs stop dominating the request.

Benchmark setup: a Bash tool returning 60 grep results as a JSON array, roughly 3,400 tokens unoptimized.

Lynkr: 427 billed input tokens, $0.009, 12s latency
LiteLLM: 3,458 billed input tokens, $0.018, 12s latency

Result: 87.6% token reduction and 50% lower cost at the same latency.

That last part matters. This was not a tradeoff where cost improved because the request got slower. Compression happened in-process and the wall-clock result stayed flat.

3) Semantic cache

The easiest cheap request is the one that never reaches the model.

Lynkr computes embeddings for the incoming prompt and returns a cached response when a semantically similar request shows up again. In the benchmark, the second prompt was just a paraphrase of the first:

"Explain TCP vs UDP"
"What is the difference between TCP and UDP?"

Cold run vs cache hit

Lynkr cold: 2,857 tokens, 1,891ms
Lynkr cache hit: served from cache in 171ms
LiteLLM repeat path: 54 tokens, 3,282ms

The important part is not just token avoidance. The response time dropped from 1.9s to 171ms, about 11x faster.

For interactive tooling, that difference is felt immediately.

4) Tier routing that looks at complexity, not just price

LiteLLM has routing. But in this benchmark configuration it was using cost-based-routing, which means the gateway optimizes for cheap first.

That works for simple questions. It breaks when the prompt genuinely needs a stronger model.

Lynkr scores requests across 15 dimensions — token size, reasoning markers, code complexity, risk signals, and agentic traits — then routes automatically.

In the benchmark:

Simple prompt: "What does git stash do?"
- Lynkr routed to minimax-m2.5
- LiteLLM routed to local Ollama
Complex prompt: JWT vs cookies security analysis for a banking architecture
- Lynkr escalated to moonshot-v1-auto
- LiteLLM still sent it to local Ollama

That is the difference between "cheap by default" and "cheap when appropriate."

Why this benchmark matters more than a generic proxy comparison

A lot of gateway comparisons collapse into "who can talk to more providers." That is table stakes now.

The more important question is:

What does the gateway do to reduce spend before the request hits the model?

That is where Lynkr is different in practice.

It stacks three cost levers:

Tool pruning so irrelevant tool schemas do not ride along
TOON compression so large structured tool output stops inflating prompts
Semantic cache so repeated or near-repeated requests do not call the model again

Then it adds tier routing on top, so the remaining requests go to the right model for the job.

That stack is why the benchmark result is interesting. It is not just "Lynkr can route too." It is that Lynkr changes the size and shape of the request before routing even happens.

Cost projection at 100,000 requests/month

Using the large JSON tool-result test as a representative tool-heavy scenario:

LiteLLM: about $818/month
Lynkr: about $409/month

So on equal footing, same backend, same model class, Lynkr came out roughly 50% cheaper.

That is the distinction I'd care about if I were evaluating an LLM gateway for coding agents. Not whether the gateway has another provider adapter, but whether it reduces the number of tokens my provider ever sees.

What about Portkey?

Portkey is good at a different layer of the stack.

It is stronger on managed observability, prompt management, and governance. But this benchmark was not measuring dashboarding or policy UX. It was measuring request-path optimization.

On that axis, Lynkr is doing something Portkey does not really center on:

automatic complexity detection
semantic caching
token compression
drop-in routing for coding-tool workloads

So I would not frame this as "Portkey but cheaper." They solve different primary problems.

Important caveats

To keep this honest, there are a few things worth stating clearly.

1) This is not a neutral benchmark

I built Lynkr. So the burden is on me to be explicit about methodology and where the numbers come from.

2) LiteLLM can look cheaper in headline totals

If LiteLLM routes everything to a free local model, the raw total can look lower. But that is not the useful comparison.

The fair comparison is same backend, same prompt, same model class. On those apples-to-apples paths, Lynkr was cheaper because it sent fewer tokens upstream.

3) Lynkr adds system-level context

In this benchmark, Lynkr injected a system prompt with memory and agent instructions, which added about 2,800 tokens of overhead in some scenarios. That is why comparing estimated raw request size to billed tokens can be misleading.

The correct comparison is billed tokens between Lynkr and LiteLLM on the same scenario.

Who this is for

Lynkr is for teams running things like:

Claude Code
Codex
Cursor
Hermes
custom agents using an OpenAI-compatible endpoint

If your real problem is reducing spend on coding workflows without rewriting client-side integrations, the benchmark result is pretty simple:

Lynkr wins when the workload includes tools, structured outputs, repeated prompts, and mixed-complexity requests.

That is exactly what real coding-agent traffic looks like.

Reproducibility

The benchmark script is reproducible from the Lynkr repo root:

node benchmark-tier-routing.js

Versions used in this run:

Lynkr v9.3.2
LiteLLM v1.87.1

Final takeaway

If all you want is a gateway that forwards requests, Lynkr is not interesting.

If you want a gateway that makes coding traffic cheaper before it reaches the model, that is where Lynkr starts to separate.

The three levers that mattered in this benchmark were:

tool selection
TOON compression
semantic cache

And on top of that, tier routing kept the hard prompts from being sent to the wrong model just because it was cheaper.

If you want to dig into it, the repo is here:

GitHub: https://github.com/Fast-Editor/Lynkr

If you test it against your own coding workload, I would genuinely like to know where it holds up and where it doesn't.

How a Gateway Layer Could Reduce LLM Costs in TradingAgents

Lynkr — Tue, 02 Jun 2026 23:02:53 +0000

Multi-agent AI systems are impressive, but they can also become expensive fast.

That’s especially true for projects like TradingAgents, where multiple agents may gather information, summarize findings, compare signals, and synthesize outputs before arriving at a final result.

The instinctive way to build systems like this is simple: use one strong model for everything.

It works — but it’s often wasteful.

That’s where a gateway layer starts to matter.

The real problem isn’t model cost — it’s overprovisioning

When people talk about LLM cost in agent systems, they often focus on the price of the “main” model.

But in practice, the bigger issue is usually overprovisioning.

A multi-agent system often sends many different kinds of tasks through the same premium model:

intermediate summaries
lightweight transformations
retrieval-adjacent reasoning
orchestration steps
final synthesis

Those tasks don’t all need the same level of capability.

And once every step uses the most expensive model in the stack, costs rise much faster than they need to.

That’s not a criticism of TradingAgents specifically. It’s a common pattern in multi-agent design.

Why TradingAgents is a good example

TradingAgents is exactly the kind of system where this matters.

A workflow like this usually contains several layers of work:

collecting or interpreting market information
comparing different signals or perspectives
generating intermediate summaries
combining outputs into a final view

Some of those steps are relatively lightweight.

Some are more reasoning-heavy.

Some likely matter more for output quality than others.

That creates a natural opportunity: not every step has to run on the same model tier.

What a gateway layer changes

A gateway layer sits between the application and the underlying model providers.

Its job is not to “make the model better.”

Its job is to give the system more control over where different requests go.

In a setup like TradingAgents, that could mean:

lightweight summarization goes to a cheaper model
intermediate analysis goes to a balanced mid-tier model
final synthesis or high-stakes reasoning goes to a stronger premium model

That’s the key idea.

The savings do not come from magic.

They come from routing tasks based on complexity instead of defaulting everything to the same expensive backend.

Where cost savings might actually come from

The interesting thing about systems like TradingAgents is that a lot of model usage may happen before the “final” answer is even produced.

If multiple agents are:

reading inputs
generating their own interpretations
refining intermediate outputs
exchanging context
contributing to a final synthesis

then the system can accumulate a large number of calls very quickly.

If all of those calls hit the same premium model, the cost profile becomes hard to justify.

A gateway layer helps by letting you separate:

cheap, repeatable steps
moderately complex reasoning
high-value final decision steps

That gives you a more rational stack.

If a large share of the workflow is made up of summarization, orchestration, and intermediate transformations, then routing those steps to cheaper models could produce substantial savings.

The exact percentage depends on:

how many agents are involved
how often they call models
prompt sizes
context sizes
whether outputs are recursive or chained
which steps truly need premium reasoning

The real insight is:

multi-agent systems create natural routing opportunities, and those opportunities often go unused.

This is where a gateway layer like Lynkr becomes relevant.

Lynkr is useful in this kind of stack because it can make the model layer more flexible without forcing the application to be rewritten around one provider.

That means systems like TradingAgents can potentially:

route cheaper tasks to lower-cost models
reserve premium models for the hardest reasoning steps
swap providers without changing the whole application layer
mix local, cloud, or enterprise backends more cleanly
introduce fallback behavior if one backend is slow or unavailable

That makes the architecture more practical, not just cheaper.

The bigger takeaway

The point is not that TradingAgents is “too expensive” or designed incorrectly.

The point is that multi-agent systems naturally create different classes of work, and those classes should not automatically be priced the same.

A gateway layer is valuable because it introduces policy into the model layer:

which tasks go where
which tasks deserve premium reasoning
which tasks can be handled more cheaply
how the system behaves when one provider fails

That’s a much more durable idea than simply trying to find the single “best” model.

Final thought

TradingAgents is a useful example because it shows how quickly multi-agent systems can compound model usage.

Once multiple agents are generating intermediate work before a final result, using one expensive model for everything becomes the easy default — but not always the right one.

That’s why a gateway layer matters.

Not because it magically reduces costs.

But because it gives systems like TradingAgents a way to stop overpaying for the parts of the workflow that don’t need premium intelligence in the first place.

How to Self-Host UI-TARS Desktop Without Vendor Lock-In

Lynkr — Tue, 02 Jun 2026 05:27:44 +0000

The next interesting wave of AI tools isn't just about coding assistants.

It's about agents that can actually operate software.

That's why UI-TARS Desktop is worth paying attention to. It's an open-source multimodal desktop agent from ByteDance's broader TARS ecosystem, designed around a simple but powerful idea: let an AI agent see the interface, understand what's on screen, and interact with the computer like a user would.

After looking through the GitHub repo, the positioning is pretty clear. UI-TARS Desktop is a native GUI agent with support for:

local and remote computer operators
browser operators
screenshot-based visual understanding
mouse and keyboard control
cross-platform usage
a broader agent stack that connects vision, GUI actions, and MCP-style tool integrations

That already makes it interesting.

But the part that matters most for real-world use is what sits underneath it: the model layer.

And that's where Lynkr becomes useful.

Desktop agents are powerful — and expensive to get wrong

Desktop agents are a different category from coding copilots.

A coding tool mostly works inside text: source files, terminals, prompts, diffs.

A desktop agent has to deal with:

screenshots
dynamic UI state
clicking the right target
retrying after failure
latency between action and feedback
reasoning over visual context
sometimes switching between browser and desktop flows

That means the model setup matters a lot.

If the backend is too weak, the agent makes bad decisions.

If it's too expensive, experimentation becomes painful.

If it's tied to one provider, the whole stack becomes brittle.

For teams trying to use tools like UI-TARS Desktop seriously, the bottleneck is not just "is the model smart enough?"

It's also:

can we run it locally when needed?
can we swap providers without rewriting the setup?
can we use cheap models for lighter tasks and stronger ones for harder steps?
can we fit this into enterprise infra without locking into a single vendor?

That is exactly the kind of problem Lynkr is built for.

What Lynkr adds beneath UI-TARS Desktop

Lynkr's core value is straightforward: it acts as a universal LLM gateway for AI tools.

Instead of tying one tool to one provider, Lynkr makes it possible to route requests across different model backends while keeping the tool-facing interface stable.

That matters a lot for a desktop agent stack.

A UI-TARS Desktop + Lynkr setup could make it possible to:

test different providers without changing the whole workflow
use local models for cheaper experimentation
route more difficult reasoning steps to stronger cloud models
keep enterprise traffic inside approved backends like Bedrock, Azure, or Databricks
reduce provider lock-in as the desktop agent ecosystem evolves

In other words: UI-TARS Desktop gives you the agent interface, and Lynkr gives you the model control plane.

That's a much better architecture than hardwiring one expensive model setup into a fast-moving agent product.

Why this matters more for multimodal agents

The more multimodal a tool gets, the more useful backend flexibility becomes.

How Lynkr Fits Under UI-TARS

The cleanest mental model is:

UI-TARS Desktop / Agent TARS

→ Lynkr

→ Ollama, OpenRouter, Bedrock, Azure, Databricks, OpenAI, or another backend

That gives you one stable endpoint for the agent layer while keeping the actual model choice flexible.

At a high level, the goal is to point UI-TARS or Agent TARS at Lynkr instead of binding the stack directly to a single vendor.

In practice, that usually means configuring:

a custom model endpoint or base URL
a model name that Lynkr can route internally
an API key placeholder or Lynkr-managed credential path

If the runtime supports an OpenAI-compatible endpoint, the setup conceptually looks like this:

OPENAI_BASE_URL=http://localhost:8081/v1
OPENAI_API_KEY=dummy
MODEL=gpt-4o

Lynkr can then translate and route that request to the provider you actually want to use.

That setup makes it easier to:

run cheaper local models during experimentation
send harder multimodal tasks to stronger cloud models
avoid rewriting agent config every time you change providers
keep traffic inside enterprise-approved infrastructure
add fallback behavior when one provider is degraded

One important caveat: the exact configuration path depends on whether UI-TARS Desktop or Agent TARS exposes a custom compatible endpoint directly, or only vendor-specific settings. So this is best understood as the intended integration pattern unless you validate the exact runtime path in a live setup.

A desktop agent doesn't just answer a question. It has to perceive, decide, act, and recover.

Some steps need raw speed.

Some need stronger reasoning.

Some may need privacy or local execution.

Some may need enterprise compliance.

A single-model strategy is often the wrong fit.

That's why a gateway layer matters more here than it does for a simple chatbot.

With a Lynkr-style routing layer, you can imagine:

lighter steps going to cheaper or local models
harder planning steps going to stronger reasoning models
fallback behavior when one provider degrades
fast experimentation across multiple backends as UI-TARS evolves

That makes desktop agents much more practical to run, not just more impressive in a demo.

UI-TARS Desktop points to a bigger shift

The most interesting thing about UI-TARS Desktop is that it represents a shift in what users expect from AI.

People are moving from:

"answer my question"

to:

"operate the software for me"

That's a much bigger leap than most AI product copy admits.

Once an agent is controlling browsers, settings panels, apps, and workflows, the underlying infrastructure starts to matter a lot more:

latency matters
cost matters
control matters
provider flexibility matters
observability and fallback matter

That's why tools like UI-TARS Desktop and Lynkr feel complementary.

One is pushing upward into computer use.

The other is stabilizing the messy model layer underneath.

That combination is more interesting than either product in isolation.

Why this is a strong direction for Lynkr

Lynkr already makes sense as a universal LLM gateway for coding tools.

But tools like UI-TARS Desktop suggest a bigger opportunity.

The next generation of AI products won't just be IDE assistants. They'll include:

desktop agents
browser agents
multimodal workflow tools
hybrid systems that combine GUI interaction with tool use and automation

Those tools are going to need:

model portability
cost optimization
fallback routing
local/cloud flexibility
enterprise-friendly deployment paths

That's a very natural place for Lynkr to sit.

Not as the flashy top-layer app.

As the infrastructure that makes those apps more usable.

Final thought

UI-TARS Desktop is interesting because it pushes AI beyond text and into direct computer interaction.

Lynkr is interesting because it makes the model layer behind those interactions more portable, flexible, and cost-aware.

Put them together, and the story is bigger than just "support another tool."

It becomes a real argument for why desktop agents should not be locked to a single provider stack.

And honestly, that feels like the right direction for this whole ecosystem.

References

UI-TARS Desktop GitHub repo: https://github.com/bytedance/UI-TARS-desktop
UI-TARS model repo: https://github.com/bytedance/UI-TARS
Agent TARS quick start: https://agent-tars.com/guide/get-started/quick-start.html
Agent TARS introduction/docs: https://agent-tars.com/guide/get-started/introduction.html
UI-TARS Desktop quick start: https://github.com/bytedance/UI-TARS-desktop/blob/main/docs/quick-start.md
UI-TARS Desktop SDK docs: https://github.com/bytedance/UI-TARS-desktop/blob/main/docs/sdk.md
Lynkr GitHub repo: https://github.com/Fast-Editor/Lynkr
Lynkr docs: https://fast-editor.github.io/Lynkr/

🐍 How to Use Open Interpreter for Free — With the Latest Models

Lynkr — Sun, 31 May 2026 06:54:52 +0000

The GPT-4 Code Interpreter You Can Actually Own — And Run for Free

If you've ever used ChatGPT's Code Interpreter (now "Advanced Data Analysis"), you know the feeling: "This is incredible... but why can't I run it locally? Why can't I install my own packages? Why do files disappear after 2 hours?"

Open Interpreter fixes all of that. It's the open-source version of what ChatGPT's Code Interpreter should have been — and it runs on your machine, with your data, for as long as you want.

But there's always been one painful trade-off:

Cloud models (GPT-4o, Claude Sonnet) → fast and smart, but costs add up fast
Local models (Ollama, Qwen) → free, but slow and less capable

What if you could have both — latest models, near-zero cost?

That's what this guide covers. Let me show you how.

What Is Open Interpreter?

Open Interpreter (53k★ GitHub) gives LLMs a natural-language interface to your entire computer. Install it with one command:

pip install open-interpreter
interpreter

Now you can say things like:

"Analyze this CSV, find outliers, build a dashboard, and email it to me."

And it will — writing Python, running shell commands, installing packages on the fly, and showing you the results, all in real time.

What Makes It Special vs ChatGPT Code Interpreter

Capability	ChatGPT Code Interpreter	Open Interpreter
Internet access	❌ No	✅ Full access
Custom packages	❌ 300 pre-installed only	✅ Any pip/npm/shell package
File size limit	100 MB upload limit	✅ Unlimited
Runtime limit	2 minutes max	✅ Unlimited — runs until done
Your data stays local	❌ Uploaded to OpenAI	✅ Everything runs on your machine
Model choice	GPT-4o only	✅ Any model — local or cloud

Real Things You Can Do With Open Interpreter

1. Data Analysis That Actually Finishes

interpreter.chat("Download my last 6 months of Stripe transactions,
clean the data, find churn patterns, and build a retention dashboard")

It runs Python, Pandas, Plotly — no runtime limit, no upload cap. Your data never leaves your machine.

2. Full System Automation

"Find all duplicate files over 100MB in ~/Downloads,
ask me before deleting each one, then log what I chose"

It can browse directories, run bash, and ask for confirmation before destructive operations.

3. Multi-Step Research Pipelines

"Scrape the top 10 HN posts about AI agents,
summarize each, then save a markdown report"

Browser control + Python + file I/O — chained together in one conversation.

4. Video/Photo Processing

"Extract audio from every .mp4 in this folder,
transcribe it with Whisper, then save transcripts"

It installs ffmpeg, whisper, whatever it needs — no manual setup.

The Problem: Free Models Are Slow, Paid Models Are Expensive

Open Interpreter is token-hungry by nature. Every multi-step task generates a long conversation:

The model proposes a plan → tokens
It writes code → tokens
The output comes back → tokens
It iterates → more tokens
It hits an error and fixes it → even more tokens

A single analysis session can burn 50,000–200,000 input tokens.

Option A: Use GPT-4o / Claude Sonnet Directly

You get speed and quality — but at full retail price. A 30-minute session costs $1-3. Do this daily and you're spending $60-90/month on one tool.

Option B: Run Locally With Ollama (The "Free" Way)

interpreter --local

This is truly free — but painfully slow. A local Qwen 2.5-Coder 14B takes 15-30 seconds per response. For Open Interpreter's interactive back-and-forth loop, that kills the flow.

Worse: local models just can't handle complex multi-step tasks as reliably. The analysis I described earlier? It breaks down on a 14B model.

The Solution: Latest Models, Almost Free

Lynkr is an open-source LLM gateway that solves this exact problem. It lets you use the latest and best models — DeepSeek V4, Claude Sonnet 4.5, Gemini 2.5 Pro, GPT-5.5 — while paying 80-90% less.

Open Interpreter uses LiteLLM under the hood, so pointing it at Lynkr is trivial:

interpreter --api_base "http://localhost:3000/v1" --api_key "anything"

That's it. Here's what Lynkr does behind the scenes.

How Lynkr Makes Open Interpreter Free (Almost)

1. Tier Routing: Smart Models for Smart Work

Not every Open Interpreter step needs GPT-5.5. Listing files? Go to DeepSeek V3 (free). Writing a Python script? Use Sonnet 4.5 or GPT-5.5.

Lynkr automatically routes each request to the cheapest capable model:

Simple tasks (ls, grep, file ops) → GPT-4o Mini / Gemini Flash / DeepSeek V3 ($0-0.15/M)
Code generation → DeepSeek V4 / Sonnet 4.5 ($1-3/M)
Complex reasoning → GPT-5.5 / Opus 4.5 ($10-15/M — but only used when actually needed)

Result: That $2.40 naive GPT-4o session? Drops to $0.30-0.50.

2. Prompt Caching: Don't Pay Twice for the Same Work

Open Interpreter repeats the same system context on every turn. Lynkr's Semantic Cache detects repeated prompts and returns cached results.

For batch operations like "process file X in folder Y" — where only the filename changes between calls — cache hit rate hits 60-70%. That's real money staying in your pocket.

3. Local Fallback: Never Get Stuck

Rate limited on OpenAI? Key expired? Lynkr automatically fails over to Ollama or another working provider:

# Same config — just works
interpreter --api_base "http://localhost:3000/v1"

No crashes, no context loss, no retyping your request.

4. MCP Code Mode: Fewer Retries = Less Tokens

Lynkr reformats code prompts to produce cleaner output. Fewer syntax errors → fewer retries → fewer tokens burnt on error recovery. Each retry avoided saves 3,000-10,000 tokens.

Before vs After: Real Cost Breakdown

Session Type	Naive GPT-4o	Lynkr (Tier Routing + Cache)
1-hour data analysis	~$2.40	~$0.35-0.60
Batch file processing (100 files)	~$3.50	~$0.12-0.30
Multi-step research pipeline	~$5.00	~$0.60-1.00
Daily use for a month	~$75-150	~$10-20

That's 85-95% cheaper — and you're using better models than GPT-4o alone.

Setup: Open Interpreter + Lynkr in 3 Minutes

1. Install Lynkr

npx lynkr@latest

It auto-detects your setup, creates a config, and starts the proxy on port 3000.

2. Install Open Interpreter

pip install open-interpreter

3. Point Open Interpreter to Lynkr

interpreter --api_base "http://localhost:3000/v1" --api_key "anything"

Done. Open Interpreter now routes through Lynkr — latest models, tiered routing, prompt caching, local fallback.

What About the Latest Models Specifically?

Here's the models you can route through today with Lynkr + Open Interpreter:

Model	Best For	Cost via Lynkr
DeepSeek V4	Code gen, multi-step reasoning	~$0.50/M tokens (cheapest top-tier)
Claude Sonnet 4.5	Balanced code + analysis	~$3/M tokens (used sparingly via tier routing)
GPT-5.5	Complex debugging, architecture	~$15/M tokens (only for hard steps)
Qwen 3-Coder 32B (local)	Freefall backup	$0 (via Ollama)
Gemini 2.5 Pro	Fast code, vision tasks	~$1.25/M tokens
GPT-4o Mini / DeepSeek V3	Simple file ops	$0-0.15/M tokens

Lynkr picks the right one per step automatically. You don't think about it.

The Bottom Line

Open Interpreter is the most underrated open-source AI tool of 2026. It does what ChatGPT Code Interpreter promised — but on your machine, with your data, at any scale.

The old trade-off was: use GPT-4o and pay up, or use a local model and deal with the slowness.

With Lynkr that trade-off is gone. Latest models. Intelligent routing. Local fallback. 85-95% cost savings.

You can run Open Interpreter for essentially free — with models that beat GPT-4o.

Built with Lynkr — the open-source LLM gateway that makes every AI tool cheaper. Drop a ⭐ if this helped. ⚡

How I Cut Aider's Token Bill 80%: Prompt Caching, MCP Code Mode, and Tier Routing

Lynkr — Sat, 30 May 2026 15:56:21 +0000

Aider is the best terminal AI coding tool I've used. But by default it sends every diff through your OpenAI or Anthropic key, which gets expensive fast on real refactors — a single 100-file repo map can torch a few dollars before Aider even reads your prompt.

This post shows how to run Aider against any LLM provider — Ollama for free local runs, OpenRouter for mixed-provider routing, AWS Bedrock for the enterprise plate — through a single OpenAI-compatible endpoint, with prompt caching and MCP Code Mode layered on top to slash the bill further. I'll use Lynkr, the self-hosted gateway I maintain.

Full disclosure: I build Lynkr. I'm going to make the case for why the combination — gateway + caching + code-mode tools — is the real cost lever, not just "swap your provider."

The setup in three commands

# 1. Start the gateway
npx lynkr@latest

# 2. Point Aider at it
export OPENAI_API_BASE=http://localhost:8081/v1
export OPENAI_API_KEY=any-value

# 3. Run Aider with any model name Lynkr knows about
aider --model claude-sonnet-4-5

That's it. Aider speaks the OpenAI Chat Completions protocol; Lynkr speaks it back and quietly translates the call to whichever upstream provider you've configured (Ollama, Bedrock, Anthropic, Azure, OpenRouter, Databricks, llama.cpp, LM Studio, ...). Aider has no idea it's talking to a router.

Where the money actually leaks in Aider

Most "save money on AI coding" posts focus on swapping GPT-4o for a cheaper model. That's table stakes. The real spend in an Aider session breaks down roughly like this:

Call type	Share of total tokens	Where it goes
Repo map (system context, sent every turn)	~50–60%	Same prefix, every single request
File contents you've /add'd	~20–30%	Same prefix until you change the files
The actual diff / instruction	~5–10%	Genuinely new each turn
Commit messages, summarization	~5%	Cheap model anyway

Look at that table. Most of your Aider bill is the same bytes being re-sent over and over. Swapping models helps a little. Caching that repetitive prefix helps a lot.

Lever 1: Prompt caching — cuts the repeated-prefix tax

Anthropic, Bedrock, Gemini, and OpenRouter all support prompt caching now, but Aider doesn't speak any of their cache-control protocols natively (it speaks one — OpenAI's — and only partially). Lynkr sits in the middle and injects cache_control: ephemeral breakpoints on the right blocks before forwarding upstream.

What that means in practice: the second Aider request in a session — same repo map, same /added files — only pays for the few hundred tokens of new instruction. Cached input tokens are 10% the price of fresh input on Anthropic, 25% on Bedrock, free for 5 minutes on Gemini.

On a 4-hour Aider session against Claude Opus 4 or GPT-5, this single lever has cut my own input bill by ~70% before I even start tier-routing.

Lynkr enables it automatically when the upstream provider supports it. No Aider config change.

# .env
MODEL_PROVIDER=anthropic
ANTHROPIC_API_KEY=sk-ant-...
PROMPT_CACHE=true    # default on, but explicit is good

Lever 2: MCP Code Mode — collapse N tool calls into 1

Aider doesn't use tool calls itself (it parses code blocks from plain Markdown). But the moment you start composing Aider with other MCP tools — file search, web fetch, sandboxed execution — the round-trip cost explodes. Every tool call is a full request/response cycle through the LLM.

Lynkr's MCP Code Mode (borrowed from Cloudflare's pattern) flips this. Instead of advertising each MCP tool as a separate function the model can call, Lynkr exposes them as a small TypeScript API that the model writes a single program against. The program runs in a sandbox, hits all the tools it needs, and returns the result in one LLM round trip.

Example: "find every file that imports redis, check if any still use the v3 API, and print a migration TODO list."

Tool-call mode (default everywhere else): 5 file_search calls + 12 file_read calls + 1 grep call = 18 round trips. Each round trip re-sends the conversation history.
MCP Code Mode (Lynkr): model writes ~20 lines of TS using mcp.fileSearch() and mcp.fileRead(), executes once, returns the result.

For coding-heavy sessions where Aider is composed with other MCP tools, this is a 5–15x reduction in tokens spent on tool plumbing.

Lever 3: Tier routing — match model to task

Aider's own polyglot leaderboard in May 2026:

Model	% correct	Copilot cost ratio
Claude Opus 4.5	89.4%	3×
GPT-5 (high reasoning)	88.0%	1×
o3-pro (high)	84.9%	—
Gemini 2.5 Pro (32k think)	83.1%	1×
Claude Sonnet 4.5	82.4%	1×
Claude Opus 4.1	82.1%	10×
Grok 4 (high)	79.6%	—
DeepSeek V3.2 Reasoner	74.2%	—
Claude Haiku 4.5	73.5%	0.33×
GPT-4o	72.9%	0×
Claude Opus 4.5 (no-think)	70.7%	3×
DeepSeek V3.2 Chat	70.2%	—

Two things actually worth knowing:

Claude Sonnet 4.5 at 82.4% is the practical pick. It's within 7 points of the absolute top at 1× Copilot pricing — i.e. one-third the cost of Opus 4.5 for ~92% of the capability.
DeepSeek V3.2 Reasoner at 74% is the budget workhorse. Costs a fraction of any Claude tier, still beats GPT-4o on Aider's own bench.

You don't need Opus 4.5 to rename a variable. You need Sonnet 4.5 for almost everything, Opus 4.5 for the hardest 10% (multi-file architecture, refactor planning), and Haiku 4.5 or local Ollama for the trivial 30% (commit messages, repo map summarization).

Lynkr's tier routing splits the work by prompt complexity:

Aider call type	Routes to	Why
Repo map summarization, commit messages	`qwen2.5-coder:7b` (Ollama, local)	Free, runs on your laptop
Single-file edits, small diffs	`claude-haiku-4.5`	73.5% on Aider, 0.33× Copilot cost
Default coding workhorse	`claude-sonnet-4.5`	82.4% on Aider, 1× Copilot cost
Hardest 10% — architecture, multi-file refactor	`claude-opus-4.5` or `gpt-5`	Used sparingly

# .env additions
TIER_SIMPLE=ollama:qwen2.5-coder:7b
TIER_MEDIUM=anthropic:claude-haiku-4-5
TIER_COMPLEX=anthropic:claude-sonnet-4-5
TIER_REASONING=anthropic:claude-opus-4-5

Then point Aider at --model lynkr-auto and Lynkr scores each prompt before picking the tier.

Stacking the three levers

Each lever on its own is meaningful. Stacked, they compound:

Caching alone: ~70% input-token cut on a stable session
+ Tier routing: another ~40% by pushing routine calls to Flash/Ollama
+ MCP Code Mode (if you compose with other MCP tools): another 5–15x on tool-plumbing tokens

In my own Aider workflow — heavy refactors against a 200k-LOC monorepo — this combination has dropped a session that used to cost ~$8 in Claude calls down to under $1.50. Not because Claude got cheaper. Because most of the work is now happening on cached prefixes, free local models, or in-sandbox code execution.

Configuration walkthrough

Step 1 — Install and start Lynkr

npx lynkr@latest

First run creates a .env file. Minimal config:

MODEL_PROVIDER=anthropic
ANTHROPIC_API_KEY=sk-ant-...
PROMPT_CACHE=true
PORT=8081

For full local + free:

MODEL_PROVIDER=ollama
OLLAMA_ENDPOINT=http://localhost:11434
OLLAMA_MODEL=qwen2.5-coder:latest
PORT=8081

Then ollama pull qwen2.5-coder:latest.

Step 2 — Point Aider at the gateway

export OPENAI_API_BASE=http://localhost:8081/v1
export OPENAI_API_KEY=dummy

Drop those in your shell rc file.

Step 3 — Pick a model (or let Lynkr pick)

# Direct pass-through
aider --model claude-sonnet-4-5

# Or let Lynkr tier-route
aider --model lynkr-auto

Step 4 — Verify

curl -s http://localhost:8081/v1/models | python3 -m json.tool | head

Start Lynkr with LOG_LEVEL=info and watch the cache-hit lines on your second Aider request — that's where the savings show up.

Aider-specific gotchas

Weak model for commits / summarization. Aider uses a cheaper model for non-code calls; default is gpt-4o-mini. Override to a free local one:

aider --model openai/gpt-4o --weak-model ollama/qwen2.5-coder:7b

Long context. Local Ollama models will OOM on 200k+ token repo maps. Either set --map-tokens 0, or route long-context calls to Gemini Flash 1M-token contexts via the TIER_REASONING line above.

Streaming. Aider expects streaming responses. Lynkr streams by default. If you're on a non-streaming Databricks endpoint, set STREAM_PASSTHROUGH=false and Lynkr buffers + simulates.

Cache hit rate. Prompt caching only fires when the prefix is byte-identical across requests. If your repo map changes (you edit a /added file), the cache for that block invalidates and rebuilds. Lynkr logs cache-hit ratios per session — watch them; if hit rate is below 60% something in your workflow is busting the prefix.

Quickref

Aider env var	Lynkr role
`OPENAI_API_BASE=http://localhost:8081/v1`	Where Lynkr listens
`OPENAI_API_KEY=dummy`	Required by Aider, ignored by Lynkr
`--model claude-sonnet-4-5`	Forwarded as-is to the configured upstream
`--model lynkr-auto`	Triggers Lynkr's complexity-based tier routing
`--weak-model ollama/qwen2.5-coder:7b`	Free local model for commit messages

TL;DR

The default Aider setup pays full price for the same repo-map bytes on every turn. The fix isn't "use a cheaper model" — it's:

Cache the repetitive prefix (prompt caching).
Collapse tool plumbing into one call (MCP Code Mode).
Match model size to task complexity (tier routing).

Stacked, those three levers have taken my Aider sessions from ~$8 to ~$1.50 without changing how I work. Lynkr is one gateway that does all three; it's Apache 2.0, single Node binary, drop-in OpenAI base URL.

Aider's GitHub: https://github.com/Aider-AI/aider
Lynkr's GitHub: https://github.com/Fast-Editor/Lynkr — star to follow next integration writeups (OpenHands, Vercel AI SDK, Open Interpreter queued).