Free Tiers for AI Agents: Your Token Budget Is a Request Budget

If you sized a free tier for a chat app and then pointed an agent at it, you have probably already hit the limit — and the number that broke was not the token count. Agents consume free tiers in a fundamentally different shape: more requests per user action, compounding context on every turn, and bursty timing that collides with per-minute caps.

The practical consequence is that the free tier that looks generous on paper ("200K tokens per day") can be the wrong tier for your agent, while a tier that looks restrictive on tokens can be exactly right. This guide works through the arithmetic, names the ceilings that actually fail, and ends with the checklist we use before pointing an agent at any free allocation.

One user turn is not one API request

A human chat turn is one API call. An agent turn is a loop:

[object Object]

Five requests, one user action. The general shape is roughly 2N+1 round trips for a task with N tool calls: one planning call, two calls per tool use (decide and consume), and a closing summary. A "simple" ten-step agent task therefore lands near 21 requests.

Now multiply. Ten tasks a day is 210 requests before anyone has done anything interesting. Fifty tasks a day is over a thousand. The request count, not the token count, is the number that explodes — and it is the one most free-tier comparisons ignore, because chat products are advertised in tokens.

Why context re-sending makes token spend quadratic

Every round trip re-sends the conversation. Turn five of the loop above carries the system prompt, the tool schemas, and all four previous calls and results. So token spend is not linear in turns; it grows roughly quadratically:

A ten-turn task has read roughly the sum of that sequence — on the order of 130K input tokens for a single task, most of it a repeated prefix. That figure is arithmetic on the growth pattern above, not a benchmark, and it is directionally what you will see in your own usage logs if you plot input tokens per call across a task.

Two consequences follow immediately:

1. Daily token ceilings bind far faster than intuition suggests. A per-model daily pool of 200,000 tokens per day, which is the shape several free tiers publish, sounds roomy — until one ten-turn task consumes something like 130K of it. That is a handful of agent runs per day, not a workday's worth.
2. Caching is the highest-leverage cost optimisation available. If the system prompt, tool schemas, and early history are cached, each round trip only pays for the delta — the new tool result. On the cache-hit rate published for DeepSeek's flash model ($0.003 per 1M input tokens off-peak), a repeated 10K prefix falls from roughly $0.0015 to roughly $0.00003 per turn, about a 98% cut on the input side, on every turn, for the life of the task. The full arithmetic is in the cache-hit breakdown.

But note what caching does not do: it does not reduce the number of round trips. If your binding constraint is requests per day, caching buys you nothing there. Fix the request side separately, and treat the token side as a second, independent problem.

Per-minute caps are the silent killer

Agents cluster requests in time. The loop fires calls back-to-back, and parallel tool calls fire several simultaneously. That is precisely the shape that exhausts a per-minute request cap:

• Groq↗ documents tight per-minute request ceilings alongside higher per-day ceilings on its free tier. The per-minute number binds first for loops.
• NVIDIA NIM↗ applies a modest default per-minute request cap on free developer access — comfortable for chat, tight for parallel tool calls.
• OpenRouter↗ applies both per-minute and per-day limits to :free model traffic, and an agent plus one human doing anything concurrent will collide with the per-minute one.

The failure is worse than a chat app's because it lands inside a task: the agent 429s on call four of twenty-one, and you either fail the whole run or restart it from scratch — re-sending and re-paying for all the context you just accumulated. On a free tier, a mid-task 429 is not a rate-limit event; it is a wasted-work event.

The fix is serialisation with backoff. Run tool calls sequentially when you are on a free allocation, honour retry-after on a 429 instead of hammering the endpoint, and treat the per-minute cap as a throughput budget to smooth across the minute rather than a wall to hit. If your agent genuinely needs fan-out, that is a signal to route it to a paid or higher-ceiling provider, not to retry harder.

The three numbers to size a free tier on

Before comparing free tiers for an agent, extract these from the provider's own limits documentation:

Documented examples make the point: SambaNova's rate-limit docs↗ publish per-model daily token ceilings by tier, and Google's Gemini API rate limits↗ publish per-minute, per-day, and token dimensions separately. Read all three columns for any tier you are considering — a generous token column with a thin request column is a chat tier wearing an agent's clothes.

Which free tier shapes survive agent load

Ranking the reset shapes specifically for agents:

1. A high daily request ceiling with a workable daily token pool — best fit. Agents are sustained rather than bursty at the day scale, and a large daily allowance absorbs the loop. Pair it with caching to keep the token burn down and with sequential tool calls to stay under the per-minute cap.
2. A monthly credit — good for evaluation, bad for running. Fine for the benchmark week when you are comparing agent frameworks. Under sustained agent load the credit depletes in days, and then you are back to paying with no free baseline.
3. A generous token pool with a thin daily request cap — worst fit. This is the classic trap: the tier was designed for a chat user sending a handful of long messages. A single ten-step agent task is 21 requests, so a 50-request-per-day allowance is roughly two tasks. If you can lift that ceiling through an account-level threshold such as a minimum credit purchase, the shape changes completely — that is often the single cheapest upgrade available to an agent developer, and we cover the arithmetic in the OpenRouter free-model breakdown.

The general rule: size the tier on requests first, tokens second, and treat context ceiling as the tiebreaker.

How to cut requests per task (the real optimisation)

Reducing round trips is worth more than reducing tokens on a free tier, because requests are the scarce resource.

• Plan once, execute in batches. A planning call that returns a list of tool invocations lets you execute several tools and feed all their results back in one subsequent call, instead of two calls per tool.
• Batch tool results. If your tools are independent, aggregate them into one round trip. Two tool results in one message cost one request instead of two.
• Cut redundant verification turns. A "verify" call that re-sends the entire history to confirm what the tool already returned is pure overhead on a metered tier.
• Cap the loop. Give the agent a hard ceiling on iterations and a stopping condition, so a confused run cannot spend your whole day's allowance searching for an answer.
• Trim history aggressively. Summarise or drop older turns rather than carrying them verbatim; it reduces both tokens and the per-call latency that makes long tasks expensive.
• Cache the preamble. Put the system prompt and tool schemas first and keep them byte-stable so they fall under the cached rate rather than the miss rate.
• Route by cost. Send deterministic steps to cheap or local models and reserve the strong free allocation for the reasoning turns.

Moving a ten-turn task from 21 requests to 15 by batching tool results is a 29% increase in daily task capacity — on a free tier, that is often the difference between a demo and a usable tool.

Backoff and recovery patterns that keep a task alive

[object Object]

Three design rules make the difference between a hiccup and a lost task:

1. Checkpoint state after every turn. If the loop dies on call 20 of 21, resuming should cost one request, not twenty-one.
2. Make failover explicit. A router that can move a request to a second provider turns a mid-task limit into a slower task instead of a failed one.
3. Log request counts, not just token counts. Log every provider call with its provider, model, and outcome — including 429s. Token dashboards hide the constraint that actually bit you.

Worked example: one agent, fifty tasks a day

Assume a ten-turn task at roughly 21 requests and something like 130K input tokens of cumulative context. Run fifty tasks a day and you need approximately:

• 1,050 requests per day
• 6.5M input tokens per day before output

Now check that against the free tier shapes we have documented:

• A 50-request-per-day ceiling covers about two tasks — roughly 4% of the requirement.
• A 1,000-request-per-day ceiling covers roughly 47 tasks, which is nearly the whole requirement but leaves no headroom for retries or a human using the same key.
• A 200K-token-per-day-per-model pool covers roughly one and a half tasks — about 3% of the token requirement.

Those are arithmetic comparisons against published limits, not measured runs. They are also the reason the honest recommendation for a real agent is a portfolio: a high-RPD tier for the loop, a cached path to collapse the input bill, and a second provider configured as failover. No single free tier hosts fifty agent tasks a day, and the tiers that appear to are the ones with an undisclosed per-minute cap waiting inside the task.

The agent-friendly free-tier checklist

1. Request ceiling, not just token ceiling. How many round trips per day? If it is under about 100, no real agent fits.
2. RPM and retry semantics. Does it 429 with a retry hint, or hard-fail? The first is recoverable; the second kills tasks.
3. Context re-send cost. Is there prompt caching, and at what rate? Without it, input cost is quadratic in turns.
4. Max context per call. A growing history needs headroom; a modest context ceiling clips long runs rather than failing cleanly at the start.
5. What a 429 or payment failure does mid-task. Can you resume from the last checkpoint, or does the loop restart and re-burn the context?

How we verified this

The rate-limit behaviours in this article come from each provider's own limits documentation, linked inline, read on 2026-09-17. The round-trip multiplier, context growth table, and token totals are arithmetic on a defined task shape — they are models you can re-run against your own agent's logs, not benchmark results, and we label them as derived figures rather than measurements. Where a provider's free ceiling depends on account state, we describe the dependency rather than quoting a number that may already have moved.

FAQ

Is an agent on a free tier ever realistic? Yes, if it is steady and thin: a monitoring agent making a few hundred calls a day fits a high-RPD tier comfortably, especially with batching and caching. What does not fit is a busy multi-user agent running dozens of long tasks, because the request arithmetic alone exceeds most free ceilings.

Should I make my agent's tool calls sequential or parallel? Sequential on a free tier, because a fan-out is the fastest way to trip a per-minute cap. Parallelise only after you have measured your headroom against the provider's documented per-minute limit and can confirm the burst stays inside it.

Does a bigger model make agent planning cheaper? Not on a metered tier. A stronger model may need fewer planning turns for the same task, which reduces requests, and that can win outright. But per-token rates are typically higher, so measure both dimensions on your own task shape rather than assuming one dominates.

How much do 429 retries actually cost me? Retries cost requests, context, and latency at once: a restart re-sends the whole history, so a task that fails at turn twenty pays most of its token cost twice. That is why checkpointing and failover matter more on free tiers than on paid ones.

Is it worth buying the minimum credit to unlock a higher free ceiling? Often, yes. When a provider gates a much larger daily request ceiling behind a small account threshold, the effective price of the upgrade is the threshold rather than the credit itself, which you can still spend. Verify the current threshold on the provider's own limits page before you plan around it.