Choose an AI Coding Model for OpenCode

Choosing an AI coding model for OpenCode means balancing code quality, context-tool reliability, speed, and total cost for your actual tasks. Before switching models, check that OpenCode can connect to the provider and that the model supports the tools and context length your workflow needs.

What You’ll Need

• OpenCode installed and configured, plus access to at least one model provider.
• Any required provider credentials, such as an API key or an account with model access. Keep credentials private; do not paste them into prompts or commit them to a repository.
• A small, representative coding task and a way to inspect the model’s tool calls, edits, and usage or billing information.
• The current model documentation or provider listing for tool support, context limits, and pricing. These details can change.

Step-by-Step

1. Define the job before comparing models. Write down what you need OpenCode to do: answer questions about a repository, edit one file, debug a failing test, or plan and carry out a multi-file change. Note whether the work requires reading many files, running shell commands, searching, or repeatedly revising code. A model that is adequate for short edits may struggle with long, tool-heavy sessions.
2. Confirm how your OpenCode setup handles tools. OpenCode can expose context and other tools to a model, but availability depends on the configured model, provider, and current integration. Check the model’s listing and provider documentation for tool or function-calling support. Do not infer support from a model name or general coding benchmark. If your setup offers a model picker or model configuration, select the exact model and provider you intend to test.
3. Check the context limit against your real workload. Context is the information the model can consider in a request, including instructions, conversation history, code, and tool results. A larger stated context limit can help with broad repository work, but it does not guarantee better answers or mean every file is automatically included. OpenCode’s context tools may retrieve relevant material selectively; check what they actually send. Leave room for the model’s response and tool results, and avoid choosing solely by the largest advertised limit.
4. Compare the full cost, not just the input price. Providers may charge separately for input and output tokens, and may price cached or other token categories differently. Tool-heavy work can make repeated requests and large tool results add up. Read the provider’s current pricing for the exact model, and check whether your account uses pay-as-you-go billing, a subscription allowance, or another arrangement. Do not assume that a subscription covers API usage, or that the cheapest input rate means the cheapest completed task.
5. Make a short evaluation set. Choose three to five tasks that represent your work, such as locating a function, explaining a dependency, making a contained change, and diagnosing a test failure. Use the same repository state, task wording, and tool permissions for each model. Include a task that requires the context tool if that is central to your workflow. Keep the prompts specific, but do not give one model extra hints.
6. Run each task and observe the process. Record whether the model finds the right files, uses tools appropriately, asks before risky actions when needed, and produces a change that fits the project. Check whether it gets stuck repeating searches or commands, omits relevant context, or makes unsupported assumptions. Inspect tool output and edited files rather than judging only the final explanation. Do not grant broader permissions just to make a model appear more capable.
7. Verify the code independently. Review the diff, run relevant tests and project checks, and confirm that the result meets the task. A fluent answer is not proof that the code works. Note how much correction or follow-up was needed; a model with a higher per-token rate may still be more economical if it completes work with fewer retries, while a cheaper model can cost more when it repeatedly misses context.
8. Compare value per successful task. For each model, record completion quality, number of follow-ups, elapsed time, and available usage or cost data. Compare models on the same tasks, not on different coding sessions. If exact spend is unavailable, label your comparison as an estimate rather than a measured cost. Choose the least costly model that meets your quality and tool-use requirements consistently, not simply the lowest advertised rate.
9. Set a practical default and revisit it. Use the selected model for routine work, and keep a stronger or larger-context option available for difficult tasks if your setup supports switching. Set provider spending limits or alerts where available, and check usage after the first few sessions. Re-evaluate when model capabilities, prices, provider support, or your repository workflow changes.

Common Mistakes

• Picking by benchmark or reputation alone: Published coding scores do not establish how a model behaves with your repository, OpenCode configuration, or context tools.
• Assuming the context tool works automatically: A model may be selectable but lack the required tool support, or the tool may not be enabled in the current configuration. Confirm with a real task and visible tool activity.
• Comparing unlike tasks: Different prompts, repository states, permissions, or test coverage make results hard to interpret. Keep the evaluation conditions consistent.
• Looking only at token rates: Retries, long outputs, and large tool results affect total usage. Compare completed, verified work.
• Trusting a successful tool call as proof: A search or command can run successfully and still return irrelevant information. Review what the model used and whether the final change is correct.
• Ignoring context quality: Sending more files can increase cost and noise. Relevant, current context is often more useful than an indiscriminate repository dump.

Tips

• Start with a read-only repository question, then try a small, reviewable edit before allowing broader changes.
• Use the same test command and acceptance criteria across model trials. Record the model identifier and provider, since similarly named offerings can differ.
• Ask for a concise plan on multi-step work, and review it before consequential commands or edits.
• Use OpenCode’s context tools to retrieve targeted files or relevant excerpts where available; keep generated files, unrelated directories, and secrets out of the prompt.
• Check provider usage dashboards or logs soon after testing. Usage displays may be delayed or categorized differently, so compare them with the provider’s billing documentation.
• Keep a fallback model for outages or tasks that exceed the default model’s context or tool capabilities.

Troubleshooting

The model does not call a context tool. Verify that the tool is enabled and available to the selected model in your OpenCode configuration. Check provider documentation for tool support, then try a simple prompt that clearly requires retrieving a repository file. If no call appears, switch to a confirmed compatible model or use the documented configuration path; do not assume a prompt can add unsupported capabilities.

The model misses relevant code. Ask it to identify the files or evidence it used, then inspect the retrieved context. Narrow the request to a specific symbol, directory, or error, and check that the repository index or search results are current if your setup relies on indexing. Include a short, relevant excerpt when appropriate, without exposing secrets.

Responses stop early or become inconsistent. The request may exceed the usable context once history and tool output are included. Start a fresh session with a concise summary, provide only necessary files, or choose a model with a suitable context limit. Verify that the summary preserves key constraints before continuing.

Usage is higher than expected. Review provider usage details for input, output, cached usage, and repeated calls where reported. Reduce unnecessary history and broad retrieval, ask for focused outputs, and set a spending limit or alert if available. If pricing or usage remains unclear, consult the provider’s current billing documentation before continuing.

The change fails tests or edits the wrong files. Revert or correct the change using your normal version-control workflow, then give the model the exact failure and relevant code. Ask for a focused diagnosis rather than an unrestricted rewrite, and run the checks again. Never merge or deploy code solely because the model says it is fixed.

Frequently Asked Questions

Does every model available in OpenCode support context tools?
No. Support depends on the model, provider, and configuration. Confirm it in current documentation and test an actual tool-dependent task.

Is a larger context window always better?
No. It can help with large tasks, but it does not ensure relevant files are retrieved or improve reasoning by itself. It can also increase usage when more context is sent.

Which model is cheapest for OpenCode?
There is no permanent answer: model rates, billing categories, and account terms vary. Check current provider pricing and compare the cost of completing and verifying your own tasks.

Can I use one model for every coding task?
You can, if it reliably meets your needs. Many workflows benefit from a cost-effective default and a more capable fallback for complex reasoning or large-context work.

How do I know whether a model’s code is good?
Review the diff, run relevant tests and project checks, and verify the behavior against the task requirements. Tool use and confident explanations are not substitutes for validation.

Should I send the whole repository to get better answers?
Usually not. Use targeted retrieval and provide the files needed for the task. Avoid sending secrets, credentials, or unrelated private data.

Related

• Lovable Pages to Editable WordPress Content
• Verify AI-Generated Code Before You Ship It
• EU Data Protection Rules for AI Services: A Practical Guide