What does it actually cost to build an app with AI?

Building an app with an AI app builder costs somewhere between nothing and a few dollars per generation, and the reason nobody gives you a straight number is that the cost is driven by how many tokens the model writes, not by how many times you press send.

On Fabricate specifically, the unit is a credit, and a credit is defined in code as 10,000 weighted tokens (`TOKENS_PER_CREDIT` in worker/config/billing.ts). Free gives you 60 credits per month at no cost, Pro gives 350 for $25 per month, Scale gives 700 for $50 per month. There is no per-seat charge and no usage bill on top; when the credits are gone, generation stops until the next monthly refresh or an upgrade.

The useful question is not "what does one app cost" but "how many credits does a turn burn, and what makes that number move". The rest of this post answers that with the actual weights, the actual arithmetic, and the parts of the model that work against you.

A Fabricate credit is 10,000 weighted tokens. Weighted, not raw. Raw token counts are useless as a billing unit because a token the model reads and a token the model writes differ in cost by roughly a factor of five, and a token served from cache costs a fraction of either.

So every token is multiplied by a weight before it is counted. The weights, defined as `TOKEN_WEIGHTS` in worker/config/billing.ts, are:

Input: 1.0. Output: 5.0. Cache read: 0.1. Cache write with a 5-minute TTL: 1.25. Cache write with a 1-hour TTL: 2.0.

Those numbers are not arbitrary. They are price ratios against a fixed reference rate of $3 per million input tokens (`SONNET_INPUT_USD_PER_MILLION_TOKENS` in the same file), used purely as a normalization baseline so that usage from any provider can be expressed in one comparable unit. That reference rate is an accounting yardstick, not a model you are running: Fabricate routes to Gemini 3.6 Flash, Gemini 3.1 Pro Preview, Gemini 3.5 Flash Lite and Grok 4.3 depending on the step, per the routing table in worker/agents/inferutils/config.ts.

The conversion is one line of arithmetic: sum every token multiplied by its weight, divide by 10,000, and that is your credit charge. Internally the result is kept at six decimal places (`CREDIT_PRECISION_FACTOR = 1_000_000`) so that a long run charged in many small increments does not accumulate rounding error, and there is a small floor per charge (`MINIMUM_CREDIT_CHARGE`) so that trivial calls are not billed as zero.

Output tokens carry a weight of 5.0 because the reference rate prices output at $15 per million against $3 per million for input. This is not a platform markup; it reflects how model providers price. Reading your prompt is a parallel operation across the whole sequence. Writing a response is sequential -- each token depends on the one before it, so the model runs a full forward pass per token generated. Every provider prices output above input, though the exact ratio varies by model: across the models Fabricate routes to, the output-to-input price ratio in `MODEL_COSTS` ranges from about 2x on Grok 4.3 to about 8x on Gemini 3.5 Flash Lite. Because the charged weight is derived per model rather than fixed, that variation is passed through rather than averaged away.

The practical consequence is that a request that reads a lot and writes a little is cheap, and a request that writes a lot is expensive regardless of how short your prompt was. "Rewrite this entire file" costs more than "read these twelve files and tell me which one has the bug", even though the second one sounds like more work.

Cache reads are weighted 0.1 -- one tenth of a fresh input token -- because a cached prefix has already been processed. The provider stores the computed state and replays it instead of recomputing it, and charges around a tenth of the input rate for the privilege. The cache-write weights (1.25 for a 5-minute TTL, 2.0 for an hour) exist for providers that bill cache creation separately; on the providers Fabricate currently routes to, no cache-write tokens are reported, so in practice that line does not appear on your bill.

One honest caveat about caching, because it changes how much you should count on it. Fabricate does not place explicit cache markers on the models it routes to -- caching there is automatic and provider-managed, so whether a given turn gets a cache hit is the provider's decision, not ours. When a hit does happen the provider reports the cached token count and the 0.1 weight applies. When it does not, those tokens bill as ordinary input at 1.0. So treat cheaper iteration as the strong tendency it is, not as a guarantee you can budget to the credit.

Here is the conversion done explicitly, so you can run it on your own numbers. These figures are illustrative arithmetic chosen to show the mechanics -- they are not measured platform averages, and you should not read them as a typical build.

Take a hypothetical generation that consumes 40,000 input tokens, 12,000 output tokens, and 200,000 cache-read tokens. Apply the baseline weights:

Input: 40,000 x 1.0 = 40,000 weighted tokens. Output: 12,000 x 5.0 = 60,000 weighted tokens. Cache read: 200,000 x 0.1 = 20,000 weighted tokens. Total: 120,000 weighted tokens. Divide by 10,000 tokens per credit and you get 12.0 credits.

Now look at what that total is made of. Output was 12,000 of the 252,000 raw tokens the run touched -- under 5 percent by count -- and it accounted for 60,000 of the 120,000 weighted tokens, exactly half the bill. Cache reads were 200,000 raw tokens, nearly 80 percent of everything the run processed, and contributed 20,000 weighted tokens, about 17 percent of the bill.

That inversion is the whole model in one paragraph. What the run reads is almost free. What the run writes is what you pay for.

The weights in the table are a baseline, not the final answer. The function that charges you, `calculateWeightedTokens` in worker/database/services/UsageService.ts, does not apply the published input and output weights directly at all. It recomputes them from the price of the model that actually ran the step, against the $3-per-million reference rate for input tokens.

The mechanics are worth stating precisely, because the two sides work differently. The input weight is the model's input price divided by $3.00. The output weight is the model's own output price divided by that same $3.00 input reference -- it is not the 5.0 baseline weight scaled down. The cache weights are the published 0.1, 1.25 and 2.0 multiplied by the input ratio, because caching is priced off the input side.

Work it through for Gemini 3.6 Flash, which the routing table in worker/agents/inferutils/config.ts assigns to code generation and to every phasic pipeline stage. Its cost entry in `MODEL_COSTS` is $1.50 per million input tokens and $7.50 per million output. Input weight: 1.50 / 3.00 = 0.5. Output weight: 7.50 / 3.00 = 2.5. Cache read: 0.1 x 0.5 = 0.05. For this model every weight happens to land at exactly half the baseline, because its output price is exactly five times its input price -- the same ratio the baseline encodes. On a model with a different internal ratio the two sides diverge: Grok 4.3 is $1.25 input and $2.50 output, giving an input weight of about 0.42 and an output weight of about 0.83, which is nowhere near a uniform halving.

Rerun the same hypothetical generation from the previous section on that multiplier. Input: 40,000 x 0.5 = 20,000. Output: 12,000 x 2.5 = 30,000. Cache read: 200,000 x 0.05 = 10,000. Total 60,000 weighted tokens, which is 6.0 credits -- exactly half the baseline figure.

This is a deliberately unglamorous design choice, and it cuts against us commercially. It would be simpler and more profitable to charge one flat weight regardless of which model ran, and pocket the difference whenever a cheap model handled the step. Charging the real ratio means routing a step to a cheaper model directly lowers what you are billed for it. It also means the credit cost of the same prompt can change when we change the routing table, in either direction.

The first generation of a project is the most expensive turn you will run on it, and the gap is structural rather than incidental. On turn one there is nothing to reuse: the model writes an entire application from a blueprint, and writing is the heavily weighted operation. On turn twelve the application already exists and the model writes a diff, with much of the context eligible to come back as a cache read at 0.1.

Fabricate builds in phases (worker/agents/execution/phasicStateMachine.ts): plan a deployable milestone, implement it, deploy it, validate it, repeat. Each phase pair is a planning call plus an implementation call, and the implementation call is where the output tokens are. The sizing comment on `ESTIMATED_PHASE_COST_CREDITS` in worker/config/billing.ts records what those phases were measured to cost against real end-to-end builds in the usage log: phase generation around 2.8 credits, phase implementation around 5.6, giving a phase pair of roughly 8.4 credits, rounded to 9 for budgeting purposes.

The comment on `MAX_CREDITS_PER_GENERATION` in the same file records the corresponding figure for a whole first build -- a measured full-stack build of blueprint plus project setup plus two phases, settling at about 16 credits. Those are measured figures from our own logs at the time the constants were tuned, not a guarantee, and your build will differ by however much code it needs to write.

A follow-up turn is a different shape entirely. It is usually one implementation pass over an existing codebase, with the project as cached context, producing a diff rather than a codebase. That is why the honest answer to "how many apps can I build on 350 credits" is a bad question and "how many turns of what size" is the good one.

Three separate limits govern spend, and they exist for three different failure modes.

The per-generation cap is the ceiling on what a single run can consume. It rises with the tier and is defined in one place, `MAX_CREDITS_PER_GENERATION` in `worker/config/billing.ts`; the current figures are published on the pricing page rather than restated here, because they get tuned. It exists so that one ambitious prompt cannot drain an entire month in a single run. When a run approaches its cap, the phase planner reconciles the remaining roadmap against the remaining budget and stops at a phase boundary rather than starting a phase it cannot finish, because a clean partial app you can continue from is worth more than a truncated file. The run tells you it has done this rather than stopping silently.

The free tier also carries a daily cap (`FREE_TIER_DAILY_CREDIT_CAP`), applied on top of the monthly allocation. Its job is to stop a single bad day from consuming the whole month before you have learned whether the tool suits you. The relationship between the two numbers matters more than either one: the daily cap is meant to sit above the per-generation cap. The code comment explains why, and it is worth quoting the reasoning because it came from getting it wrong -- when the daily cap and the per-generation cap were equal, one full-size build consumed the entire day, so a user whose first build failed was locked out until midnight UTC with nothing to show for it. At 45 against 25 you can run a full-cap build and still have credits left to fix what it got wrong.

Credits do not roll over. `maxRollover` is 0 on all three tiers, and the monthly refresh tops your balance up to the allocation rather than adding to it. This is the least popular design decision in the model and it deserves a straight justification rather than a shrug: capacity is provisioned monthly, and rollover converts a predictable monthly cost into an unbounded liability that can be redeemed all at once. Platforms that offer rollover generally price that risk into the base rate. We chose the lower rate. If you routinely finish a month with a large unused balance, the honest advice is to move down a tier rather than to bank the difference.

AI builders use five broadly different pricing shapes, and the shape tells you more about how your bill will behave than the headline number does. Rather than quote competitor prices that change monthly and go stale in a blog post, here is what each shape does to you as your project grows.

Flat subscription with soft limits gives you the most predictable bill and the least predictable service, because the provider has to protect its margin somewhere -- usually with throttling, queue priority, or a "fair use" clause that becomes real exactly when your project gets big enough to matter.

Per-message or per-request pricing is easy to understand and misaligned with reality, because a message that changes one line and a message that rewrites your app cost the provider wildly different amounts and cost you the same. Users learn to batch enormous requests into single messages, which is worse for output quality.

Raw token passthrough is the most honest and the least usable. You get a real cost signal, and you also get a bill you cannot forecast and a unit you cannot reason about without a calculator.

Weighted credits, the model described in this post, is an attempt at the middle: one unit you can count, weights that track real cost ratios, and a hard cap so the bill cannot surprise you. The cost is complexity. The fact that explaining it honestly takes an article this long is itself a real disadvantage compared to a flat fee.

Start from the per-credit rate, because it is the one number that makes tiers comparable. Pro is $25 for 350 credits, which is about $0.071 per credit. Scale is $50 for 700 credits, which is also about $0.071 per credit. They are the same rate. Scale is not a volume discount -- it is twice the monthly capacity and a higher per-generation ceiling (120 credits versus 60), which matters if your builds are large enough that a single run bumps the Pro cap.

Then estimate in turns rather than apps. Using the roughly 16-credit measured first build cited earlier as a rough anchor, 350 credits is on the order of twenty first builds if you spent every credit on first builds and never iterated -- which nobody does. A more realistic split is a handful of new projects plus a long tail of follow-up turns, and follow-up turns are much cheaper because most of their context is cache-read.

For the free tier, be clear-eyed: 60 credits per month against a roughly 16-credit measured first build is on the order of three or four full builds, or one build plus a real amount of iteration on it. The daily cap also means you cannot spend all of it in one sitting. That is enough to find out whether the output quality suits your project. It is not enough to run a business on, and we would rather say so here than have you discover it on day nine.

If you want a real number instead of an estimate, run one build on Free and read the credit charge on the completed generation. Charging is incremental during the run and settled at the end (worker/agents/execution/billingManager.ts), so the figure you see is what was actually consumed, not a projection. One measured build of your kind of app beats any average we could publish.

A credit model has genuine disadvantages, and pretending otherwise is how pricing pages lose trust.

It creates meter anxiety. Watching a balance tick down changes how people work, usually for the worse -- they batch requests, they hesitate to iterate, they accept a mediocre result rather than spend two more credits improving it. That is a real cost that does not appear on the invoice. A flat fee, whatever its other faults, does not do this.

It is harder to budget than a flat fee. We can tell you what a credit is with total precision and still not tell you what your app will cost, because that depends on how much code it needs. Anyone who gives you a confident per-app number is either averaging over projects unlike yours or guessing.

It shifts variance onto you. When a generation goes wrong and has to be retried, the tokens were genuinely spent and the credits are genuinely charged. We mitigate that where we can -- the pre-deploy safety gate in worker/agents/validators/preDeploySafetyGate.ts runs 28 static rules against generated code before deployment specifically to catch failures that would otherwise cost a wasted round trip -- but a gate is not a guarantee, and a bad run still costs you.

What a credit model does buy is proportionality. Small changes cost little, large generations cost more, and nobody subsidises anybody else. If your usage is light, you pay less than you would under a flat fee sized for heavy users. If your usage is heavy, you are not quietly throttled to protect someone else's margin. Whether that trade is worth the complexity depends on which kind of user you are, and that is a decision we would rather you make with the arithmetic in front of you.