Three and a Half Weeks, 689M Tokens, No Meter

Aug 18, 2026·
Derek Armstrong - Software Engineer · AI · Infrastructure
Derek Armstrong
· 6 min read
Twenty-five days of local inference, metered.

For three and a half weeks, everything I did — the code, the research, the 2am refactors — ran through a model served on two used 24GB GPUs in my house. No invoice, no subscription, nothing to look at at the end of the month.

So I figured out what that work would have cost, per token, if every request had gone through a commercial API instead.

The number is big. The interesting part, though, isn’t the number. It’s what changed about how I work when the bill stopped existing — and exactly where this whole math falls apart.

How I measured this

I use a local coding agent as my daily driver, and it logs every session to a local database: input tokens, output tokens, timestamps. I pulled the window I’m quoting — 25 days, late July through mid-August 2026, 24 active days — and summed the rows. No projection, no sampling. The full meter.

  • 689M tokens total — 682.7M input, 6.3M output
  • 370 sessions, ~27.5M tokens per day
  • The model: an open-weights 27B at 4-bit, served across two used 24GB GPUs

For scale: 689M tokens is about 920,000 pages of text. Printed, it’s a stack roughly 320 feet tall — a thirty-story building’s worth of paper.

What it would have cost

Mid-2026 list prices. No cache discounts, no volume discounts — and list price is the most honest number a provider publishes, so if anything, this table flatters them. The same 682.7M input and 6.3M output tokens, metered by each:

Model$/M in$/M outThis 25-day windowAnnualized
GPT-4o-mini0.150.60$106$1.6K
Qwen3-32B (hosted, Groq)*0.300.90$210$3.1K
GPT-51.2510$916$13.6K
Claude Sonnet 52.0010$1,428$21K
GPT-4o2.5010$1,769$26K
Claude Sonnet 4.53.0015$2,142$31.8K
Claude Opus 4.55.0025$3,570$53K
My box00~$40 in electricity~$600

*Closest hosted equivalent to my local 27B. The ~$40 in electricity covers the whole window — bursts of full load, weeks of idle in between.

The number that actually surprised me

99.1% of the tokens I consumed were input.

Roughly a 110-to-1 input-to-output ratio. The model spent the period looking at things, not writing them.

It’s easy to assume you’re paying mostly for what the model generates. Not true if you’re driving it like an agent. Agents read files. They re-read files. They resend the entire conversation every turn. They spawn subagents, and each of them walks in carrying its own copy of the context. Every single request drags the full history with it, and the history grows with every request. So the cost compounds with session length in a way a single prompt never would.

This is why per-token pricing and agentic workloads fight each other. The vendor’s answer is prompt caching — cached reads often drop to around 90% off — and it helps. But cache reads still bill. A model reading your project’s files for the fortieth time is still a line item on the invoice.

That’s the mechanism I keep coming back to: per-token pricing isn’t charging for the model. It’s charging for your re-reading.

What changed wasn’t the money. It was the behavior.

Here’s the part I actually want to argue.

When inference costs nothing at the margin, the unit economics of thinking change. I now do things a meter would make me ration:

  • Let a research loop run overnight and read the results in the morning without feeling like I’m burning money
  • Re-run validation passes I expect to fail, without caring
  • Spawn subagents for work I’d otherwise do clumsily by hand, and not flinch at the context overhead
  • Throw away a draft and have it regenerate from scratch instead of patching it

With a meter, all of those feel like costs, so you ration the same way you’d ration anything else — and rationing is invisible, which means it quietly shrinks your scope. It’s the unlimited-data-vs-10GB-on-the-plane split. Same flight, different person. The meter limits scope, not wallet.

There’s the most honest exit in any learning loop: don’t do the thing until you know what you’re doing. It reads like a virtue, but with a meter it’s just a parking lot, because every check at the gate costs real money. So “figuring it out” waits in line. On a box that can’t be metered, the gate is free, and that exit mostly disappears: you do the thing, and the knowing comes after.

Where this math falls apart

Before you frame this as “local beats cloud”:

1. The workload has to clear a threshold. This is ~27.5M tokens a day, seven days a week, running the agent as my daily driver. If you run it an hour after lunch, a $3,500 box will never pay back. If there’s one line of this article you’re carrying out the door, it’s this one — the shape of your day decides the math, not your politics about the cloud.

2. A 27B isn’t a frontier model. Honest split of how I actually use mine: most of the work — rewrites, fact checks, bulk edits, research synthesis, refactors — a smaller model covers fine, and you can’t tell the difference at 90% quality on work that doesn’t need a ceiling. The minority of work that does needs one, and for that I still call a frontier model on the wire. That’s an 80/20 split, not “I replaced the cloud.”

3. If you’re already on a flat subscription, the savings math isn’t yours. A $200/month max plan caps the bill in a way per-token pricing can’t match. If your play is a flat-rate plan, the pitch isn’t savings — it’s that nothing you write ever goes to a data center, no one rate-limits you, and overnight runs don’t consume your monthly allotments. Against a flat subscription, local is parity, not a win.

4. TCO, honestly. The box was ~$3,500, all in — GPUs and PSU were about $2,500 of that; the rest I already had. Electricity is tens of dollars a month. GPUs will fail and need replacing within a few years. Payback at the pace in this table: about one month against a flagship API, ~six weeks mid-tier, 3–4 months GPT-5 class, and 2–4 years against the budget row — which is exactly what point 1 is saying. And I’m not counting “I already had the box” as a savings. If you want fresh-money accounting, the only new spend in this whole arrangement is the electricity: the ~$40.

When I’d rebuild the case

  • Open-weights models close the gap with frontier models on the 20% of my work that still needs a ceiling
  • A general-purpose flat-rate subscription appears that’s strong enough for daily-driver work, uncapped, and priced so nobody can tell the difference
  • My workload shape changes — these cycles move faster than the hardware does

Key takeaways

  • 689M tokens over 25 days, measured from actual session logs — 99.1% of them input
  • Same workload, frontier pricing: $53K/yr metered against ~$600 of electricity
  • The mechanism: per-token pricing bills re-reading, and agentic work is nothing but re-reading
  • The real win isn’t the savings — it’s that the work stops being metered, so you stop rationing it
  • The threshold: this only pays off at ~27.5M tokens/day, seven days a week, agent as daily driver. Below that, the cloud or a flat subscription is fine.

Next

Want to keep the conversation going?

If you found this useful, let's connect — I'm always happy to swap notes with people building in the same space. Start a conversation on LinkedIn .

Derek Armstrong - Software Engineer · AI · Infrastructure
Authors
Software Engineer · AI · Infrastructure
I’m a payments & POS engineer who knows the whole stack, from CPU to customer support, and I bring AI into the toolchain end to end: using, building, and maintaining it in production. 10+ years in production payment systems, running on the quiet infrastructure that has to work at 3am whether I’m awake or not.