Agent Cost Lens reads your agents' usage metadata — never your prompts, never your code — shows where the API money actually goes, and names the caching fixes that recover it, quantified as headroom from your own data. Our own numbers, method, and caveats sit on this same page: the live report.
Get your key — $500/month
Stripe checkout → your API key on the next page → analyzing in
under five minutes. Cancel anytime; your key deactivates automatically.
Measurement is the easy half. Every run — local transcripts or API logs alike — carries a pattern catalog: your specific cache-waste, named, with what fixing it recovers, every figure computed from your own usage and labeled (simulated).
cache_control to your conversation prefix recovers.On a Claude Max or Pro plan? Tell the lens once
(plan.json: plan name + monthly price) and every figure is worded
for flat-fee reality: dollars become API-equivalent value, savings
become usage-limit headroom, and you get your equivalent run-rate as a
multiple of the plan price — no fake dollars claimed as savings. The audit
shows the plan line too, along with every other field on the wire, so nothing
travels unshown.
The client ships a preview_upload tool that shows what would
be sent before anything is sent, no key required: a sample of the records,
and every field name that travels — not just the ones in the sample. If you
can find a prompt, a file path, or a real project name in it, don't buy.
You can also keep the records.
python3 -m acl_mcp.export --out records.jsonl
writes every scrubbed record to a file you name — one
apilog-v1 record per line, built by the same code and the same
salt an upload uses, with no server in the loop. A first run also creates a
local salt if you have none; nothing else is written, and nothing is sent.
Diff it, grep it, hand it to a script of your own: it is an audit you can
read, not only one you can watch. The export path imports nothing that can
open a socket — asserted by test in both directions, not promised in a
sentence.
And the client is open source (MIT) — don't take the tarball's word for it: read the code on GitHub. What you install is what you audited.
Key from the claim page after checkout. Paste the block below into your MCP config (Claude Code, Claude Desktop, or any MCP host):
pip install "agent-cost-lens-mcp @ https://lens.r-lattice.com/download/agent_cost_lens_mcp-1.5.3.tar.gz"
{
"mcpServers": {
"agent-cost-lens": {
"command": "acl-mcp",
"env": {
"LENS_SERVER_URL": "https://lens.r-lattice.com",
"LENS_API_KEY": "acl_YOUR_KEY"
}
}
}
}
Then ask your agent to run preview_upload (the audit) and
analyze_costs (the answer).
Teams and solo builders running Claude / Anthropic API agents — custom agent loops, Claude Code fleets, LangChain/raw-SDK apps — who suspect their context re-sends are quietly costing real money.
Already running 95%+ cache-hit? That is where the lens earns its keep, not where it runs out. A rate on its own is not an amount: the lens does the attribution — what that rate is worth in dollars, priced at rates verified against Anthropic's published pricing rather than a table someone typed a year ago (worded as API-equivalent value if you are on a flat-fee plan, per the paragraph above). It also names the drift that quietly erodes a high rate — a prompt prefix that starts changing per request, a cache lifetime (TTL) that stops fitting the workload, write premium paid for context nobody reads back — on the run it appears rather than on the invoice a month later. And when a workload genuinely has nothing left to recover, no pattern fires and the report names none — it shows you the measurement and stops, instead of manufacturing a fix. The one case it does call out by name is the one-shot workload: "caching can't help one-shot workloads."
Agent Cost Lens on its own build, rendered from the analyzer's own store — the same hosted path a customer's data takes, on keys that are ours. Everything below comes from our own build, and from no customer's key at all. As of 2026-09-08 — our own build's data runs through 2026-09-08, and this page counts nothing that is not in it.
This is the Agent Cost Lens run on the people who build it. Every night, our own Claude Code sessions on the drive where this product is built are counted, scrubbed to pseudonyms, and pushed to this server. The server prices them the same way it prices a customer’s. Nothing here is typed in. Every number comes from those records.
The actual figure is what the API would have charged us, at Anthropic’s published pay-per-token prices, for exactly the tokens we used, with the caching that really happened. It is not what we paid. We are on a $200-a-month flat plan, so on our side no money changed hands for any of it. The figure is called API-equivalent for that reason: the same usage, priced as if we paid per token.
Every time a model reads a prompt, it reads tokens. If the same beginning of a prompt was sent before, the platform can serve those tokens from cache at a much lower price. The without-caching figure asks: what would the same tokens have cost if none of them had come from cache? Every input token is priced once at the full fresh rate. This is a simulation. It is our own token counts run through the published prices under one changed assumption. It is not an industry average and not a guess.
The difference between those two figures. We call it headroom rather than savings because no money was saved. On a flat plan, the marginal cost of one more token is zero. What the caching bought us is room inside the plan we already pay for.
The cache-hit figure counts tokens: how many of all the input tokens came from cache. Ours is about 99%.
The saved figure counts dollars: how much of the without-caching cost the caching removed. Ours is about 87%.
They differ because a cache read is cheaper, not free. A cached token costs a tenth of a fresh one on most models, and a fortieth on Fable 5.1. So 99% of tokens at a tenth of the price removes about 87 cents of every dollar. Same tokens, two ratios. One counts tokens, one counts money.
Each session is priced at its own model’s published rates. The full price table this server uses is shown below the numbers, with a fingerprint so you can tell if it has changed since a figure was computed.
The figures cover a 30-day window ending on the newest day pushed. Not every day in it carries data. The oldest day in this window with data is August 10, so the days before it carry none, and any day with no build work carries none. The page states both numbers: how long the window is, and how many of its days carry data.
Each figure is rounded to the cent on its own. The arithmetic runs unrounded. So a part and a total can sit a cent apart, and that is rounding, not error.
The push carries counts, and never the words that produced them. Five token counters travel with each record — cache reads, fresh input, 5-minute cache writes, 1-hour cache writes, and output — together with the model’s name, a date, and one-way tags standing in for the session and project names. The table below shows all five for this window. Where a row says “not pushed”, that day was stored before this server kept that count and no push has replaced it yet. Nothing is hidden and no number here is estimated.
87% of this window's token cost avoided as usage headroom
— $11,615.24 actual (API-equivalent) vs $90,666.89 without caching (simulated), across our own build.
Window: the trailing 30 calendar days ending 2026-09-08 (2026-08-10 through 2026-09-08) — 29 of the 30 days carry data and 1 carries none, because 1 day inside the run carries no push, so these totals describe the 29 days that do, not a full month.
| Cache reads | 14,471,859,844 | stored per day row (cache_read_tokens) |
| Fresh input | 462,506 | stored per day row (fresh_input_tokens) |
| 5-minute cache writes | 27,117,670 | stored per day row (cache_write_5m_tokens) |
| 1-hour cache writes | 172,754,402 | stored per day row (cache_write_1h_tokens) |
| Output | 58,205,261 | stored per day row (output_tokens) |
| All input-side tokens (fresh input + both cache-write kinds + cache reads) | 14,673,718,927 | stored per day row (full_input_tokens) |
| Fresh input and cache writes together | 201,859,083 | the two stored counts, subtracted |
Every count above is a stored per-day sum added up over this window — nothing here is estimated and nothing is turned back out of a rate. A kind reads “not pushed” when no day row in the window carries it. A kind that some rows carry and some do not is the sum of the rows that do, and the silent days are named below. This window still holds 2 day-rows stored before those counts were kept (2026-08-22, 2026-08-24); the four kinds above omit them.
| Model | Input $/MTok | Output $/MTok | Cache read $/MTok | 5-min write $/MTok | 1-hour write $/MTok | Cache rates from |
claude-fable-5 | 10.00 | 50.00 | 1.0000 | 12.50 | 20.00 | generic multipliers |
claude-fable-5-1 | 10.00 | 50.00 | 0.2500 | 12.50 | 20.00 | published: read, write_1h |
claude-haiku-4-5 | 1.00 | 5.00 | 0.1000 | 1.25 | 2.00 | generic multipliers |
claude-mythos-5 | 10.00 | 50.00 | 1.0000 | 12.50 | 20.00 | generic multipliers |
claude-opus-4-5 | 5.00 | 25.00 | 0.5000 | 6.25 | 10.00 | generic multipliers |
claude-opus-4-6 | 5.00 | 25.00 | 0.5000 | 6.25 | 10.00 | generic multipliers |
claude-opus-4-7 | 5.00 | 25.00 | 0.5000 | 6.25 | 10.00 | generic multipliers |
claude-opus-4-8 | 5.00 | 25.00 | 0.5000 | 6.25 | 10.00 | generic multipliers |
claude-opus-5 | 5.00 | 25.00 | 0.5000 | 6.25 | 10.00 | generic multipliers |
claude-sonnet-4-5 | 3.00 | 15.00 | 0.3000 | 3.75 | 6.00 | generic multipliers |
claude-sonnet-4-6 | 3.00 | 15.00 | 0.3000 | 3.75 | 6.00 | generic multipliers |
claude-sonnet-5 | 2.00 | 10.00 | 0.2000 | 2.50 | 4.00 | generic multipliers |
Generic cache multipliers on the input rate: reads ×0.1,
5-minute writes ×1.25, 1-hour writes ×2.0 — used for every
model whose published row carries no rate of its own. Price table in force,
content digest aee0529d; it is verified against
Anthropic’s published pricing, so a figure quoted without its vintage
cannot be re-derived later.
| Actual (API-equivalent) | $11,615.24 | the day rows’ stored spend, added up |
| Without caching (simulated) | $90,666.89 | $11,615.24 (the spend of the days that carry a saving) + $79,051.65 (the saving) |
| Saved as headroom (simulated) | $79,051.65 | without caching − actual, over the days that carry a saving |
| The percentage | 87% | $79,051.65 ÷ $90,666.89 |
| Cache-hit | 99% | cache-read tokens ÷ all input-side tokens |
Each figure is rounded to the cent on its own, so a part and a total can sit a cent apart; the arithmetic runs unrounded.
This workload runs on the $200/month Claude Max plan, so no money changed hands for any of it: on a flat monthly fee the marginal cost of one more token is zero, whatever the API would have charged for it. Every dollar above is therefore API-equivalent value — what the same usage would have cost at published API rates — and what caching gave back is usage-limit headroom, not a refund. That is why this page says headroom and never savings.
| Days with data | Sources | Actual (API-equivalent) | Without caching (simulated) | Saved as headroom (simulated) | Cache-hit | Still recoverable (simulated) catalog ceiling · floor |
|---|---|---|---|---|---|---|
| 52 | 4 | $11,615.24 | $90,666.89 | $79,051.65 (87%) | 99% | up to $6.48 (simulated) · at least $0.00 (simulated) |
Every day in the window, gaps included.
| Day | Actual (API-equivalent) | Saved as headroom (simulated) |
|---|---|---|
| 2026-08-10 | $185.63 | $949.64 |
| 2026-08-11 | $358.76 | $1,876.10 |
| 2026-08-12 | $364.49 | $2,130.02 |
| 2026-08-13 | $117.39 | $685.84 |
| 2026-08-14 | $276.21 | $1,542.03 |
| 2026-08-15 | $520.14 | $3,259.90 |
| 2026-08-16 | $246.32 | $1,470.09 |
| 2026-08-17 | $221.44 | $1,267.46 |
| 2026-08-18 | $504.36 | $3,205.52 |
| 2026-08-19 | $826.21 | $5,149.47 |
| 2026-08-20 | $383.42 | $2,317.01 |
| 2026-08-21 | $443.63 | $2,741.78 |
| 2026-08-22 | $520.62 | $3,438.12 |
| 2026-08-23 | $112.87 | $622.38 |
| 2026-08-24 | $150.55 | $970.16 |
| 2026-08-25 | $659.79 | $3,524.20 |
| 2026-08-26 | $287.00 | $1,836.42 |
| 2026-08-27 | — | — |
| 2026-08-28 | $350.12 | $2,033.31 |
| 2026-08-29 | $520.74 | $3,048.84 |
| 2026-08-30 | $732.88 | $4,490.74 |
| 2026-08-31 | $701.41 | $4,539.08 |
| 2026-09-01 | $655.52 | $4,324.53 |
| 2026-09-02 | $445.61 | $3,219.31 |
| 2026-09-03 | $371.12 | $2,756.12 |
| 2026-09-04 | $661.66 | $5,856.52 |
| 2026-09-05 | $598.72 | $5,865.04 |
| 2026-09-06 | $120.74 | $1,435.18 |
| 2026-09-07 | $176.39 | $2,525.60 |
| 2026-09-08 | $101.50 | $1,971.25 |
Honesty notes — read these before quoting any figure. “Without caching” and “saved as headroom” are simulated upper-bound counterfactuals from usage arithmetic, not measurements of money that changed hands. This workload runs on the $200/month Claude Max plan, so no money changed hands for any of it: on a flat monthly fee the marginal cost of one more token is zero, whatever the API would have charged for it. Every dollar above is therefore API-equivalent value — what the same usage would have cost at published API rates — and what caching gave back is usage-limit headroom, not a refund. That is why this page says headroom and never savings. Cache-hit is Claude Code's platform caching measured on this workload — the lens verifies and quantifies it; it does not claim credit for it. The cache-hit above is token-weighted over this window's own traffic — a rate over tokens, never an average of per-day or per-source rates. “Still recoverable” is a range with both ends measured from the same stored components: the floor is the cache-write premium this workload paid and never read back (clamped per session, so it cannot overstate), and the ceiling is what a perfectly-cached replay of the same turns simulates. A source counts in this window when its newest day row falls in it, and its source-level ceiling counts once no matter how many days it ran. Our own keys keep their full pushed history here; customer findings are kept latest-only and never appear on this page — a difference declared rather than discovered. Days can go missing: a push that never landed self-heals on the next one, but an outage longer than transcript retention loses those days for good, and they stay visible as gaps above. Rendered from the store by the same engine the product ships — no figure passes through hands at all.