Guide›Pricing & credits
Pricing & creditsBeginner5 min

Understanding credits

How credits are counted, what different build phases cost, and how to make sure you never run out mid-build.

What are credits?

Credits are Myndlab's unit of AI compute. Every time Myndlab thinks on your behalf — generating a spec, writing code, or pushing a deployment — it spends a small number of credits from your balance. Think of them like tokens at an arcade: the bigger the ride, the more tokens it costs.

Credits keep your bill predictable. Instead of being surprised by hourly compute charges at month-end, you can see exactly what each action costs before it happens. The credit cost of an operation is always shown in the Build screen before you confirm it.

ℹ
Note.Free-plan credits never expire. On paid plans, your monthly credit allowance refreshes each billing cycle — unused monthly credits may roll over within limits — and any top-up credits you buy stay valid for 6 months.

How credits are counted

Different phases of the build pipeline consume credits at different rates. Here is a breakdown of the three main phases:

1
Spec generation
When you type a prompt and hit Build, Myndlab first generates a structured specification — a plain-English blueprint of the app it will build. This planning step is lightweight — the least expensive part of a build — regardless of how complex your idea is, and the best way to sanity-check scope before committing to a full build.
2
Code generation
This is where most credits are spent. Myndlab writes every file — frontend components, backend routes, database schema, tests — and the cost scales with the complexity of your app: a simple single-model CRUD app is inexpensive, while a multi-role SaaS with authentication, billing, and a dashboard costs more. The Build screen always shows an estimate before generation begins.
3
Deploy
Each time Myndlab packages your app and pushes it to your chosen deployment target — Vercel, Railway, a Cloudflare Worker, or your own server — it costs a small, flat amount. Iterative re-deploys after small edits cost the same flat rate as the first deploy.

Smaller actions like renaming a project, editing environment variables, or browsing your build history do not consume credits. Only AI-driven generation and deployment steps do.

💡
Tip.Run a spec-only pass first. Hit Build, review the generated spec, and cancel before code generation starts. You'll spend only the small spec cost to get a detailed breakdown of what Myndlab plans to build — and you can refine your prompt before committing the full cost.

Credit tiers and topping up

Myndlab ships with four plans. Each plan includes a monthly credit allowance that refills on your billing date:

1
Free
Starts with a grant of free credits plus a daily build limit. These credits never expire. Ideal for evaluating Myndlab before committing.
2
Pro Lite — 200 credits / month
Covers typical solo-developer use: a handful of medium-complexity apps and regular iterative updates.
3
Pro — 300 credits / month
More headroom for active builders, plus support for any frontend/backend stack (incl. .NET).
4
Pro Plus — 400 credits / month
Designed for full-time builders and freelancers shipping production apps, with mobile apps and priority generation.

If you exhaust your monthly allowance before your billing date, paid plans can top up instantly from the Billing page. Top-up packs come in 50, 120, and 350 credits, and stay valid for 6 months from purchase. See the Pricing page for current prices.

Monitoring usage

Your credit balance is always visible in the top-right corner of the Build screen. Clicking it opens the Usage panel, which shows:

1
Current balance
How many credits remain in your current billing period, plus any rolled-over or top-up credits.
2
Usage by project
A breakdown of credits spent per project this month. Useful for client billing or tracking which ideas are consuming the most resources.
3
Usage by operation
A log of every spec, code-gen, and deploy event with its credit cost, timestamp, and project name.

Tips to avoid waste

A little planning before hitting Build can save a significant number of credits. Here are the habits that experienced Myndlab users rely on:

1
Write a precise prompt first
Vague prompts like 'make me an app' force Myndlab to make assumptions. Those assumptions often require correction — which means another generation cycle and more credits. Spend two minutes writing a prompt that names the user roles, key actions, and data the app manages.
2
Use spec review before committing
Always review the generated spec before approving code generation. The spec step is cheap, and catching a misunderstanding at that stage avoids a far costlier correction after the fact.
3
Iterate with targeted change requests
When asking Myndlab to update an existing build, be specific. 'Add a CSV export button to the Users table' costs far fewer credits than re-generating the entire dashboard because your prompt was ambiguous.
4
Batch related changes
If you have three small tweaks in mind, describe them all in one prompt rather than sending three separate messages. Each generation run has a base overhead, so batching saves the fixed cost.
5
Lock completed sections
Once a section of your app is exactly right, mark it as locked in the Build screen. Locked files are excluded from future generation passes, which reduces both token cost and the chance of unintended changes.
⚠
Watch out.Switching your entire stack mid-project (for example, from FastAPI to Express) triggers a near-full regeneration. If you're unsure about your stack choice, decide before starting the first code-gen pass — not after.