276K Agent Requests a Month for $430: LeanStack's Engineering Playbook

When posts claiming "I run Agents for free" flood the internet, there are usually two explanations: either the traffic is pitifully low, or the real cost is hidden somewhere else. The LeanStack team laid out their complete gateway logs from September 15 to October 15, 2026, offering an unabridged answer.

A Month of Real Data

In one month, LeanStack's 66 scheduled Agent tasks generated 276,814 model requests, consuming 9.9 billion input tokens and 385 million output tokens. Of the input tokens, 7.2 billion came from cache hits, roughly 73%. The total bill was $430 in fixed subscription fees, with zero in token-based API spending.

These numbers rest on specific architectural choices. Without that architecture, $430 can't buy this volume.

Core Architecture: One Gateway, Many Routes

The single most important decision in the whole setup was placing a local gateway between every Agent and every model provider. Each Agent, script, and coding tool talks only to this one local endpoint, and the gateway decides where requests actually go.

This design delivers four benefits that are hard to replace. All requests land in the same log, including provider, model, status code, latency, and token usage (with cached tokens). Routing policy lives in one place—switching a workload from a paid route to a free one is a one-line config change. When a route gets rate-limited or fails, the gateway can automatically try a fallback. And multiple routes run on fixed-rate plan logins rather than metered API keys—which is where the zero cost per token comes from.

LeanStack's core advice: before optimizing anything, put a gateway in front of your Agents. You can't optimize a bill you can't see.

What is a route? In this kind of gateway architecture, a route is a bound configuration of (provider + auth method + model). For example, "call Claude Sonnet via a fixed-plan login" is one route, and "call some preview model via a free OpenRouter SKU" is another. When a request arrives, the gateway picks a route based on preset priority, task type, or weight, sends it out, and writes the result back to the caller. The value of routes is that they pull the decision of "which model, which billing channel" out of each Agent and centralize it. Because a route is a first-class abstraction, switching costs drop to one line of config—changing a background task's default route from a paid API to a fixed plan or free tier requires no changes to any Agent code. At the same time, when a route returns 429 or 5xx, the gateway can defer to a fallback route per policy instead of letting the caller fail outright.

Layered Routing by Task

Not every Agent step needs a frontier model. LeanStack's rough rule: heavyweight reasoning and coding go to the strongest model on a fixed plan; background and scheduled tasks go to free or cheap routes; experimental tasks go to preview and free SKUs, accepting their instability.

Broken down by billing type, the input token distribution looks like this: fixed-subscription logins (Claude, xAI, Cursor, ChatGPT, Google Antigravity) carry about 78%; a $10/month coding plan carries about 11%; free model tiers (free and preview OpenRouter SKUs, NVIDIA free tier, local free routes) carry about 10%; and Google API keys carry about 2%.

Broken down by provider, request counts and token counts show a clear mismatch. OpenRouter's two routes together exceed 115,000 requests but account for a small share of tokens; meanwhile Anthropic and xAI each carry about 3 billion input tokens with only 20,000-30,000 requests. Free tiers absorb request volume, fixed plans absorb context depth—that's precisely the point of layered routing.

Caching Contributed 73% of Input Tokens

Of the 9.9 billion input tokens, 7.2 billion were cache reads, about 73%. Agents resend the same system prompt, tool definitions, and conversation history on nearly every call. As long as the provider and client support prompt caching, a stable prompt prefix is the cheapest optimization available.

The specifics: put the system prompt and tool schema first and don't reorder them, put variable content like timestamps and run IDs at the end; for long-running Agents, reuse the conversation rather than starting over; and monitor cached token counts per route—some route logs show zero cache, which may mean it isn't reported or isn't taking effect. Only gateway logs can tell you which.

Prompt Caching is a billing mechanism offered by mainstream model providers: if the beginning (prefix) of two requests is byte-for-byte identical, the provider can reuse the previously computed KV cache, only fully computing the new portion, and charge far less for the cached tokens than for regular input tokens—some providers' cache reads cost as little as a tenth of normal input. The hit condition usually requires a byte-identical, order-stable prefix; the moment you insert a timestamp at the start or reorder tool definitions, all subsequent tokens miss. This is why the article stresses "put variable content at the end." Cache hit rate shows up directly on the bill: of 9.9 billion input tokens, 7.2 billion were cache reads, and billing them at normal input rates would cost an order of magnitude more. Note that providers differ on cache TTL, minimum prefix length, and reporting fields—which may explain "some route logs show zero cache."

What the Actual Bill Looks Like

Monthly fixed costs: Claude plan $200, Cursor plan $200, ChatGPT plan $20, coding plan $10—$430 total. Token-based API spending: zero.

This approach works on the premise that fixed plans permit heavy use within their limits. Those limits are real, which is also why it isn't for everyone.

Free routes illustrate the point best. Of 276,000 requests, 71,953 did not return successfully, including 22,111 HTTP 429 rate limits. The rest included 404s from models being renamed or retired, upstream 5xx errors, request errors, and client disconnects. Some free routes have a success rate well below half.

Guardrails and Failure Handling

The risk with fixed plans isn't a surprise bill—it's running out of quota or getting rate-limited mid-task. If metered keys are mixed in, the risk becomes runaway loops overnight. Either way, the guardrails are the same: set a daily budget per Agent (request count or token count) and hard-stop rather than merely alert; restrict which routes each Agent can use, so background tasks can't silently upgrade themselves to the most expensive model; and never use metered keys as a silent fallback—when a free route fails, fall back to another free or fixed route, or fail loudly. Never quietly spill over into metered billing.

The lessons from failure are blunt: free-tier unreliability is by design, so budget for retries and fallbacks from day one, and never put anything user-facing on a single free route; model names change frequently, with preview and stealth models appearing and vanishing at any time, so review the routing table regularly; rate limits decide everything, and spreading load across multiple routes and providers is the key to surviving at high volume; and without per-request status logging, a quarter of failures will only be perceived as "the Agent is a bit flaky."

Why is a metered key as a fallback the most dangerous option? The risk of fixed plans is capped—when you run out of quota, you stop. The risk of metered keys is uncapped: once an Agent gets stuck in a loop, misjudges task completion, or retries repeatedly overnight unattended, the bill grows linearly with call count and there's no hard brake. More insidiously, when a free route fails due to rate limiting or a 404, if the framework defaults to "fall back to any available route," it silently dumps traffic onto the metered channel—everything looks fine until the end-of-month bill arrives. The right approach is to constrain fallback targets to free or fixed-plan routes of the same kind; if none is found, throw an explicit error so the failure is visible. Meanwhile, each Agent should have a daily hard budget based on request count or token count, terminating that Agent directly rather than just sending an alert—because alerts are useless during unattended hours.

What This Approach Isn't Good For

At just a few hundred calls a month, pay-as-you-go is almost certainly cheaper than a $430 plan. Customer-facing production workloads shouldn't use plan logins and free tiers—they have terms-of-service restrictions, rate limits, and no SLA. Teams that need data processing agreements, audit trails, or shared billing also don't fit, since personal plans are personal. Finally, it doesn't suit anyone unwilling to do ongoing maintenance—routing tables, retired models, quota scheduling, and fallback policies all need long-term attention.

The LeanStack team is packaging this approach into a $29 playbook, currently still gauging demand. They stress that every number comes from gateway logs, with no estimates.

Why can't customer-facing production workloads use personal plans? Personal subscriptions (like Claude Pro, ChatGPT Plus) typically limit usage in their terms to individual interactive use, and don't support programmatic bulk calls, resale, or serving as a product backend. Wiring such logins into a customer-facing product brings not just terms risk but also rate limits, no SLA, no audit trail, and no data processing agreement. Moreover, plan quotas are shared per account, so once automated workloads saturate them, the developer's own daily use suffers too. The reasonable framing of this approach is therefore "cost optimization for an individual or small team's internal toolchain," not a general production deployment blueprint. Teams needing compliance, auditability, or multi-party shared billing should go the enterprise contract and metered API route.

One-line Summary

LeanStack uses a local gateway with layered routing to run 276K requests/month across 66 Agents for just $430 in fixed subscription fees.

Paragraph Summary

LeanStack published a month of complete gateway logs: 66 scheduled Agent tasks generated 276,814 model requests, consuming 9.9 billion input tokens and 385 million output tokens, at a total cost of just $430 in fixed subscription fees with zero metered API spending. The core approach is placing a local gateway between all Agents and model providers to unify logging and centralize routing decisions, then layering by task importance—heavyweight reasoning on the strongest fixed-plan models, background tasks on free or cheap routes. 73% of input tokens came from prompt caching hits, with a stable prompt prefix being the most effective optimization. The tradeoff is a 27.6% failure rate, including 22,111 rate limits, requiring guardrails like hard budget stops, route whitelists, and explicit failures. This approach doesn't fit low-volume workloads, customer-facing production, or teams needing compliance and audit.