Daily vs Monthly vs One-Time: Free Tier Reset Shapes Compared
Daily vs Monthly vs One-Time: Free Tier Reset Shapes Compared
Every free tier has a clock, and the clock decides whether the tier fits you. Across the entries we maintain, free allowances come in three shapes: daily pools that refill on a 24-hour cycle, monthly recurring credits that refresh each billing period, and one-time grants that deplete and never come back. There is a fourth, smaller geometry hiding inside all of them — the per-minute window — and it is usually the one that actually breaks a workload.
Picking a tier by dollar value is the wrong axis. A daily pool and a monthly credit can both be "worth $3 a month" and behave nothing alike under load. Here is how to tell the shapes apart, size a workload against each one, and schedule around the clock instead of fighting it.
Why the reset clock matters more than the dollar value
A free tier is not a budget. It is a budget plus an expiry rule, and the expiry rule determines how much of the budget you can actually use.
Think about it as three questions asked in order:
- How much capacity exists per cycle? This is the number on the marketing page.
- How long is the cycle? Day, month, or never-again. This number is usually buried in a rate-limits table.
- What happens to unused capacity at the boundary? It is forgotten, banked, or irrelevant because the grant is finite.
Most developers answer question one and stop. Questions two and three decide whether the tier survives contact with a real workload. A daily pool with a huge ceiling and a monthly credit with a small one can be perfectly matched to two completely different jobs — and perfectly mismatched if you swap them.
Shape 1: the daily pool
Examples. Cloudflare Workers AI allocates 10,000 Neurons per day on the free allocation, with paid usage above it billed at $0.011 per 1,000 Neurons. SambaNova publishes a per-model daily token pool on its free tier, with a much larger daily ceiling on the paid developer tier. NVIDIA NIM applies a default per-minute request cap on free developer access — the same geometry as a daily pool, just on a faster clock.
Behaviour. Capacity refills on a fixed schedule and unused capacity is forgotten, never banked. Over the limit, requests fail until the next reset. Cloudflare's overage behaviour is the crucial detail here: on the free allocation you are blocked, not queued and not auto-billed.
Fits. Steady, thin, continuous workloads. A monitoring agent that makes 20 calls an hour, a nightly digest, a low-traffic internal tool. The daily pool is the only shape where "always on, low volume" costs nothing every day without you having to think about it.
Breaks on. Bursts. A 5,000-Neuron job at 15:00 UTC that would fit comfortably inside any monthly budget simply does not fit in the day's remaining pool — and it cannot wait, because tomorrow's pool is not today's. There is no borrowing forward.
Scheduling pattern. Front-load nothing, smooth everything. Spread work across the day so you never approach the reset boundary, and treat the reset timestamp as a hard restart of your capacity. If you need a burst, layer a monthly credit underneath it rather than trying to squeeze it into one day.
Shape 2: the monthly recurring credit
Examples. Mistral includes $10 per month in API credits on its free tier — no card required. Hugging Face Inference Providers credits $0.10 per month for free users and $2.00 per month for PRO, with further credits for Team and Enterprise organisations. ElevenLabs ships a monthly credit allowance on its free tier, and AssemblyAI's free allowance is a recurring block of transcription hours rather than a one-off.
Behaviour. A budget that refreshes on a billing cycle. You can spend it all on day one — the pool is bankable within the month, which is the key difference from a daily pool. What you cannot do is carry the remainder into the next cycle.
Fits. Bursty or variable workloads: the research sprint, the one-off evaluation, the month where the project is hot and the next month it is quiet. A monthly credit absorbs variance that a daily pool cannot.
Breaks on. Sustained high volume, and it also punishes the perfectly steady user. A workload that needs $40 of monthly value spends the $10 in a week and then pays for three weeks of nothing-free. Meanwhile the person who spreads exactly $10 across the month gets the most value per dollar but has no headroom at all — and the reset does not care about your calendar, your demo day, or the week the traffic tripled.
Scheduling pattern. Spend early, keep a reserve. Use roughly 70% of the cycle's credit in the first two weeks when the work is actually happening, and hold 30% for overflow. Keep a cheap second provider configured as the fallback so a mid-month depletion degrades quality rather than availability.
Shape 3: the one-time grant
Examples. The classic trial credits: a new cloud account with a limited-time credit balance, a 30-day credit window on another cloud, a 90-day research-style grant on a third, and the smaller vendor credits that arrive with a new account. Deepgram's trial credit is the interesting outlier — it is a one-time grant with no expiry, which means it behaves like a monthly credit you only get once.
Behaviour. Depletes, never refills. The only dimension that matters is the clock on the expiry, because the grant is a deadline, not a budget. A credit that expires in 30 days is a different product from the same credit expiring in six months.
Fits. Evaluation and onboarding: the benchmark window, the proof of concept, the "does this model clear our quality bar" test. It is the shape you use to decide which recurring tier to commit to — not the shape you run on.
Breaks on. Anything durable. The moment a workload outlives the grant you are on paid pricing with no free baseline, and some accounts auto-close at the end of the window unless you explicitly convert. That conversion step is an outage waiting to happen if nobody owns it.
Scheduling pattern. Front-load hard. The value of a one-time grant is spent on the questions you have now. Saving it is losing it. If a benchmark can run in week one, run it in week one, because week six is not guaranteed.
The fourth shape: the per-minute window
Per-minute caps are not a separate reset shape so much as the same geometry at a smaller clock — but they deserve their own heading because they cause more agent failures than the other three combined.
- Groq documents both per-minute and per-day request ceilings, and the per-minute one binds first for anything that fires calls back-to-back.
- OpenRouter applies free-model request limits per minute and per day, with a much higher daily ceiling once your account meets its credit threshold.
- NVIDIA NIM defaults to a modest per-minute request cap on free developer access, which is fine for chat and tight for loops.
A per-minute window is empty for the first part of every minute and full again a moment later. That means the failure it produces is recoverable but mid-task, which is worse than a clean daily exhaustion: an agent that 429s on call four of twenty-one either fails the whole task or retries from scratch, re-sending all the context it just paid for. Treat the per-minute cap as a throughput budget to smooth across the minute, honour the retry-after header, and serialise parallel tool calls when the loop is running on a free tier.
Worked example: sizing one workload against three shapes
Say you run a small monitoring agent that makes 20 calls an hour — 480 calls a day. Each call re-sends a 3K-token preamble of system prompt, tool schemas, and recent context. That is 1,440,000 input tokens a day on the wire.
- Against a 200,000-tokens-per-day-per-model free pool (SambaNova's published free-tier shape): 200,000 ÷ 3,000 = about 66 calls a day. The workload is roughly 7× over. The daily pool cannot host it — not because the tier is stingy, but because the workload's shape is wrong for it.
- Against prompt caching, the repeated 3K preamble stops being billable on every call. That is the same arithmetic as in the DeepSeek cache-hit breakdown: stable input is nearly free, fresh output is the product. The daily pool now hosts the same workload comfortably.
- Against a per-minute window, nobody is checking whether 20 calls an hour is fine — it obviously is. But if the agent ever fans out to ten parallel tool calls, the minute-level ceiling is what fails, not the day-level one.
The lesson generalises: size the tier on requests and on the shape of repetition, then use caching to fix the token side. The dollar value of the allowance is the least informative column in the comparison.
The matching table
| Workload shape | Best-fit free tier shape | Why it fits |
|---|---|---|
| Steady and thin (24/7, low volume) | Daily pool | Refills exactly when you need it, every day |
| Bursty or project-based | Monthly credit | Banks the budget into the busy week |
| Evaluation, benchmark, proof of concept | One-time grant | Deadline-shaped, matches a decision window |
| Agent with many small calls per hour | Daily pool plus request headroom | Request count, not token count, is the constraint |
| Long-context or batch jobs | Monthly credit | Big token burns fit a banked budget, not a daily pool |
| Interactive tool with spiky traffic | Per-minute headroom on a paid-capable tier | Bursts need a window that refills in seconds |
How to match a tier to a workload in five steps
- Measure the workload in requests per hour, not tokens per month. Requests are what fails first; tokens are what you optimise second.
- Find the reset time, not the reset amount. Record it, convert it to your own timezone, and note that most reset times are published in UTC. A daily pool that resets at 00:00 UTC resets in the middle of your working day if you are scheduling from Europe or Africa.
- Ask what happens to unused capacity at the boundary — forgotten, banked, or irrelevant. This single question separates the three shapes faster than any pricing table.
- Check the overage behaviour. Blocked, queued, or silently billed? A tier that silently bills the moment you exceed the free allocation is a different risk profile from one that returns an error.
- Stack a second shape underneath. Route steady traffic to the daily pool, bursts to the monthly credit, and this week's evaluation to whatever one-time grant is still alive.
The real answer is the union, not the pick
No single shape covers a real workload, which is why the free-first router pattern is an architecture rather than a luxury. The insight is that the shapes reset on different clocks:
- A daily pool is empty at 23:59 UTC and full at 00:00.
- A monthly credit is empty on the 28th and full on the 1st.
- A per-minute window is empty for part of every minute and full again immediately after.
Aligning three of those gives you a system with almost no shared zero-moment. That is the entire point of "free-first": not one big free tier, but a portfolio of small ones whose resets do not line up. The dollar value stays roughly the same; the number of hours per month during which you have usable capacity goes up sharply.
How we verified this
The allowance figures, reset descriptions, and rate-limit shapes in this article come from each provider's own pricing or limits documentation, read on 2026-09-17, and we link the source page inline wherever we state a number. The sizing example is arithmetic on published limits — 200,000 daily tokens divided by a 3,000-token preamble — not a measured benchmark. Where a provider's terms are ambiguous about reset behaviour, we describe the behaviour generally rather than asserting a specific rule we could not confirm on the official page.
FAQ
Do daily pools ever carry unused capacity forward? Not in the shapes we track. Daily pools are re-issued rather than accumulated, which is why a night of low traffic does not buy you a bigger day tomorrow. If banking matters to you, you want a monthly credit instead.
Can a monthly credit substitute for a daily pool? It can, but you will spend it faster and more anxiously. A monthly credit has no per-day guard rail, so a single runaway loop can consume the entire cycle before lunch. Daily pools are self-limiting, which is a feature when the workload is untested.
What is the failure mode of each shape? Daily pools fail on bursts at the boundary. Monthly credits fail on sustained volume partway through the cycle. One-time grants fail permanently on a date you may not have written down. Per-minute windows fail mid-task and recover on their own.
How do I know whether a tier resets in UTC or local time? Read the provider's limits page rather than inferring it, and record the exact wording and the date you read it. If the page does not state a timezone, schedule your workload so it never depends on a precise boundary — the honest answer is that you should not build a cron job around a reset time you cannot cite.
Should I upgrade one tier or add three free tiers? For most workloads, add tiers. The marginal request capacity and the desynchronised resets are worth more than the marginal dollar of a single upgrade, and a multi-provider setup also gives you a failover path when one provider degrades. Upgrade the single tier that your latency-sensitive traffic actually depends on.
- What is a daily reset free tier and which providers use that shape?
- A daily pool refills on a fixed 24-hour clock and never banks unused capacity. Cloudflare Workers AI resets 10,000 Neurons per day, and SambaNova's free tier refills a per-model daily token pool, so unused capacity is lost at the boundary rather than carried forward.
- Which free tier shape is best for a bursty project workload?
- A monthly recurring credit. Because the pool refreshes on a billing cycle rather than a day, you can spend heavily in a busy week and still have the full allowance again next cycle. Daily pools fail on bursts, and one-time grants fail on anything that outlives them.
- Are one-time free credits ever worth building on?
- Only for evaluation. Trial grants such as cloud provider credits are deadline-shaped, so their value is spent on benchmarks, proofs of concept, and model-quality decisions made now. Nothing durable should depend on a grant that never refills.
- Why do per-minute rate limits matter if the daily token allowance looks generous?
- Because agents and batch jobs cluster requests in time. A tier with a large daily token pool but a low requests-per-minute cap will return 429s mid-task even though the day's budget is barely touched, which is a failure mode the daily number hides.
- What is the best way to combine several free tiers?
- Route each workload to the shape that matches it and treat the tiers as a portfolio rather than picking one. Because daily, monthly, and per-minute pools reset on different clocks, their zero-moments rarely line up, so a well-mapped set of small tiers covers more of the month than a single larger one.
- How often should I re-verify a free tier's limits?
- On a schedule, and before any launch. Allowances, request ceilings, and reset times change without much fanfare, so re-read the provider's own limits page and record the date you checked rather than trusting a figure you remember from months ago.