> 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-with-ai-agents/model-selection-by-task-type.md).
# Model selection by task type
Use this process when you need to choose which AI model to use for work in Sandbox Studio. The right model depends on the task, the risk of the change, and how much reasoning the work needs. Names of models in the picker live on [Choosing the right model for the task](/working-efficiently-with-ai/choosing-the-right-model-for-the-task.md). This page is how you decide the **tier**.
## Step 1: Name the task
Write one sentence that describes what you need the AI to do.
1. Name the immediate task, not the whole project.
2. State whether you need explanation, planning, writing, debugging, or implementation.
3. State what output you expect from the AI.
Example: Plan a small inventory feature for Sandbox Studio before any code changes are made.
{% hint style="info" %}
*TIP: If the task is unclear, clarify the goal before choosing a model. Model choice cannot fix an unclear request.*
{% endhint %}
## Step 2: Decide the risk level
Decide how costly a wrong answer would be before selecting the model.
1. Use low risk for short explanations, summaries, and small writing edits.
2. Use medium risk for focused feature work or small code changes.
3. Use high risk for multi-system changes, hard bugs, project structure, build configuration, save data, or networking. High blast radius means a stronger tier even when the diff is small.
## Step 3: Choose a fast model for small tasks
Use the fast tier when the task is narrow, low risk, and easy to check.
1. Use it for short explanations.
2. Use it for simple wording changes or small documentation edits.
3. Use it for quick summaries of known context.
{% hint style="info" %}
*TIP: Fast models are useful when speed matters more than deep reasoning.*
{% endhint %}
## Step 4: Choose a stronger model for planning
Use the strong-reasoning tier when the task needs judgment, tradeoffs, or multiple steps.
1. Use it for feature planning.
2. Use it for architecture decisions or changes that touch multiple systems.
3. Use it when you need options, risks, and a recommended approach.
{% hint style="info" %}
*TIP: Ask for options and tradeoffs before asking the model to build.*
{% endhint %}
## Step 5: Choose a stronger model for debugging
Use the strong-reasoning tier when the bug has several possible causes or has already resisted a quick fix.
1. Provide the exact error message.
2. Provide reproduction steps and recent changes.
3. Ask for likely causes before asking for edits.
The selected model matches a debugging task that needs deeper reasoning.
## Step 6: Use the strongest model for rebuild-level risk
Use the strongest tier when a mistake would mean tearing out a significant part of the project, or when the strong-reasoning tier has already failed twice.
1. Use it for architecture decisions and long, complex tasks that are expensive to rebuild if they are wrong.
2. For save data, networking, and build configuration that you can still correct without a rebuild, stay on the strong-reasoning tier unless those two attempts have already failed.
3. Ask for a plan before implementation. Review the plan before approving any changes.
{% hint style="danger" %}
*WARNING: A stronger model reduces risk, but it does not make the output automatically correct. Review the result before using it. Have in mind these models generally have a very high cost per prompt.*
{% endhint %}
## Step 7: Use the quick reference
Match the task type to a tier. For the current picker names in each tier, see [Choosing the right model for the task](/working-efficiently-with-ai/choosing-the-right-model-for-the-task.md).
| Task type | Recommended tier |
| ------------------------------------ | ---------------- |
| Quick explanation | Fast |
| Small writing edit | Fast |
| Feature plan | Strong reasoning |
| Multi-file implementation | Strong reasoning |
| Hard bug | Strong reasoning |
| Architecture or rebuild-level change | Strongest |
## Step 8: Switch models when the task changes
Change models when the work changes from one type to another.
1. Move up to a stronger model when the task becomes unclear, risky, or multi-step.
2. Move down to a faster model when the remaining work is routine.
3. Restate the current goal after switching so the new model has the right context.
## Step 9: Check the result
Review the output according to the risk of the task.
1. For writing, check accuracy and tone.
2. For code, check behavior and supported project checks.
3. For high-risk changes, review the plan, changed files, and test path before moving on.
{% hint style="info" %}
*TIP: The model choice is part of the workflow, not a guarantee. The final result still needs human judgment.*
{% endhint %}
## What You've Done
You have matched the model to the task instead of choosing by habit. Use faster models for narrow low-risk work, stronger models for planning and debugging, and the strongest available model for changes where mistakes are hard to undo.
---
# 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-with-ai-agents/model-selection-by-task-type.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.