Stop rationing your AI agents

Every dev with an OpenAI or Anthropic API key has had the same moment. You look at the bill from the month you actually shipped something, and you decide, quietly, to run fewer agents next month.

That's rationing. It's the wrong instinct. The instinct came from paying flagship rates for tasks that didn't need flagship models. Route through Reality Router and the reason to ration goes away.

What we measured

Over the past two weeks I ran eighteen real agent workloads on my home lab through Reality Router: email triage, receipt extraction, PDF form filling, PR review, vision, long-context document analysis, blog cross-posting, and a class-action settlement claim. Every one of them was a task an actual person would do. Every one produced a real artifact you can inspect.

Cost across all eighteen: about fifty cents. Average per task: $0.028.

$200 of RR spend at that rate gets you 7,140 completed agent tasks in a month. Same eighteen tasks, priced at what a direct API bill would have looked like at each vendor's low tier and flagship tier:

The chart

Enlarge

What smart routing is actually doing

Start with the two flagship bars. GPT-5 direct gets you 800 tasks per $200. Fable 5 direct gets you 85. Those are the numbers if you send every one of the 18 agent turns in every workload through OpenAI's top tier or Anthropic's top tier. Most of those turns don't need it, and you're burning flagship dollars on trivial planning steps.

Now look at the two low-tier bars. GPT-5-mini gets you 4,000. Haiku 4.5 gets you 1,200. Way better on cost. But now you're doing the opposite mistake: sending complex agent turns that actually need Opus 5 or Fable 5 through a model that can't handle them. Those turns fail silently, or produce garbage the agent has to work around, or you notice the answer's wrong and re-run the whole thing at Sonnet or Opus anyway. The apparent savings evaporate the moment your GPT-5-mini answer isn't good enough.

That's the trap of self-picking a single model. You can't win. If you default to a flagship, you overpay on every routine call. If you default to a low-tier, you underdeliver on every hard call. If you try to pick per-call yourself, you're guessing before you've even seen the task, and you're doing it at your speed, not the agent's.

Now look at RR. Seventy-one hundred and forty. Same models available underneath, same 18 workloads, same token counts. The difference is that RR decides per call based on the specific task in front of it. When the call can drop to a $0.14/M-input model like DeepSeek Flash with no loss of quality, it does. When the call actually needs Opus 5 or Fable 5, it uses them. You get the price of the cheap tier for the calls that can handle it and the quality of the flagship tier for the calls that need it. Both, without you thinking about it.

No human picking models by hand matches that per-call. You don't have time to look at every agent turn before it fires. The router will always do a better job than you can, because it sees each call the moment it happens and has a calibrated probability score for every candidate model, and it uses that math instead of your guess. Doing this across the seven-to-twenty agent calls a single task takes, the compounding produces a 70x cost reduction on the routine turns with no compromise on the hard ones.

Put the router in front of what you already have

RR speaks the OpenAI protocol. Anything that already speaks that protocol points at RR by changing one URL. That includes:

• OpenCode — one config change and every OpenCode call routes through RR
• Aider, Cursor, Continue, Cline, Zed, any other OpenAI-compatible client — same story
• Your own Python or Node code using the OpenAI SDK — one base_url change and you're routing

You don't rewrite your agent. You don't switch IDE. You don't learn a new framework. You point the base URL at your RR instance and every call your agent already makes now goes through the router.

The API keys you already have (OpenAI, Anthropic, DeepSeek, Google) go into RR's config. Or you use one OpenRouter key and RR routes across OpenRouter's catalog for you. Either way, the code that was calling api.openai.com/v1 is now calling your-rr-host/v1 and everything else works the same.

Why any other router will lose on routing quality

There's a technical point that matters beyond price: RR routes on RealitySignal.

Every other router in production today either doesn't route at all (OpenRouter's default behavior is passthrough — you tell it which model to use) or uses a static heuristic (Diamond, Sapiom, the vendor-specific ones). RR is different. Every routing decision is made against real-time calibrated probability scores of each candidate model's likelihood of succeeding on the specific task in front of it. Those probabilities come from RealitySignal, which continuously calibrates against actual outcomes. The router gets better the more you use it.

No hard-coded heuristic can beat a system that's calibrating itself against real workloads in real time.

Combine that with the pricing above: RR routes cheaper and routes smarter. Any other router you might choose can match one, not both.

And underneath all of it, RR is the only truly open-source router in this category. Every closed-SaaS competitor could deprecate a model, change pricing, or shut down tomorrow. RR is a container you run yourself. Your API keys stay yours. The routing policy is code you can read. The model catalog is a config file you edit.

Try it yourself

Reality Router is open source. Point OpenCode, Aider, Cursor, or your own agent code at it. Add the API keys you're already paying for. See what your bill looks like when the router is actually routing, and calibrating against real outcomes.

Then stop rationing.

→ realityrouter.dev

Chart data sourced from Anthropic's and OpenAI's published API pricing, and eighteen agent workloads measured on Reality Router during August 2026. Direct API bars scaled from measured per-task token counts (~111k input / 11k output average) at each model's per-token rate. Vendor-tier selection: one low-priced model and one flagship per vendor.