One proxy for Claude Code, Codex, and Cursor: is it worth setting up

Short answer: a single proxy in front of every coding agent on your machine is worth setting up once you regularly use more than one of them, or once you have stopped being able to say where last month's API bill came from. The payoff is not routing cleverness. It is that caching, spend caps, and a per-process record of every call get written once instead of three times, and they keep working when you add a fourth tool next quarter.

If you use exactly one agent, on one model, on a flat subscription, skip it. Per-tool config is genuinely enough, and adding an intercepting layer to a working setup buys you a new class of debugging session for no return. The interesting case is the middle: two or three CLIs open at once, a mix of subscription and API billing, and a growing suspicion that a lot of what those agents send is work you already paid for.

What actually breaks when every tool keeps its own config

Each agent CLI has its own way to point at a different endpoint. Claude Code reads an ANTHROPIC_BASE_URL environment variable. Codex CLI takes a custom model provider block in its config file. Cursor lets you override the OpenAI base URL in settings. None of these are hard on their own. The cost shows up in the fact that they are three separate places, with three separate failure modes, and no shared state between them.

Concretely, the things you cannot do with per-tool config, no matter how carefully you write it:

• See one ordered ledger. Each tool reports its own usage in its own units, if it reports at all. Reconciling them against the provider invoice is manual and you will stop doing it by the third month.
• Share a cache. If Claude Code and Cursor both ask for an explanation of the same file within a minute, that is two paid calls, because neither one knows the other exists.
• Enforce a cap that means anything. A per-tool budget is a budget per tool. Three tools with a fifty dollar ceiling each is a one hundred fifty dollar ceiling.
• Attribute a spike. When a bill jumps, the question is which process did it, in which repo, at what hour. No individual CLI can answer that, because the answer spans all of them.
• Change one thing and have it apply everywhere. Switching a cheap first-pass model means editing three configs and remembering the third one exists.

I built a proxy for myself because of the fourth item on that list. I had a week where the bill roughly doubled and I could not tell whether it was an agent stuck in a retry loop, a long-running background task I had forgotten about, or just me working more. That question should take thirty seconds to answer. It took an afternoon of grepping shell history, and I still was not sure.

What a single interception point buys you

Once every agent's traffic passes through one place, a set of optimizations become possible that no individual tool can do for itself, because they all depend on seeing the full stream.

• Exact caching across tools. Byte-identical requests get answered from disk. Agents repeat themselves far more than people expect, especially across restarts of the same task.
• Request coalescing. Two agents firing the same call at the same instant collapse into one upstream request. This happens more often than it sounds when you run parallel subagents on one repo.
• Model tiering as a policy rather than a per-tool setting. Cheap model attempts first, escalate when the answer is weak, and the rule lives in one place.
• Local model routing. If you already have a model warm in Ollama or LM Studio, some fraction of agent traffic is small enough that it never needed to leave the machine.
• A real cost ledger. Model, token counts, actual cost, latency, and which process made the call, all in one table you can sort.

The ledger is the part I would keep if I had to drop everything else. Optimization arguments are only interesting when you can check them afterwards, and almost nobody in this space can check them.

The honest costs of putting a proxy in the path

Four real ones, in rough order of how much they should bother you.

• Certificate trust. Intercepting HTTPS from tools you do not control means installing a local CA certificate. That is a genuine change to your machine's trust store, and you should want to know exactly what is being trusted and be able to remove it.
• A new single point of failure. When the proxy is unhealthy, every agent is unhealthy at once. Anything sitting in this position needs to fail open, passing traffic straight through rather than dropping it.
• Prompt caching interference. Providers cache on exact prefixes. Anything that rewrites, compresses, or reorders a prompt in flight can invalidate a cache the agent was relying on, and you can end up paying more while a dashboard tells you that you saved. This is why I refuse to do prompt compression in Probe0 at all.
• Semantic cache correctness. Fuzzy matching on an agent conversation that carries tool calls is dangerous in a way that chatbot caching is not. A wrong hit does not produce a slightly-off answer, it produces a wrong action against your filesystem.

A cache that is right 97 percent of the time is fine for a support bot and unusable for something that runs shell commands.

Local proxy or hosted gateway

This is the fork that decides most of the answer, and it depends on who you are rather than what the software does.

Hosted gateways are the right pick for teams. Shared keys, org-level budgets, role controls, dashboards several people look at, broad provider catalogs. Portkey, Helicone, and Cloudflare AI Gateway are all solid at this, and LiteLLM gives you a proxy you can self-host with far wider provider coverage than anything focused only on coding agents. If you need one budget across eight engineers, use one of those and stop reading.

For a single developer, the tradeoff inverts. Your agent prompts contain your source code. Sending every one of them through someone else's infrastructure to get a cost chart back is a poor exchange, and it adds a network hop plus a vendor outage to the critical path of your editor. A cache that lives on your own disk has no such hop and cannot leak.

Where Probe0 sits

Probe0 is the local version of this. One proxy plus a certificate installed once, and every coding agent CLI on the machine routes through it with no per-tool configuration after that. There is no Probe0 server; nothing about your traffic leaves the machine unless it was going to a model provider anyway.

Every module is individually switchable and each one reports what it actually saved. Local routing sends work to a model already running in Ollama or LM Studio and auto-retries weak answers on the cloud. Exact caching never touches the network. Semantic caching runs off a local vector index with a strict similarity floor and refuses to match anything carrying tool calls, for the reason above. Spend Guard holds a hard cap per run and per day, warning first and pausing after. Recording keeps the full ledger, including which process made each call, which is what lets the plan-tier advice tell you when you are paying for a tier above what you use.

The limits are real and I would rather you hear them now. macOS only, private beta. It is a single-developer tool, not a team gateway with shared budgets and role controls. Provider coverage is what coding agents actually call, not a catalog of a hundred backends. The account system is new, and sign-in is Google or GitHub only.

So: one agent, one model, one subscription, no proxy. Several agents, API billing, and no idea where the money goes, and a local proxy pays for its setup within a week, mostly through the ledger rather than the caching. Set the cap first, watch the recording for a few days before you turn any optimization on, and only then decide which modules are earning their place.