Guide · 14 min read
Recommended models in SpinBuild: Claude Opus 5, GPT-6 Astra, Gemini, and the rest
The shortlist at the top of the picker — Claude Opus 5, Sonnet 5, GPT-6 Astra, DeepSeek, Qwen, Kimi, and Auto — plus Gemini and the wider catalogue.
Why the picker has a shortlist
SpinBuild writes a web app from a description: frontend, backend, and a private Postgres for that project. You review every change as a diff and accept it before it ships. The model you pick decides how that first draft — and every follow-up — is written. It does not change what you approve, where the live URL lives (your-app.apps.spinbuild.ai), or that Starter is free with no credit card.
The dropdown lists hundreds of chat models from Anthropic, OpenAI, Google, xAI, DeepSeek, Meta, Mistral, Qwen, Moonshot, and others. Scrolling that list every time you open a project is a waste of attention. So the top of the picker is a curated shortlist for building software. Everything else stays available under its vendor further down.
This post walks through that shortlist in the same order you see it in the product, then covers Google Gemini and the rest of the catalogue so you know what “recommended” means and what it does not.
Anthropic
OpenAI
Google
DeepSeek
Qwen
Moonshot
Meta
Mistral
xAI
How to read a model row
Each row shows the context window, the price per million tokens (input and output), and badges for thinking (the model exposes reasoning) and images (it accepts attachments). Your choice is remembered per browser. New accounts start on Claude Opus 5.
The Think control next to the picker sets how much the model reasons before answering: none, low, medium (default), or high. Higher levels help on schema design, tricky refactors, and debugging. They also cost more time and credits. For a copy tweak or a small UI change, low or none is enough.
Credits scale with the work the request actually did. A frontier model costs many times what the same prompt costs on a budget one. Prices in the picker are the live OpenRouter numbers; the credits a message used appear next to it when it finishes.
The recommended shortlist
These seven sit at the top. Reach for them in this order of intent, not prestige: pick the job, then the model.
Claude Opus 5
Reach for Opus when a feature has to be right the first time. It holds a large codebase in view and reasons carefully through refactors, multi-file changes, and rules that must not be simplified away. If your description names several screens and the data that must survive a refresh, start here.
Opus is the slowest and most credit-heavy option on the shortlist. That is the trade. Use it for the hard turn, then switch down for cleanup if you want to stretch the month.
Claude Sonnet 5
Sonnet is fast enough for rapid iteration and strong enough to carry most of a build end to end. Day-to-day work — add a field, fix a button, tighten a form, follow a short reject note — usually belongs here. It is the model you leave selected when you are shipping small accepted diffs in a row.
If Opus feels like overkill and a budget model keeps missing the instruction, Sonnet is the middle that most projects live in.
GPT-6 Astra
Astra is built for sprawling projects. When a question spans a dozen files, or you need the model to keep the whole repo shape in mind while it proposes a change, this is the OpenAI row on the shortlist. Feed it a precise description of what must stay the same and what must change; large context only helps if the instruction is still specific.
Use it when “look across the project” is the job. Prefer Sonnet or a cheaper model when the job is a single screen you can name in one sentence.
DeepSeek V4.1 Flash
DeepSeek stretches monthly credits the furthest. It is ideal for the long tail: small edits, copy tweaks, cleanup, renaming a label, fixing a layout that almost works. After a strong model lands the hard feature, switch here for the polish passes.
Do not expect it to replace Opus on a multi-screen first version with tricky data rules. Expect it to make the cheap turns cheap.
Qwen3.8 Max
Qwen is a serious coding model at a fraction of frontier price. It follows long, precise instructions across many files well. When you already know exactly what the diff should do — “add a pickup time to the order, store it in Postgres, show it on the list, do not touch the menu screen” — Qwen is a strong fit.
Pair it with a clear reject note when the previous turn was close. Precision in, precision out.
Kimi K3
Kimi plans multi-step changes and sticks to them. Reach for it when a single prompt should produce a whole feature: several files, a clear sequence, and a result you can review as one diff. It is a good match for “build the order flow end to end” once you have named the screens and the data.
Still read the diff. A confident plan is not an accepted change. Accept only what matches the description.
Auto
Not sure which model to use? Auto reads each request and routes it to a model that suits it, so you can keep describing the web app instead of managing the shortlist. It is the right default when you are exploring, or when the day’s work mixes hard turns and tiny polish and you do not want to switch by hand.
If a turn matters enough that you already know you want Opus or Astra, pick that model yourself. Auto is convenience, not a override of your judgment on the hard jobs.
Google Gemini and the rest of the catalogue
Below the shortlist, the picker groups models by vendor. Google Gemini sits there with the other Google chat models — same OpenRouter catalogue, same live pricing and context numbers in the row. Pick Gemini when you specifically want that family for a turn; it is not on the curated top row because the shortlist stays focused on the models we recommend first for building full web apps in SpinBuild.
You will also see older Claude versions, the GPT-5 family and other OpenAI variants, Llama from Meta, Mistral, xAI, and more. Search by name, id, or vendor. The badges and prices are the same format as the shortlist. Availability and naming follow what OpenRouter currently exposes; when a slug retires, the product falls through to the next candidate we configured for that slot.
A short rule: use the shortlist unless you have a reason to leave it. Use the wider catalogue when you already know the vendor or family you want, or when you are comparing a specific model’s price and context for a long session.
A practical way to choose
- First version of a multi-screen web app. Claude Opus 5, or Auto if you prefer not to decide.
- Everyday iteration after the shape is right. Claude Sonnet 5.
- Questions that span the whole project. GPT-6 Astra.
- One precise, instruction-heavy coding pass. Qwen3.8 Max.
- A whole feature from one well-written prompt. Kimi K3.
- Cheap polish and cleanup. DeepSeek V4.1 Flash.
- You want Google’s Gemini specifically. Pick it from the Google section under the shortlist.
Whatever you pick, the sequence does not change: describe the job, read the diff, accept or reject, click through the private preview, publish when the path works. The model writes the proposal. You decide what lands in the project.
What the model does not change
Starter stays free. No credit card. The result is still a web app with a frontend, a backend, and a private Postgres per project. The preview stays private. Publish still puts the accepted version on your-app.apps.spinbuild.ai with HTTPS — not a custom domain. GitHub, if you connect it, is still a one-way push to a repository you own. SpinBuild is not a coding assistant inside your editor, and it is not a built-in sign-in product for your end users.
Those limits are the product. Switching from Opus to DeepSeek does not add a custom domain or two-way GitHub. It only changes how the next diff is written and how many credits that turn costs.
Start with the shortlist
Open a project at spinbuild.ai, open the model dropdown, and you will see Claude Opus 5, Claude Sonnet 5, GPT-6 Astra, DeepSeek V4.1 Flash, Qwen3.8 Max, Kimi K3, and Auto at the top — with Anthropic, OpenAI, DeepSeek, Qwen, and Moonshot logos on those rows. Google Gemini, Meta, Mistral, xAI, and the rest of the catalogue sit underneath when you need them.
Pick the model for the job in front of you. Keep the review. Questions about accounts, preview, or a deployed web app go to support@qyant.dev.