What costs credits and what is free

Two completely separate meters: credits you spend building your app, and credits your app spends serving your users. Hosting, page views, email/password sign-in, previewing and publishing are free. Here's what each visitor action actually costs — usually single digits, not hundreds.

There are two separate meters, and mixing them up is the single biggest source of panic about credits. Keep them apart and the whole picture gets simple.

1. Building — you, in the editor, asking the AI to make your app.
2. Running — your app doing backend work for a visitor after it's live.

They're priced differently, so we'll take them one at a time.

Free — no credits at all

None of this draws credits, ever:

• Hosting your app, 24/7
• Page views and navigation — whether you have 10 visitors or 50,000
• Your users signing up and signing in with email and password
• Previewing your app in the editor and clicking around it
• Publishing — including re-publishing as often as you like
• Version history and rolling back
• Your app's own screens, images, and static files

Two things people expect to be on that list and aren't:

• SMS sign-in. Sending a one-time code by text is an SMS, and SMS costs 1.6 credits per message. Email-and-password sign-in stays free.
• Database storage past the included allowance. Every app gets a free storage allowance, and past it your app's database is billed monthly by how much it stores. Most apps never come close, but data apps cost nothing isn't accurate — check the pricing page for the current included allowance and rate rather than a number quoted in a chat.

So an app that's mostly screens and static content — a dashboard, directory, booking tool, form, community page — costs you essentially nothing per user as long as it isn't doing AI, email, SMS, or integration work for each visitor.

Meter 1: building your app

Building is charged on the tokens of each generation, not per message. Roughly:

• Long output is the expensive part. Output counts about 5× more than input, so a turn that rewrites five whole files costs far more than one that answers a question.
• Re-reading the same context is cheap. Context we've already seen is discounted about 90%, which is why a long conversation doesn't cost proportionally more as it grows.
• The model you pick matters most. Light models cost a fraction of the baseline; top-end reasoning models cost roughly double it. Your model picker in the editor is the biggest single lever you have.

Three habits that cut building costs a lot

1. Plan first, build second. Use plan mode to agree on what you're building before any code is generated. Planning turns are short — they produce a plan, not files — so you're paying for a paragraph instead of paying to write, then rewrite, five files. See Plan mode vs build mode.

2. Edit, don't rebuild. Change the header to dark blue touches one file. Rebuild my app with a dark theme regenerates everything. Same outcome, very different cost. See Editing vs rebuilding.

3. Say what you want, once, specifically. Vague asks produce a guess you then have to correct — and you pay for the guess and the correction. Being specific up front is cheaper than iterating. See How to ask the AI for changes.

Meter 2: your live app doing work for visitors

This is the one people fear, so here are real numbers.

When a visitor triggers an AI feature in your app, the charge is based on tokens, at a rate set by the model your app uses:

• Light / edge models: about 0.25–0.5 credits per 1,000 tokens
• Budget models: about 0.25–1.0
• Mid-range models: about 2.0–3.0
• Top-end models: about 5.0–10.0

Output counts 3× input on this meter, repeat context gets about 90% off, and every charge is rounded up — so any billable call costs at least 1 credit.

What that means for one visitor action

Take a typical analyze this and tell me about it action — roughly 2,000 tokens in, 500 tokens out:

Model your app uses	Credits for that one action
Budget model	2
Vision / document scan	4
Mid-range model	7

These are single-digit numbers. That's the correct order of magnitude for one visitor action, and it's worth stating plainly because we have quoted this catastrophically wrong before: an end-user AI scan does not cost hundreds or thousands of credits. To reach even 1,000 credits in a single call you'd need on the order of a third of a million output tokens — which no ordinary app feature produces.

So if you're pricing a product around per-user AI actions, budget single-digit credits per action, not hundreds. If a number you've been told doesn't look like the table above, ask support to check it rather than repricing your product.

Other things your live app can spend on

What your app does	Approximate cost
Sends an email	0.1 credits
Calls a connected integration (Slack, a CRM, etc.)	0.5 credits
Live web search	2 credits per search (the deeper pro search: 10)
Reads a web page	1 credit per page
An AI step inside a workflow	5 credits
An outside API call inside a workflow	0.2 credits
A database query inside a workflow	0.05 credits
Runs a workflow	1 credit base, plus 0.1 per step
Sends an SMS (including a login code)	1.6 credits
A workflow step that waits for an event	0.1 credits

A research-style model that reads many sources before answering isn't a flat per-search charge — it's billed on tokens like any other model, in the bands above. A long research answer can therefore cost more than a single 2-credit search.

Delays, conditions, and setting variables inside a workflow are free. Waiting on an event is not — it holds resources, so it's 0.1.

Scheduled tasks don't currently draw credits for running. The recurring run itself isn't billed today. What the task does is billed exactly like anything else on this page: if it sends an email, calls an AI model, or sends an SMS, those charges apply. If that changes we'll say so here and on the pricing page before it takes effect.

Image and video generation are billed differently — per image or per render rather than per token. Check your usage view for what yours actually cost rather than estimating, and ask support if a number looks off.

Who pays

You do — not your visitors. Just like hosting, your users never see your credit bill. If your app's value is per-user AI, that cost scales with your success, so either gate those features behind a paid tier in your app or price your offer to cover them.

If you'd rather your users fund their own AI usage, that's a supported model — see Monetize AI usage in your app with buyer credits.

Before you commit to a plan

1. Decide whether your app's value depends on per-user AI, email, SMS, integrations, or heavy data storage. If it doesn't, a free offer is safe.
2. If it does, multiply: actions per user per month × the per-action cost above.
3. Watch your balance after launch, not just while building — this usage happens while your app is live.
4. Keep headroom so a traffic spike doesn't catch you mid-month.

Not sure which kind of app you're building? Tell support what you have in mind and we'll sanity-check it with you before you invest the time.

What to read next

• What are credits? — how the meter works overall
• Using your credits efficiently while building — more building-side savings
• Editing vs rebuilding — the single biggest building lever
• Credits in your published app: who pays for AI usage — the runtime deep dive
• Why errors and retries still use credits — what happens when a turn goes wrong