Introducing Sanic Pro

We've been watching the ceiling of Fast for three months.

It's a good ceiling. Fast, our default model, writes real React Native code, wires up Supabase, drops in Stripe checkout, pushes to your GitHub repo, and does most of it in seconds. For a first build, a quick edit, a CSS tweak, or a new screen, Fast is the right tool. Roughly 90% of what users ask for lands comfortably inside what Fast handles well.

The other 10% is a different shape. You ask for something large. Something ambiguous. Something that touches fifteen files and has to stay consistent across all of them. Something where you don't fully know what you want until the agent proposes it back to you. That 10% is what Sanic Pro is for.

Today, we're launching it.

What "more intelligent" actually means

There's a tempting intuition that a smarter AI model just means "more knowledge" or "a bigger training set." That's not what makes Pro different from Fast. They're built from the same foundation. They know the same libraries, the same patterns, the same frameworks.

Pro is more intelligent in three specific, measurable ways:

1. Deeper reasoning chains. Fast typically reasons in one or two steps before producing a response. "User wants button. Add button." Pro reasons in ten, twenty, sometimes forty steps before it writes anything. It considers your prompt, then it considers the implications of your prompt, then the implications of those implications, then it catches a case you didn't mention, then it revises its approach, then it validates the revised approach against the existing codebase, and only then does it commit to a plan.

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

2. A larger working context. Fast looks at the files it's about to change. Pro holds your entire project in mind at once: every screen, every schema column, every helper function, every component already built, every convention the previous features established. When Pro edits your authentication flow, it does so with a view of how that flow connects to onboarding, to settings, to the billing page, to the analytics events, and to the tests. Fast edits the auth file. Pro edits the auth system.

This is why Pro produces changes that feel coherent with the rest of the codebase. Fast is writing code. Pro is maintaining 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. It reasons about edge cases the way a senior engineer does during code review, before the review. When Pro catches that a proposed change would break the timezone handling it established in a feature you launched last week, it adjusts the plan rather than committing the bug. Fast tends to commit first and fix on the next round.

Put these three together and you get a model that doesn't just type faster. It thinks deeper, sees more of your project, and polices its own output more strictly.

What Pro does differently in practice

The three characteristics above translate into three visible behaviors when you hand Pro a task.

It plans before it writes. Fast starts typing almost immediately. That's what makes it fast. Pro pauses. Before a single file gets touched, Pro produces a full product plan: screens, data models, flows, connectors, and the edge cases your prompt didn't mention but that will matter the first time a real user lands on the app. You see the plan. You can approve it, adjust it, or reject it. Work starts only when you say go. Ten seconds of planning routinely saves ten minutes of rework.

It holds the whole codebase. Fast works on the files it's touching. Pro holds your entire project in context: every screen, every schema column, every helper, every dependency, every message earlier in the conversation. When you ask Pro to rewrite your authentication flow, it updates the login screen, the auth store, the API routes, the type definitions, the Supabase policies, and the tests in one atomic change that you review together. This is the difference between editing a file and understanding a system.

It stays coherent across hours. Fast works in short bursts. Pro can run for hours without losing the thread. You can describe a whole feature (a reviews system, an invoice flow, a multi step onboarding), hand it off, close your laptop, and come back to a merged pull request with a summary of every decision Pro made while you were gone.

A concrete example

Take a real prompt we've seen: "Let's redesign the onboarding so users invite a friend before they see the home screen."

On Fast, that reads as "change the onboarding screen." Fast opens the onboarding screen, adds a friend invite input, builds it. What it builds works. What it builds also quietly ignores five things you'd have asked for if someone had asked you first.

On Pro, the same prompt produces a plan like this:

I'll need to:

• Add a connections table (doesn't exist yet) with invitee and inviter IDs, status, invited_at timestamp, and a Supabase RLS policy scoped to both parties.
• Flip the auth store's first_launch flag to needs_invite so it can distinguish brand new users from returning ones who signed up through a friend.
• Change the home screen's empty state. The assumption "user arrives alone" no longer holds once invites exist.
• Handle the case where the invited friend doesn't yet have an account. Do they receive an SMS, an email, both, or neither? I'll default to email. Let me know if you want SMS too.
• Add an analytics event for invite sent and invite accepted so you can measure the onboarding funnel.

Confirm and I'll build it.

Forty five seconds for Pro to produce that plan. Twelve minutes to build the feature after you approve.

Fast's version of the same prompt: four minutes to build, then twenty minutes over the next week discovering the things it missed and asking for them one at a time.

The difference isn't raw speed. The difference is that Pro's work doesn't need a second pass.

Why planning changes the economics

There's a common objection to "the agent thinks for ten seconds before writing": isn't that time wasted? Wouldn't it be faster to just start?

The math says no.

We instrument every agent run. On Pro's hardest requests, the planning phase adds about 15% to the total token budget. In exchange, it reduces the number of follow up corrections by 60 to 70%. Put another way: on complex features, Pro finishes the entire arc (initial build plus revisions) in fewer total tokens than Fast does, because Fast spends so much of its budget revising work it didn't plan well the first time.

The framing that matters isn't "tokens spent thinking." It's "tokens spent building a working feature." Every second the agent spends reasoning before writing is a second you don't spend reviewing, re explaining, and asking it to try again.

This is also why Pro costs more per request than Fast. More reasoning means more tokens means higher API costs. But if you're doing work that actually benefits from the reasoning, you come out ahead on total spend. If you're doing trivial work, you don't, which is exactly why Fast is still the default.

When to use which

Don't pick upfront. Every paid plan includes both, and you can switch in the middle of a conversation. But here's how to decide in the moment:

A heuristic: if you'd grab a piece of paper and sketch the feature first before coding it yourself, use Pro. That paper sketch is exactly what Pro produces before it types.

A practical Pro workflow

The users getting the most out of Pro tend to follow a loose pattern:

1. Start a prompt with intent, not instruction. Instead of "Add a button that saves to localStorage," try "I want users to be able to save a draft while offline and sync it when they reconnect." The first prompts a line of code. The second prompts a feature plan.

2. Read the plan seriously. The plan is where the work gets architected. Push back on choices you disagree with. "I don't want email notifications, just inside the app" or "keep the existing Zustand store, don't introduce Redux" at this stage is five words. At the "code written" stage it's an hour of backing out work.

3. Let it run. Once the plan is approved, don't interrupt. Pro's value comes from holding the whole plan in its head at once. Stop it halfway and you've paid the planning cost without getting the planning benefit.

4. Start a fresh conversation for unrelated work. Pro is most coherent when each session is about one logical unit. If you just launched payments and now you want to redesign the feed, start over.

How pricing actually works

Credits haven't changed. Each prompt costs a few credits based on what you're building and which model you use. We re-ran the matrix on real builds in May 2026 and these are the ranges we measured:

• Tiny tweak (one-line text, swap a colour): Fast 2–4 cr · Pro ≈25 cr
• Small feature (counter, single-screen form): Fast 2–3 cr · Pro ≈20 cr
• Mid-size feature (2 screens with navigation and saved data): Fast 9–18 cr · Pro 39–44 cr
• Full app skeleton (4 features, navigation, persistence): Fast 24–28 cr · Pro 61–66 cr

Pro is roughly 5 times the per request cost of Fast. That's a real gap. It's why Fast is the default. You shouldn't pay Pro rates for work Fast does well.

One thing we didn't expect when we measured: Pro is far more deterministic than Fast. On mid-size and full app builds Pro lands inside a 5–10% band run-to-run; Fast varies more like 20–35% because shorter thinking means more retries on harder prompts. If you're budgeting credits exactly, Pro is the predictable one.

Quick math on real usage: a typical day for an active Pro user (maybe five prompts, mix of Fast and Pro on smaller features) runs 40 to 80 credits. At the $25 Pro tier (200 cr) that's 2 to 5 days of heavy work. At the $100 tier (800 cr) you're easily 2 to 3 weeks in.

There are no hourly limits. Spend your monthly allowance at whatever cadence fits you. We don't care if you burn it all on a Saturday sprint. If you run out, you can buy more credits on demand from inside the app.

What Pro is not

To save you from disappointment: Pro is not magic. It still makes mistakes. It is not a substitute for having taste about what to build. It will build a well architected version of a poorly conceived feature just as eagerly as it builds a good one. The part where you decide what's worth building is still yours.

Pro is also not cost efficient for every task. A one file typo fix on Pro costs the same as a multi file refactor on Fast. If you're doing trivial work, Fast is the right call, both for your wallet and because the extra planning overhead on trivial tasks is just friction.

Pro also isn't a benchmark number. It's not better than Fast at every narrow metric you could measure. On small, well defined tasks, the two produce similar code in similar time. What Pro is optimized for is the messy middle: ambiguous prompts, large surface areas, features with edge cases that don't show up until real users try them. That's where the deeper reasoning earns its cost.

Available today

Sanic Pro is live on every paid Appsanic plan, Pro and Business alike. Open any conversation, click the model selector in the prompt bar, switch to Pro, and ask.

If you've been sitting on a feature you couldn't quite bring yourself to hand off (the one you kept rewriting requirements for, the one with too many moving pieces), give it to Pro. That's exactly what we built it for.

Welcome to the ten percent.