3.2 — Model options & cost
On this page
3.2 — Model options & cost
VibeMap runs generations on named frontier models from OpenAI, Anthropic and Google. You can usually leave the defaults alone — but here's exactly what's happening if you want to know.
Default model behavior
If you don't pick a model, VibeMap uses one pinned per generation type. The pinning is a fixed table, not a heuristic — the same generation type always uses the same model, so output stays consistent run to run. Roughly:
- Summary, features, user stories, acceptance criteria — Gemini 3 Flash. Fast, cheap, reliable at structured output.
- Pages, schema, pseudocode — GPT-5 Mini. Better at following a strict JSON shape.
- Personas — GPT-5. Deep nested objects reward stronger reasoning.
- Files — Claude 4.5 Sonnet. Code-generation quality.
- Dependency analysis and sprint planning — Gemini 3 Flash.
For most users this is exactly right, and it's the only behaviour available below Pro.
Choosing a model yourself
The model selector on a generation button is Pro and above (showModelSelector). On Free and Starter it isn't shown — those plans always run the pinned model above.
Every plan carries an allow-list of named models. You cannot pick outside it:
| Free | Starter | Pro | Team | Enterprise | |
|---|---|---|---|---|---|
| GPT-5 Nano | ✅ | ✅ | ✅ | ✅ | ✅ |
| Gemini 3 Flash | ✅ | ✅ | ✅ | ✅ | ✅ |
| GPT-5 Mini | ❌ | ✅ | ✅ | ✅ | ✅ |
| Claude 4.5 Haiku | ❌ | ✅ | ✅ | ✅ | ✅ |
| Gemini 2.5 Pro | ❌ | ✅ | ✅ | ✅ | ✅ |
| GPT-5 | ❌ | ❌ | ✅ | ✅ | ✅ |
| GPT-5.2 | ❌ | ❌ | ✅ | ✅ | ✅ |
| Gemini 3 Pro | ❌ | ❌ | ✅ | ✅ | ✅ |
| Claude 4.5 Sonnet | ❌ | ❌ | pinned only | ✅ | ✅ |
| Claude 4 Sonnet | ❌ | ❌ | ❌ | ✅ | ✅ |
| Claude 4 Opus | ❌ | ❌ | ❌ | ❌ | ✅ |
The allow-list is enforced server-side, not just in the dropdown. An API or MCP caller that names a model outside its plan doesn't get an error — the request silently falls back to the pinned model, so a smuggled model id can never spend someone else's tier.
Greyed out, with a reason
A model your plan can't run isn't hidden from the dropdown — it's shown disabled with a short reason. Hiding it reads as "this model doesn't exist", which is the wrong answer when it's the one you were looking for. The reasons, most specific first:
| What you see | What it means |
|---|---|
| Not code-capable (or not research-capable) | The model is fine on your plan, but wrong for this particular task. The App Builder needs a code-capable model; the business case needs a research-capable one. |
| 🔒 Premium limit reached | You've spent this month's premium allowance. Economy models still work. |
| 🔒 Auto limit reached | You've spent this month's economy allowance. |
| 🔒 Upgrade to unlock | The model isn't on your plan's allow-list. |
The distinction matters: "premium limit reached" sends you to the billing page, and telling you that when the real problem is that the model can't write code sends you there to fix something upgrading won't fix.
Economy vs premium — and what a generation costs
Every model is classified economy (auto) or premium, and your plan carries two separate monthly allowances:
| Free | Starter | Pro | Team | Enterprise | |
|---|---|---|---|---|---|
| Economy tokens / month | 300K | 1.5M | 6M | 15M | 40M |
| Premium tokens / month | 0 | 250K | 1M | 3M | 8M |
Free has no premium allowance at all, which is the real reason its allow-list is two economy models.
Within those allowances, tokens are weighted by model cost. Model prices span roughly 190× from the cheapest to the most expensive, so if every model drew "one token" the rational move would be to always pick the most expensive one. Instead each model has a multiplier relative to a baseline (Gemini 3 Flash = 1×), and your allowance is debited raw tokens × multiplier. Multipliers are rounded up to legible steps — you'll see figures like 0.25×, 1×, 4×, 200× rather than 173.7×.
Practically: a premium model doesn't just draw from a smaller bucket, it drains that bucket faster. Both facts are the same mechanism.
Current usage is on the Billing page, under Usage & Analytics.
⚠️ Running out of premium tokens does not silently downgrade you. The run is refused with
402andTOKEN_BUDGET_EXCEEDED. Nothing is quietly re-routed to a cheaper model behind your back.
Or don't spend VibeMap tokens at all — author with your own agent
Every generation type here has a second engine that costs you nothing on VibeMap's meter: instead of VibeMap's hosted models, your own connected IDE agent authors the spec over MCP and VibeMap simply stores it. VibeMap runs no server-side LLM on that path, so the work runs on your agent's own tokens and never draws down your VibeMap allowance.
- Idea-first:
/mcp__vibemap__author_idea— your agent authors the whole graph (personas → pages) from the project idea. - Code-first:
/mcp__vibemap__author_spec— same graph, grounded in your entire repo. - Schema (run last):
/mcp__vibemap__author_schema— the Postgres data model in onevibemap_create_schemacall.
The prompt bodies expand server-side (GET /api/mcp/prompts). MCP access is on every plan — what varies is which entities your agent may author, since authoring pages or schema still needs the same pages / schema capability a hosted generation would. See the MCP server overview and the user-facing Two ways to generate.
Tips for keeping cost down
- Regenerate parts, not the whole project. If only your acceptance criteria are off, regenerate just those — don't rerun the whole pipeline.
- Leave the pinned model alone unless you have a reason. The pinning table is already tuned per task; picking a premium model for a job Gemini 3 Flash does well just spends your premium allowance faster.
- Edit before regenerating. A 30-second edit often beats a 3-minute regenerate-and-hope.
- Let your agent author it. The MCP path costs nothing on VibeMap's meter at all.