> For the complete documentation index, see [llms.txt](https://studio-docs.sandbox.game/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://studio-docs.sandbox.game/working-efficiently-with-ai/choosing-the-right-model-for-the-task.md). # Choosing the right model for the task Picking a model is a cost decision and a quality decision at once. Get it wrong in one direction and you burn credits on a task a cheaper model handles fine. Get it wrong in the other and you spend an afternoon re-prompting a model that was never going to solve your bug. ## **The Core Explanation** ### **Think in tiers, not model names** Models change every few months. The tiers do not. Every model in the picker belongs to one of three: | Tier | Reach for it when | Cost | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | **Fast** | The task is small and well-defined: rename something, add a property, write boilerplate, answer a question about code you can point at | Low | | **Strong reasoning** | The task spans multiple files, the cause of a bug is unclear, or the change touches save data, networking, or build configuration | Medium–high | | **Strongest** | Architecture decisions, long complex tasks, or a strong-tier model has failed twice | Highest | The deciding factor is **risk, not size**. A one-line change to how player data saves deserves a strong model. A fifty-line boilerplate UI panel does not. ### **Current models by tier** Open the model picker at the top of the chat panel, or press `Ctrl+/` / `Cmd+/` to cycle models. Exact names depend on your plan. This table matches what Cursor documents as of the review date. | Tier | Models in the picker today | | ---------------- | ------------------------------------------------------------ | | Fast | Auto, Composer 2.5 | | Strong reasoning | Cursor Grok 4.6, Cursor Grok 4.5, Claude Sonnet 4.6, GPT-5.5 | | Strongest | Claude Opus 5, GPT-5.6 Sol | Auto is a router, not a fixed model. It picks from the pool for everyday work. Use it when you want Cursor to choose. Pick a named model when you need a specific tier. {% hint style="info" %} *TIP: For routine implementation with a clear brief and good reference files, Auto is a reasonable starting point. Override it when the task is high risk or Auto keeps landing on a tier that is not solving the problem.* {% endhint %} *Model names and prices last verified: 18 Aug 2026.* ### **Escalate deliberately, de-escalate quickly** Two failed attempts at one tier means the tier is wrong. Move up **one** tier, start a fresh chat, and open with a two-sentence summary of what was tried and what failed. Do not escalate out of impatience. A tighter prompt at the current tier often beats a vaguer prompt at a more expensive one. Before you switch, clarify the problem, add the relevant files, and state what you already tried. The moment the hard part is solved, drop back to the fast tier for follow-up edits. Paying strongest-tier prices to rename variables is a common way to waste credits. When you switch models mid-problem, always start a new chat. A fresh model inheriting a confused conversation performs worse than a fresh model with a clean summary. ### **When the strongest tier is the right first choice** Go straight to the strongest tier when getting it wrong would mean tearing out and rebuilding a significant part of the project: complex system design, architectural decisions that shape the whole game, systems that are expensive to rebuild if they are wrong. If a follow-up prompt can correct the mistake, start lower. ### **How this applies to Sandbox Studio** Routine Sandbox Studio work (adding a property to an existing node, creating a behaviour that follows an established pattern, hooking up an input binding) is fast-tier territory. The patterns exist in the project, Cursor can read them, and the implementation is well-defined. System design in Sandbox Studio (how a new multiplayer mechanic should use replication, how a complex UI flow should be structured, how an enemy AI system should integrate with the rest of the game) is strong-reasoning planning work. Get the architecture right before any code is written. Complex debugging in Sandbox Studio (a replication issue that only appears on the server, a serialisation problem that only occurs on scene load, a class registration that silently fails) is where escalation earns its place. These problems require reasoning about how the engine works, not pattern matching against existing code. For a step-by-step risk check before you pick a tier, see [Model selection by task type](/working-with-ai-agents/model-selection-by-task-type.md). ## **Practical Guidance** * Default to the fast tier and let failure — not anxiety — push you upward. * Decide the tier before you write the prompt. That forces you to notice what kind of task this actually is. * Use the strong-reasoning tier for planning, unclear bugs, multi-file work, and anything that touches save data, networking, or build configuration. * Follow the escalation ladder: two genuine failures, then one tier up in a fresh chat, with a summary of what failed. * Before escalating, improve the prompt. A better brief to the current model often beats switching. * Go straight to the strongest tier when the cost of getting it wrong is a rebuild. * When handing off from planning to implementation, paste the plan into the implementation prompt so the fast-tier model has the full brief. * The moment the hard part is solved, drop back to the fast tier. ## **Common Mistakes** | Mistake | What to do instead | | -------------------------------------------------------- | ------------------------------------------------------------------------- | | Using the strongest model "to be safe" on routine edits | Fast tier first; escalate on failure | | Judging by task size instead of blast radius | Small diffs to save data or networking still get a strong-reasoning model | | Re-prompting the same model five times | Two failures = move up a tier with a fresh chat | | Staying on the strongest model after the breakthrough | Downshift for follow-ups | | Switching to a higher tier after a single failed attempt | Tighten the prompt first | | Not passing the plan to the implementation model | Treat the plan as a handover document and include it in the next prompt | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://studio-docs.sandbox.game/working-efficiently-with-ai/choosing-the-right-model-for-the-task.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.