Running Claude Code, Codex, and Cursor together: what it costs

If you use Claude Code, Codex, and Cursor on the same machine, you have three separate billing relationships and no shared ledger between them. Each tool tracks its own usage in its own dashboard, on its own schedule, with its own definition of a 'request.' The direct answer to what this costs: it's the sum of whatever each subscription or API bill charges, but almost nobody can actually produce that sum on demand, because nothing on the machine sits below all three tools at once.

That's the actual problem worth solving. Not which of the three tools is 'best' — they overlap heavily and most power users keep more than one around for good reasons. The problem is that a developer paying for two or three of these in parallel is flying blind on combined spend, and the friction of checking three separate places means most people just... don't.

Why people end up running more than one

This isn't indecision. Each tool has a real reason to stay installed.

• Claude Code lives in the terminal, handles long multi-file refactors well, and its subscription plans (Pro, Max) bundle a usage allowance rather than metering every token.
• Codex (OpenAI's CLI, distinct from ChatGPT) is the default reach when a task needs GPT-family reasoning specifically, or when a team already standardized on OpenAI for other infra.
• Cursor is the IDE-native option — inline diffs, tab-complete, and a UI that non-terminal-first developers prefer, with its own bundled or metered plan depending on tier.

None of these read the others' state. Switching from Cursor to Claude Code mid-task doesn't carry context, and it doesn't carry cost either. You're maintaining three mental models of 'how much have I spent this month' and updating none of them in real time.

What actually drives the combined bill

Across all three tools, the same handful of behaviors move the number the most, and they're the same behaviors regardless of which agent triggered them:

• Repeated identical or near-identical prompts — retried tool calls, restarted sessions, re-running the same lint-fix loop after a failed edit.
• Large system prompts and tool schemas sent on every single call, which is structurally how agent CLIs work and which prompt caching only partly offsets.
• Long conversations where early turns get re-sent as context on every subsequent call, growing the effective token count per request even when the actual new work is small.
• Defaulting to the strongest available model for tasks that don't need it — a one-line typo fix and a cross-file refactor going through the same model tier.

None of these are specific to Claude Code, Codex, or Cursor. They're properties of how agentic coding tools call models. Which means the fix isn't 'use less of tool X,' it's reducing wasted calls before they leave the machine, across whichever tool made them.

The visibility gap, concretely

Say you want to know your actual AI coding spend for last week. Claude Code's usage view shows Claude Code's usage. Cursor's dashboard shows Cursor's usage, on Cursor's billing cycle, which may not align with the calendar week you're asking about. Codex usage shows up either in the ChatGPT usage page or an OpenAI API billing dashboard depending on how it's configured. Three logins, three time windows, three units of measurement, and manual arithmetic to combine them — if you even remember to.

That gap is exactly where a local proxy sitting underneath all three tools earns its place. Not because any single tool's own reporting is bad — Claude Code's usage view is genuinely fine for Claude Code — but because none of them can see the other two.

Where Probe0 fits

I built Probe0 to sit locally, underneath every coding agent CLI on the machine, not inside any one of them. Setup is a local proxy plus a certificate installed once — no per-tool config, no separate integration for Claude Code versus Codex versus Cursor. Whatever calls each tool makes, it routes through the same proxy, which means the ledger it keeps is a combined one by construction, not by manual reconciliation. Every request gets recorded with model, tokens, real cost, latency, and which process made the call, so 'what did I spend on AI coding this week, across everything' is a query, not a spreadsheet exercise.

The savings modules are the part worth being specific about, because each is individually switchable and reports what it actually saved rather than a projected number. Exact Cache catches literal repeat requests off local disk before they hit the network. Semantic Cache catches near-duplicates using a local vector index with a strict similarity floor — and it refuses to match anything carrying tool calls, because a wrong hit there doesn't just waste a request, it corrupts the agent's run. Request Coalescing collapses simultaneous identical calls (common when a tool fires overlapping validation requests) into one upstream call. Model Tiering routes to a cheaper model first when the task doesn't need the expensive one. Local Routing sends work to a model already running in Ollama or LM Studio, with weak answers auto-retried on the cloud so correctness doesn't get traded for savings silently. Spend Guard sets a hard cap per run or per day, warning first and then pausing rather than letting a runaway loop burn the day's budget.

It's honest to say what this isn't. Probe0 runs on macOS only, it's in private beta, and it's built for a single developer's machine, not a team gateway with per-seat roles and centralized policy enforcement. If you need multi-user routing across a company, that's a different category of tool. If you're one developer running two or three agent CLIs and want to actually see the combined number, that's the exact shape of problem it targets.

What to do without installing anything

Even without a proxy, you can get a rough combined number by hand. Pull each tool's usage export for the same date range, normalize to dollars (not tool-specific credit units), and add them. Do this once and you'll usually find one of two things: either one tool is quietly carrying most of the spend because it's the default habit even for trivial edits, or all three are roughly even because different tasks genuinely route to different tools. Either result is useful — it tells you whether consolidating effort on one tool would actually save money, or whether the multi-tool setup is earned and the real lever is cutting waste inside each one.

The question isn't which agent is cheapest per call. It's whether you can even see the total before the invoice arrives.