276,814 agent requests in a month for $430 flat
By the LeanStack team. 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, of which 7.2B were served from cache
- 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 between every agent and every model provider. Every agent, script and coding tool on the machine talks to a single local endpoint, and the gateway decides where each request actually goes.
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.
- Subscriptions used like APIs. Several of our routes run on flat-rate plan logins rather than metered API keys. This is where the $0 per-token comes from.
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, the biggest single route by input was a top Claude model on a subscription login.
- 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 / logins (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 provider (requests / input tokens including cache):
| Provider | Requests | Input |
|---|---|---|
| Anthropic | 29,466 | 3.14B |
| xAI | 24,164 | 3.06B |
| Cursor | 11,684 | 1.25B |
| $10 coding plan | 29,947 | 1.06B |
| OpenRouter, dedicated free route | 61,705 | 488M |
| OpenAI (via ChatGPT plan) | 4,028 | 232M |
| OpenRouter, free and preview | 53,291 | 191M |
| 42,037 | 163M | |
| 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 over 115,000 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
7.2B of our 9.9B input tokens were cache reads, about 73%. 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 quarter of our requests failed. Of 276,814 requests, 71,953 did not return a success, including 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 quarter 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. Plan logins and free tiers come with 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're writing up the full setup (gateway layout, routing rules, caching checklist, guardrail configs, and the failure-handling patterns above) as a $29 playbook called LeanStack. We haven't written it yet. We're testing demand first, and we'll only write it if enough people sign up in the next 7 days.
If that's useful to you, the signup is here: https://leanstack-landing.vercel.app. There's no payment, just an email when it's ready. And if you have questions about any of the numbers above, ask in the comments. We'll answer with whatever the logs show.
Top comments (1)
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?