Back to blog

What a free tier costs when the models are yours

·Updated September 16, 2026·8 min read
What a free tier costs when the models are yours

Every free tier is a bet on how much you will cost. When your AI runs on someone else's API, that bet is denominated in dollars and you hedge it the way everybody does: make the free tier thin enough that it hurts, put the good stuff behind the wall, and hope the conversion rate covers the leakage.

IndieBob's models run on a machine I own. That changes what the free tier is a bet about, and I think the design decisions that follow from it are worth writing down — partly because I would have liked to read someone else's.

We launched days ago. I have no user counts to show you and I am not going to invent any.

A free user costs compute we already own, not money

Text generation on the free tier runs on two local models on one card in one room. The providers are registered with an input and output cost of zero, and that zero is the number the usage ledger records. Images default to local FLUX, also zero, also preferred over the metered alternatives on every plan because it is free and good enough that reaching past it is usually a downgrade in economics.

So the resource a free account consumes is minutes on a solar-powered, battery-backed AI farm that is already switched on. Not nothing — but a fundamentally different kind of not-nothing than a per-token invoice. It has a hard ceiling (there is one card, and it can only do one thing at a time), it does not compound, and no one sends me a bill at the end of the month for a spike I did not plan.

That is why the caps read the way they do.

The caps are a budget, not a wall

Free, per month:

  • 3 blog drafts
  • 5 social batches
  • 5 AI images
  • 5 email copy generations
  • 10 meta descriptions
  • 2 content opportunity runs
  • 2 SEO audits

And 20 outreach emails. When this post first went up that line read "0 — cold outreach is the one thing that is not on the free tier at all", because sending is a different kind of action from writing and I would rather gate it plainly than half-gate it. On 2026-09-16 I changed my mind about which twenty, not about the gate: the personalised email — the prospect's site read first, one email written for that one business, held until you have said yes — is the whole product, and it made no sense that nobody on Free could try it. So Free now sends twenty of those a month through IndieBob Mail on our shared domain, to prospects found on OpenStreetMap; your own sending domain, the wider discovery sources and the two hundred stay on Plus. The gate is still plain. It just moved to what spends someone else's resource — the sending reputation, the paid search APIs — rather than to the feature itself.

Look at the shape of that list rather than the numbers. Three blog drafts is not a tease; it is roughly a month of posting for a solo developer who is actually shipping. Ten meta descriptions covers a small site's whole backlog. The generous ones and the tight ones are set by how long each takes on the card, not by which ones I most want you to run out of.

That is the whole difference. A cost-denominated free tier is tuned to make the expensive actions scarce. A time-denominated one is tuned to make the slow actions scarce — and the slow actions are mostly not the useful ones.

The pricing page cannot oversell

One object in one file defines the limits for every plan. The pricing page reads it, through an endpoint that builds each row's label directly from it. The enforcement reads the same object.

This sounds like housekeeping and it is actually the honesty mechanism. The most common way a pricing page becomes a lie is not malice; it is that someone tightened a limit in the enforcement code and the marketing page kept its old number for four months. Here that cannot happen, because there is no second copy of the number to go stale. If I make the free tier meaner, the pricing page says so the same minute, without me remembering to edit it.

The enforcement also runs on the server, inside the generation endpoints, before a model is touched — not in the button. The image endpoint goes one further and clamps a batch to what is actually left, so a four-image request against a two-image remainder returns two rather than quietly overspending the meter and letting the count go negative.

A spent allowance is not a dead button

When you hit a cap, the endpoint refuses with a structured payload — the category, how many you have used, the limit, your plan, a human label, and the date it resets — and the client renders that. You see you have used 3 of 3 blog drafts, resets on the 14th, with the upgrade path next to it.

A bare red toast was the previous behaviour and it was worse than a bad experience: it reads as breakage. A user who thinks your product is broken does not upgrade, they leave and they tell someone. A user who can see they used all three of the three they were given, and when they get more, is being told the truth about a transaction they entered into.

Two AI actions are deliberately never metered. The claim check — which reads a draft against your product facts and flags every unverified claim — is free forever on every plan, because charging for the safety check teaches people to skip it, and a safety check people skip is worse than none. The Command Center's "Do Next" refresh is not metered either; it is a page load. Both get a per-day breaker instead so they cannot be looped, and the free and paid ceilings differ, which is what makes the upgrade prompt on them honest: upgrading really does raise that number.

The one absolute rule

A free account never triggers a metered cloud call. Not when the local rig is overloaded, not when it is down, not for the tasks that would normally route to a frontier model.

This is the rule I care most about because it is the one that is easiest to break by accident, and we did break it. The cloud policy returns two flags that must travel together; the router only blocks the cascade when the restrictive one is set. For a while the callers passed only the permissive one, which does nothing on its own — so free accounts fell through to a metered provider every time the rig was unavailable. No error, no alarm. Just a feature working quietly in the wrong direction.

The fix was structural rather than careful: the two flags became one object callers spread whole, so they cannot be separated by hand. The tier-3 shortcut and the explicit force-cloud override, both of which had been jumping the guard, now downgrade to the local model when cloud is blocked, or fail.

There is also a global circuit breaker under the per-user caps — a daily aggregate cost and request budget across all free accounts, cached so it does not cost a query per request. If free usage as a whole blows through it, free AI pauses for the day. That exists because per-user caps do not stop someone opening thirty accounts, and I would rather the honest answer be "paused until tomorrow" than discover the alternative on a Sunday.

When the rig is off and you are on the free tier, what you get is this, and nothing else:

Image generation is briefly offline. Please try again in a few minutes.

That is a worse experience than a silent cloud fallback, for about four minutes. I will take it, every time. "Briefly offline" is a true statement about a machine. The alternative is a bill that neither of us agreed to, arriving at the end of a month in which nothing appeared to go wrong.

What I am actually betting on

That a free tier which is generous, legible, and incapable of surprising either of us is a better acquisition channel than one engineered to run out.

I do not have the numbers to prove that yet. Ask me in six months. In the meantime, the thing I can prove is narrower and it is the one on this page: every limit you see advertised is the limit that is enforced, because they are the same line of code.

Written with IndieBob

Share this article

Stay up to date

Get the latest insights on indie software growth, marketing tactics, and building profitable projects.

No spam. Unsubscribe anytime.