What Claude Code Actually Costs Me

TL;DR by Goose▾

Ingredients

• My always-on home server — the same headless Linux box that runs all my scheduled jobs (already set up)
• A JSON registry — one hand-maintained file listing every job that calls Claude: which model, which billing bucket, roughly how many calls and tokens per week (free)
• Python 3 — three small scripts: a drift scanner, a cost estimator, and a weekly digest (free)
• A scheduled task — runs the whole thing once a week without me thinking about it (free)
• Email + phone push — the same alert plumbing my other projects already use, so the digest lands in my inbox and on my phone (free tier)

The Problem: I Had No Idea What I Was Spending

The trigger was an announcement. Anthropic said it was moving programmatic usage — the Agent SDK and headless claude -p calls — onto a metered $100-a-month API-credit cap. My first reaction wasn’t about the $100. It was the uncomfortable realization that I had no idea how much of my subscription those background agents were already burning through, because I’d never once looked.

Over the past few months I’ve built a small zoo of automated jobs, and a lot of them call Claude. A morning market briefing that asks Claude to explain why markets moved. A soccer-club bot that grades its own decisions. A classifier that reads news posts and decides which ones matter. A weekend fitness recap. Each one, on its own, felt trivial. But they add up, they run on their own schedules, and I’d stopped counting.

The honest truth is I couldn’t have told you how many jobs called Claude, which models they used, or what the whole thing cost me per month. As a product manager, that’s exactly the kind of “we’ll figure out the unit economics later” blind spot I’d flag in a review. So I turned it on myself: build the dashboard, get the number, stop guessing.

The Twist That Reframed the Whole Project

Here’s the twist. That $100-a-month cap I mentioned up top? Mid-build, I learned Anthropic had paused it before it ever went live. No metered cap, no credit pool — at least not yet. Which meant the exact question I’d set out to answer (“how much of my $100 have I used?”) no longer had an answer, because the number didn’t exist.

That sounds like it kills the project. It actually clarified it. Because once the credit was off the table, the real cost picture came into focus, and it turns out there are two completely different kinds of “cost” hiding in the word “cost.”

Subscription Load vs. Real Dollars

This distinction is the entire point of the audit, so it’s worth being precise about it:

• Subscription jobs — these call Claude the same way I do when I’m typing in the terminal. They count against my monthly plan’s usage limits, not against a bill. As long as I stay under the plan’s ceiling, running these jobs is effectively free. The cost here isn’t money — it’s headroom: how much of my plan’s capacity the automation eats before I’d notice it interactively.
• API-key jobs — these use a separate pay-as-you-go key, billed per token. This is real money, and it’s the number I actually care about. In my setup, every one of these runs on Haiku — Claude’s smallest, cheapest, fastest model — because they’re all doing narrow, high-volume work (classify this, summarize that) where a bigger model would be overkill.

For the subscription jobs, I still wanted a way to rank them — which ones eat the most of my plan? So the tool computes a “shadow dollars” figure: what each subscription job would cost if it were billed at that model’s API rate. It’s not a real charge. It’s just a common yardstick so I can see which automation is the heavy one, purely for load-ranking.

How the Audit Works

Three small Python scripts, one hand-maintained inventory file, and a weekly schedule. No database, no web framework, no new servers. The whole thing is maybe a few hundred lines.

🔧 Developer section: the three scripts

• The registry — a JSON file with one entry per Claude-calling job: an ID, the model it uses, which billing bucket it’s in (subscription or API key), and rough estimates of calls-per-week and average input/output tokens. This is the single source of truth. To tune a cost estimate, I just edit the numbers here.
• The cost estimator — reads the registry, multiplies each job’s calls and tokens by that model’s published per-million-token price, and sums it up into two totals: real pay-as-you-go dollars (the API-key jobs) and shadow dollars (the subscription jobs, for ranking only).
• The drift detector — this is the part I’ve come to value most. It scans my scheduled jobs and project folders for anything that looks like a Claude call, then compares what it finds against the registry. If a project is calling Claude but isn’t in the registry, it’s flagged as NEW. If a registered project has stopped calling Claude, it’s GONE. And if a job quietly switched to a more expensive model, that’s MODEL drift.

A weekly digest script stitches all three together — runs the drift scan, runs the cost estimate, writes a log, and sends me a formatted email plus a push to my phone. Once a week, Sunday morning, I get one message that answers “did anything change, and what am I spending?” and then I forget about it again.

A Detail That Mattered: Scan by Project, Not by File

My first instinct for the drift detector was to key everything on the exact file that makes the Claude call. That produced a mess of false alarms. Real projects don’t call Claude from one obvious place — they route the call through wrappers and imports, so the actual API call lives a couple of files deep from where the job kicks off. File-level tracking kept screaming “this file disappeared, a new file appeared!” every time I refactored, when nothing had actually changed.

The fix was to track drift at the project level: does this project call Claude, yes or no, and with which model? That collapsed all the noise and left only the alerts I actually care about — a whole new project starts using AI, or an existing one changes model. Same lesson I keep relearning: alert on the thing you’d act on, not on every raw event, or you’ll train yourself to ignore the alerts.

The Number

Here’s what the audit actually reports. Across a handful of small Haiku jobs running on the pay-as-you-go key, my real spend is about $1.86 a month. Not a typo. Under two dollars.

Meanwhile, the subscription jobs — the heavier, more frequent ones running against my flat-rate plan — carry a shadow cost of roughly $14 a month if you imagine billing them by the token. But I don’t pay that. It’s absorbed by the monthly subscription I was already paying for anyway. The single biggest “cost” in my whole automation stack is a job that, in reality, costs me nothing incremental at all.

Why so cheap? Because the expensive-per-token work all runs on the flat-rate subscription, and everything on the metered key is Haiku doing small, well-scoped tasks. Cheap model plus narrow job plus predictable volume equals a bill that rounds to a rounding error. The lesson isn’t “AI is free.” It’s “match the model to the job and know which meter you’re on.”

The Best Part Was the Drift Check

I built this expecting the cost number to be the payoff. It wasn’t. The payoff was that on its very first run, the drift scanner caught two jobs my own manual inventory had missed. I’d sat down, listed every Claude job I could think of by hand, and still forgot two of them. One was a scheduled job quietly calling Claude that I’d simply overlooked. The other turned out to be an on-demand tool with no schedule at all, which I then correctly marked as excluded.

That’s the whole argument for the tool in one anecdote. Left to my own memory, I was already wrong about my own systems after a few months. A cheap automated check that says “actually, you also have these” is worth far more than the cost estimate it ships alongside. Going forward, the value isn’t the number — it’s the weekly “nothing changed” (or the occasional “hey, this is new”).

How It Grew: From “Track My Credit” to “Track My Drift”

The shape of this project changed completely between the idea and the finish, and that’s the interesting part:

• The original pitch — a meter for a $100/month free credit, so I’d know when I was getting close to the ceiling.
• The reframe — the credit got paused before launch, the ceiling vanished, and I had to ask what problem was actually left. The answer: I still didn’t know what I was really spending, and I still couldn’t reliably list my own AI jobs.
• The finished thing — a two-part audit. Cost: real dollars (tiny) separated from subscription load (absorbed). Drift: an automated weekly check that my inventory still matches reality. The second part turned out to be the durable one.

It’s a small, real example of a thing product work does to you: the feature you set out to build gets invalidated, and if you’re paying attention, the underlying need points you at a better one.

What went fast

• The cost math — once the registry existed, the estimator was almost trivial: calls times tokens times the published per-token rate, summed into two buckets. An afternoon, not a project.
• The weekly digest — I already had email and phone-push plumbing from earlier projects. Reusing proven alert code meant the delivery layer was basically free; I just pointed it at a new report.
• Deciding to ship estimates — I gave myself permission to ship rough token guesses instead of building full measurement first. That single call is why this got finished in an afternoon instead of never.

What needed patience

• Getting the drift scan to stop crying wolf — file-level tracking generated constant false NEW/GONE alerts because projects call Claude through layers of wrappers. Moving to project-level tracking was the fix, but figuring out why the noise happened took some staring at the false positives.
• Separating the two billing buckets cleanly — the temptation was to report one big scary total. Keeping real dollars and subscription shadow strictly separate — and labeling the shadow number as “not billed” every single time — took discipline, because a single blended number would have been simpler to print and completely misleading.
• Being honest that these are estimates — it would’ve been easy to dress up guessed token counts as precise measurements. I made the tool say “estimate” out loud everywhere, so future-me doesn’t mistake a rough figure for a metered one.

The satisfying thing isn’t that the number came back small — though it did, and that was a relief. It’s that I no longer have a blind spot where a dozen automated jobs used to quietly call an AI on my behalf. Once a week I get a note that says everything’s where I left it and I’m spending less than a coffee. If you’re running your own automation against any paid AI, I’d recommend auditing it the same way — you might be pleasantly surprised, and you’ll almost certainly find something you forgot you built.