Fast vs Pro

Appsanic comes with two AI models: Fast and Pro. Both can build anything Appsanic supports. They differ in how they think, how much of your app they see at once, and how much they cost.

Think of Fast as the quick, capable everyday model, and Pro as the slower, more thorough senior engineer.

The 30-second version

• Fast is the default. It writes most things most of the time. Quick to respond, cheap per request, great for anything local in scope.
• Pro is the heavyweight. It plans more deeply, holds more of your codebase in mind, catches edge cases Fast would miss, and stays coherent across hours of work on a big feature.

You don't have to pick upfront. Every paid plan gives you both, and you can switch in the middle of a conversation.

How they actually differ

Pro is more capable in three specific ways.

1. Deeper reasoning

Fast reasons in one or two steps before writing. "User wants a button. Add a button." That's usually fine.

Pro reasons in ten, twenty, sometimes forty steps before committing. It considers your prompt, then the implications, then the implications of those implications, then catches a case you didn't mention, revises its approach, checks against the existing code, and only then settles on a plan.

The difference is like a fast coder and a senior engineer sitting at the same keyboard. Both can type the same words. Only one stops to ask "but what happens when a user does this?" before they start.

2. More of your app held in mind at once

Fast looks at the screens it's about to change. Pro holds your entire project in mind: every screen, every piece of data you store, every helper, every convention earlier features set up.

When Pro edits your sign-in flow, it does so with a view of how sign-in connects to onboarding, settings, billing, analytics, and tests. Fast edits the sign-in screen. Pro edits the sign-in system.

That's why Pro's changes feel coherent with the rest of the app. Fast writes code; Pro maintains a system.

3. Stronger self-correction

Both models can notice they've made a mistake. Pro is meaningfully better at catching its own errors before they reach your code. When Pro realizes that a proposed change would break the timezone handling you set up last week, it adjusts the plan instead of committing the bug.

When to use Fast

• Copy tweaks and style changes ("make the primary color a warmer red", "shorten this paragraph").
• Fixing a bug you've already diagnosed.
• Adding a new screen that follows a pattern your app already uses.
• Small, local changes ("add a confirmation dialog to this button").
• Rapid polish once you're past the big architecture decisions.

On the Free tier, you can explore the planner and see what the agent would do, but actually running the models requires a paid plan. On Pro and Business, Fast is the default for most of your day, and Pro is one click away.

When to use Pro

• Starting a brand-new project.
• A feature that touches a lot of the app (sign-in, payments, push, multi-user permissions).
• A change that would require edits across many screens or files.
• You don't fully know what you want until the agent proposes it back to you.
• A Fast attempt missed something obvious.
• You care about the edge cases you haven't thought of yet.

Simple rule of thumb: if you'd grab a piece of paper and sketch the feature before building it yourself, use Pro. That sketch is what Pro produces before it writes a line.

Roughly what they cost

A quick sense of the gap, from real builds we ran end-to-end:

Pro is roughly 5× the per-request rate of Fast on the same prompt. That sounds steep, but it's what buys you the deeper thinking and the lower variance. Fast is the default not because Pro is expensive, but because most prompts are Fast-shaped - quick, local, well-defined.

The full cost table, the per-run variance, plan allowances, and how to budget for your tier all live in Credits. That's the canonical home for the economics.

Switching mid-conversation

You can swap models between prompts at any point. A common and very effective pattern:

1. Plan the feature on Pro. Let Pro propose the architecture, data, and edge cases.
2. Approve the plan. Pro writes the core.
3. Switch to Fast for polish. Fast is great at the many small follow-up adjustments.

That combo gives you Pro-level architecture with Fast-level iteration speed.

What Pro is not

Pro is not magic. It still makes mistakes. It's not a substitute for taste about what to build. It will build a well-architected version of a poorly-conceived feature just as eagerly as a good one. That part of the job is still yours.

Pro is also not the right tool for every job. A one-line typo fix on Pro costs more than a multi-file refactor on Fast. If the work is Fast-shaped, use Fast.

Next

Understand the economics: read Credits.