276,814 agent requests in a month for $430 flat
Edited Oct 18: corrected the provider table and figures after reader comments (thanks, arhancanli). By the LeanStack team. Disclosure: we run LeanStack and its free model-testing Lab at goleanstack.com, linked at the end. Every number below comes from our own gateway logs for September 15 to October 15, 2026. We left out anything we couldn't measure.
Most "I run agents for $0" posts leave out one of two things: either there's barely any traffic, or the real bill is hidden somewhere. Here's our month with nothing removed:
- 276,814 model requests
- 9.9B input tokens
- 385M output tokens
- 66 scheduled agent jobs running around the clock
- $430/month in flat subscriptions, and $0 in metered per-token API bills
That $430 is not zero, and we won't pretend it is. But at this volume a pay-per-token setup would be a very different conversation. Below is the setup pattern, the real breakdown, what went wrong, and who this approach is a bad fit for.
The pattern: one gateway, many routes
The most important decision was putting one local gateway in front of our agents' model traffic. Agents and scripts talk to a single local endpoint, and the gateway decides which route each request goes to.
That gives you four things you can't easily get otherwise:
- One log of everything. Every request is written to one file, with provider, model, status, duration and token usage (including cached tokens). All the numbers in this article come from that file. Without it we'd be guessing.
- Routing in one place. Agents ask for a model or a route name, and the gateway maps it to a provider. Moving a workload from a paid route to a free one is a single config change, not twenty.
- Fallbacks. When a route rate-limits or fails, the gateway can try another candidate. As you'll see below, that matters a lot.
- Cost visibility by billing type. The log shows which work is covered by flat-rate subscriptions and which runs on free model tiers, and that nothing lands on a metered per-token key. That's how we know the metered API spend is $0.
If you take only one thing from this post, take this: put a gateway in front of your agents before you optimise anything else. You can't cut a bill you can't see.
Routing by task
Not every agent step needs a frontier model. Our rough rule:
- Heavy reasoning and coding go to the strongest models on flat plans. In our month, most of our input tokens went through flat subscriptions (see the split below).
- Background and scheduled work goes to free or cheap routes. Summaries, classification, triage and the long tail of cron-style jobs run on free model tiers wherever the quality holds up.
- Experiments go to preview and free SKUs, with the expectation that they'll be flaky.
Here's how input tokens actually split across billing types:
| Billing type | Share of input tokens (approx.) |
|---|---|
| Flat subscriptions (Claude, xAI, Cursor, ChatGPT, Google Antigravity) | ~78% |
| A $10/mo coding plan | ~11% |
| Free model tiers (OpenRouter free and preview SKUs, NVIDIA free tier, local free routes) | ~10% |
| Google API key (billing not yet confirmed) | ~2% |
And by route (requests / input tokens including cache). This table shows the free and API-key routes only. Subscription-covered usage is left out, so these rows don't add up to the overall totals above:
| Provider | Requests | Input |
|---|---|---|
| OpenRouter, dedicated free route | 61,705 | 488M |
| OpenRouter, free and preview | 53,291 | 191M |
| Local free routes | 10,132 | 182M |
Notice the mismatch. The free routes carry lots of requests but a small share of tokens: the two OpenRouter routes alone are 114,996 requests. The heavy, context-rich work sits on the flat plans. That's the point. Free tiers absorb volume, and flat plans absorb depth.
Caching is doing most of the work
Most of our input tokens were cache reads. Agents resend the same system prompt, tool definitions and conversation history on almost every call. If your provider and client support prompt caching, a stable prompt prefix is the cheapest optimisation there is.
What helped us:
- Keep the prefix stable. Put the system prompt and tool schemas first and don't reorder them. Put anything that changes (timestamps, run IDs) at the end.
- Reuse conversations instead of starting over for long-running agents, where the client supports it.
- Watch cached tokens per route. Some routes in our logs report zero cached tokens, either because caching isn't reported there or because it isn't happening. The gateway log is how you find out which.
Flat plans plus free tiers, and the actual bill
Our real monthly cost:
- Claude plan: $200
- Cursor plan: $200
- ChatGPT plan: $20
- Coding plan: $10
- Total: $430/month flat
- Metered per-token API spend: $0
The site that sells this playbook runs on a free hosting tier with a free Redis for signups, so hosting adds nothing either.
The honest caveat: this works because flat plans let you use a lot within their limits. Those limits are real, which brings us to what didn't work.
Spend caps and guardrails
With flat plans the risk isn't a surprise invoice. It's burning through your quota or getting throttled mid-task. With any metered key in the mix, the risk is a runaway loop overnight. Either way, the guardrails are the same:
- A per-agent daily budget (requests or tokens) that hard-stops the agent rather than just warning.
- Allow-listed routes per agent. A background job should not be able to escalate itself to your most expensive model.
- No metered key as a silent fallback. If a free route fails, fall back to another free or flat route, or fail loudly. Never quietly spill onto pay-per-token.
What didn't work
A lot of our requests failed. Among the failures were 22,111 rate limits (HTTP 429). The rest were a mix of not-found errors (often models that were renamed or retired), upstream 5xx errors, bad requests and client disconnects.
Free and preview routes were the worst offenders. Some free routes in our logs succeeded well under half the time. Lessons:
- Free tiers are unreliable by design. Budget for retries and fallbacks from day one, and don't put anything user-facing on a single free route.
- Model names churn. Preview and stealth models appear and disappear. Many of our 404s came from routes pointing at models that no longer existed. Review your routing table regularly.
- Rate limits shape everything. Spreading load across routes and providers is what keeps a high-volume setup alive. One free route won't carry 66 scheduled jobs.
- A log is the only way you'll know. Without per-request status logging, a big chunk of your agent work silently failing just looks like "the agents are a bit flaky."
Who this does NOT fit
Be honest with yourself before copying this:
- Low volume. If you make a few hundred calls a month, pay-as-you-go is almost certainly cheaper than $430 in plans. This only makes sense at heavy volume.
- Production, customer-facing workloads. Flat-rate plans and free tiers come with their own terms of service, rate limits and no SLA. If your customers depend on it, use proper API contracts.
- Teams and compliance needs. Personal plans are personal. If you need data processing agreements, audit trails or shared billing, this isn't your setup.
- Anyone who wants zero maintenance. Routing tables, retired models, quota juggling and fallbacks take ongoing attention.
What's next: we test the free routes in public
Because so much of our volume rides on free and preview models, we started testing them on a fixed suite and publishing the raw results. That's the LeanStack Drop Lab, which we run.
- Drop #1, free model baselines: https://goleanstack.com/drops/drop-1-free-model-baselines. Instruction-following, calibration and reasoning tests on three seeds, with per-seed scores, timeouts and hard fails shown as they happened, plus the raw run JSON.
- All drops: https://goleanstack.com/drops
If you want the full setup, the LeanStack playbook is $19 in early access and ships on 1 Nov: https://conchcraft.gumroad.com/l/gpqcdc. If you'd rather have your own agent bill reviewed, there's a $490 Agent Bill Audit: https://conchcraft.gumroad.com/l/ohfxlq. Everything else lives at https://goleanstack.com.
Rows from different harnesses are marked as not directly comparable, and we say so on the page. If you have questions about any of the numbers above, ask in the comments. We'll answer with whatever the logs show.
Top comments (5)
I added up the two tables against the headline numbers, since you said every figure comes from the log.
The failure rate changes what "$430 for 276,814 requests" means. If 71,953 didn't succeed, the flat cost per successful request is $430 / 204,861 = about $0.0021 rather than $0.0016. Also, which provider those failures sit on matters more than the total: if most of the 22,111 429s are on the free OpenRouter routes, they cost nothing, but if they're on the Claude or Cursor logins they eat the quota the heavy work depends on.
One more question on the "$0 metered" line: the table lists a Google API key as "billing not yet confirmed" with 42,037 requests. Was that key on a free tier, or is the $0 an assumption until the invoice arrives?
Thank you for actually adding it up. You're right on both counts. The nine rows summed to 266,454, not 276,814, so the table was partial and didn't say so. And the two OpenRouter routes are 114,996, not "over 115,000". Your cached and failed percentages and the cost per successful request are correct too.
I've edited the post. The provider table now shows only the free routes and says plainly that it's partial, and the 115k line is corrected.
On the Google key: it isn't confirmed. We haven't verified whether that key is on a free tier, so the "$0 metered" line is unproven for that slice until we see the billing. The post now marks it as "billing not yet confirmed". On the 429s, I don't have the split by provider in front of me, so I won't guess. That's a good thing to check, and I'll post it here once I have it.
Nice to see someone publish the whole log. One thing I'd add, because I did the same exercise on 33 days of my own Claude Code logs: token share and dollar share tell really different stories. ~98% of my main-session prompt tokens came from cache, but cache reads were still 62% of the API-equivalent bill (~$4,560) and cache writes another 29%. Output, the bit everyone worries about, was 8%.
So I'd be curious what your 3.14B Anthropic input comes to if you price it at API rates, split by read, write and uncached. That's the number that tells you what the $200 login is actually worth to you. (Full disclosure, I'm building a gateway-and-receipts tool in the same space, so I'm nosy!)
Thanks, that's a sharp point. We've only looked at token share so far and haven't priced the Anthropic input at API rates split by cache read, cache write and uncached, so I don't have that number. Your 62% cache-read share of the API-equivalent bill is a good reason to work it out. I'll share it here if we do.
Output is the number everyone watches, and it is the small line. In fortitudeomnis's 33 days of logs, cache reads were 62% of the API-equivalent bill and output 8%. The lever is what gets re-read.