How credits work

A credit is a prepaid unit of platform usage. It is not a token, not a message and not a minute of compute. It is an abstraction that lets one balance cover several different underlying costs: model inference, sandbox compute, build and deploy pipelines, and the orchestration layer that coordinates the agents.

Credit

The unit of account. Retail price at the base tier is $0.25 per credit, or $25 for 100 credits. Larger packs carry volume savings, described in section 11.

Token

The unit a language model reads and writes. Roughly 4 characters of English, so about 750 words per 1,000 tokens. Rates in section 5 are quoted per million tokens.

Run

One agent turn: your message, the context the agent reads, the tools it calls, and the reply and edits it produces. A run is the thing that gets billed.

Plan mode

A discussion and planning turn. The agent reads the project and answers or writes a plan, but does not modify files. Flat priced.

Build mode

An implementation turn. The agent reads files, writes code, runs installs, typechecks and builds, and can deploy. Usage priced.

Grant

Credits given rather than bought: the one off welcome grant, monthly plan credits, referral rewards and goodwill adjustments. Section 9 covers referral rewards in full.

The charge for a single build run is assembled in this order. Every step is deterministic, so the same run with the same inputs produces the same charge.

1. Model selection. The router picks a model from your project default, your workspace routing rules, or the platform default, in that order.
2. Rate lookup. The chosen model id is matched against the rate card in section 5. Each tier has an input rate and an output rate, both quoted in credits per one million tokens.
3. Token accounting. When the run finishes, the provider reports input tokens (your message plus the project context, files, tool results and prior turns the agent read) and output tokens (the reply plus every file it wrote).
4. Raw cost. Input tokens divided by one million, times the input rate, plus output tokens divided by one million, times the output rate.
5. Key discount. If the run used your own provider key, the raw cost is multiplied by 0.1, because you are paying the model provider directly.
6. Minimum charge. The result is floored at 1 credit on platform keys, or 0.2 credits on your own key, so a trivial run still carries its orchestration cost.
7. Rounding. The final number is rounded to four decimal places and written to the ledger with the model name and the token counts attached.
8. Deduction order. The credits are taken from your balance in the order set out in section 10, and the run appears in the activity table immediately.

Plan mode is charged at a flat 1 credit per message, whatever the model and whatever the length of the plan. That includes discussion turns, questions about how something works, architecture reviews and plan revisions. The flat price exists so that thinking before building is cheap and predictable.

• Every plan mode message costs 1 credit, including the ones where you only ask a question.
• Approving a plan is free. Only the messages themselves are billed.
• Revising a plan costs 1 credit per revision message, so a long back and forth is still inexpensive relative to building the wrong thing.
• Plan mode never writes files, so it cannot consume sandbox or deploy usage.

Build mode is usage based. Cost tracks the real work: the amount of project context the agent has to read, the number of tool calls it makes, and the volume of code it writes. Two requests that sound similar can differ several fold in price because one touches three files and the other touches thirty.

Rates are credits per one million tokens. A model id is matched to the first tier whose pattern it fits, and anything unmatched falls back to the standard tier.

Output is always the expensive side, typically five times input, because generated code is what you are actually buying. This is why full file rewrites cost markedly more than targeted edits of the same file.

Each example uses platform keys and applies the formula in section 2 exactly. Token counts are realistic but illustrative.

• Minimum on platform keys: 1 credit per build run. Very small edits therefore cost the same as a medium one, which is why batching related tweaks into one message is cheaper than sending five.
• Minimum on your own key: 0.2 credits per build run, covering orchestration, sandbox and storage only.
• Plan mode is exactly 1 credit and no minimum logic applies.
• Charges are rounded to four decimal places. Balances are displayed to two decimals below 10, one decimal below 100, and whole numbers above that.
• There is no rounding up to whole credits beyond the minimum, so a 1.26 credit run is charged as 1.26.

These never consume credits.

• A try to fix retry that follows a compiler, typecheck or test error the agent itself produced.
• Approving, rejecting or reading a plan.
• Browsing your projects, files, diffs, logs, activity and settings.
• Reverting to an earlier version of a project.
• Viewing a live preview once the dev server is already running.
• Creating an empty project, inviting members, and managing roles.
• Reading a public project page shared with you.
• Signing in, resetting a password and connecting a provider key.

Balances are made of separate buckets, and the credits page shows each one on its own so you always know which part of your balance is expiring and which is not.

• There is no daily refill on the free plan. The 25 credit grant is a single one off amount.
• Enterprise allowances are agreed in an order form and granted to the workspace directly.

Deduction always follows the order below, which is designed to protect the credits you paid for and to spend anything with a deadline before anything that does not have one.

1. Welcome grant credits, because they are free but finite.
2. Monthly plan credits, because they expire at the end of the billing period.
3. Referral reward credits, because they carry a 12 month expiry.
4. Purchased credits, last, because they never expire.

A single run can straddle two buckets. When that happens the ledger records one charge and the balance panel reflects the split.

Packs are one off purchases that sit on top of any plan. Price is a flat $0.25 per credit up to 800 credits, then volume savings apply.

• Packs are charged once, immediately, and credited to the workspace on success.
• Purchased credits are workspace level, not per member, so any member with permission can spend them.
• Until a payment provider is connected on this deployment, purchases are recorded in the ledger in test mode without charging a card.

Connect an OpenAI, Anthropic, Google or OpenRouter key in workspace settings and runs that use it are charged at ten percent of the normal rate, with a 0.2 credit minimum. You are then billed by the model provider directly for inference, and NovaBuild bills only for orchestration, sandboxes, storage and pipelines.

• Keys are encrypted at rest and are only ever read inside server functions. The browser sees a masked last four digits and metadata, never the key.
• A key is verified with a minimal probe request when you save it, so a bad key fails immediately rather than mid run.
• If your key is rate limited or out of quota, the run fails and no model charge is incurred, though the orchestration minimum may still apply.
• You can revoke a key at any time. Runs immediately fall back to platform keys and full pricing.

Sandboxes, builds and deployments are covered by the same credit balance. They are not billed as separate line items at the moment, but they are the reason the minimum charge and the orchestration component exist, and they are subject to fair use limits.

The managed backend, meaning the database, authentication, file storage and server functions behind a project, and the AI gateway that a generated app calls at runtime, are charged in credits from the same balance as plan and build messages. Backend cost depends on instance size, activity and data transfer. Gateway cost depends on the model and the number of tokens the app itself sends and receives.

Every workspace receives a free monthly allowance that covers ordinary backend usage. The allowance is separate from plan credits and does not roll over.

• Beyond the allowance, backend and gateway usage is deducted from the workspace balance like any other spend.
• Paid plans can buy more credits at any time from credits and billing. Free plan workspaces upgrade first, then buy.
• A project that is idle costs close to nothing, since most backend cost tracks activity rather than time.
• Connecting your own provider key removes the gateway component of runtime AI cost for that project.

There are four plans. They differ in the credits included each period and in the team features around them, not in the rate card: a run costs the same on every plan.

• Paid tiers scale from 100 up to 5,000 credits per month. The ladder in section 11 shows the price at each step.
• Changing plan takes effect from the next billing period, and any unused monthly credits from the old period expire as usual.
• Purchased packs are unaffected by a plan change, since they do not expire.

Workspaces can cap how much any individual member is allowed to spend in a billing period, so one person cannot exhaust a shared balance.

• Set a default cap for every member in workspace settings.
• Override the cap for a specific person in the members list.
• When a member reaches the cap they cannot start new build runs until the next period or until the cap is raised.
• Caps apply to spend, not to reading. A capped member keeps full access to projects, previews and history.
• Owners and admins can always see who spent what in the activity table.

• Open credits and billing for the live balance, the split across each bucket, lifetime usage and the full activity ledger.
• Each ledger row shows the timestamp, the event, the model, input and output tokens, and the credits charged or added.
• The progress bar reflects how much of the current period allowance is still available.
• Purchases, grants and adjustments appear as positive rows; runs appear as negative rows.

• Build runs stop before any model call is made, so you are never charged into a negative balance.
• Plan mode also requires a credit, since it is flat priced at one credit per message.
• Everything read only stays available: projects, files, diffs, previews already running, exports and deployed sites.
• Existing deployments keep serving. Running out of credits does not take a live site down.
• Buy a pack, wait for the next billing period on a paid plan, or connect your own provider key to resume at a tenth of the cost.

Exact estimates are not possible, because cost depends on the size of the codebase, the number of iterations and how precisely each request is scoped. These bands come from typical usage and should be treated as planning ranges, not quotes.

1. Plan first. A one credit planning turn regularly saves several build credits of exploration.
2. Name the target. Say which screen, component or field you mean rather than describing it loosely.
3. Batch related tweaks into a single message so the one credit minimum is paid once, not five times.
4. Keep the scope of each message to one concern, so a failed turn is cheap to redo.
5. Match the model to the task. Fast models handle copy, spacing and simple refactors well.
6. Ask for targeted edits rather than full file rewrites, since output tokens dominate the bill.
7. Fix errors with the free retry path instead of writing a fresh instruction.
8. Delete dead files and unused dependencies so the agent reads less context.
9. Attach a screenshot or exact copy for design changes rather than iterating in prose.
10. Avoid asking for the same change twice in different words. Read the diff first.
11. Connect your own provider key once your usage becomes steady.
12. Set member caps so a shared balance cannot be drained by one long session.

Credits are prepaid and, as a rule, consumed credits are not refundable. Where a charge is clearly wrong, we correct it.

• A platform fault that caused a failed or duplicated run is credited back on request.
• Unused credits from a pack may be refundable within the window set out on the billing page.
• Model provider outages that produced a charge without a usable result are treated as platform faults.
• Dissatisfaction with a generated result is not by itself a refundable event, since the run consumed real compute.
• Full terms live on the billing and refunds page, which prevails if the two pages ever disagree.

Does plan mode really consume credits?

Yes. Plan mode costs one credit per message. The only free messages are try to fix retries after an error.

Why did two similar requests cost different amounts?

Build mode is usage based. The more expensive run read more context or wrote more code, or used a more capable model.

Do unused credits roll over?

Monthly plan credits do not roll over. The welcome grant and purchased credits do not expire.

Can I buy credits on the free plan?

Packs are available once a payment method is on file. On this deployment purchases are recorded in test mode until a provider is connected.

Are credits per user or per workspace?

Per workspace. Member caps control how much of the shared balance any one person can spend.

Does a deployed site keep costing credits?

No. Hosting a deployed site does not consume credits. Only agent runs do.

What happens if a run fails halfway?

You are charged for the tokens actually consumed, subject to the minimum. If the failure was ours, ask for an adjustment.

Can I cap spending outright?

Yes, indirectly and precisely: do not hold purchased credits, and set member caps. Runs stop rather than overdraw.