Model selection guide
Choose for the job.
Not the parameter count.
A huge catalog is useful only if you can narrow it down. This guide explains what actually changes the result — model age, size, context, tools and price — then applies it to coding, where the cheapest acceptable model is often not the biggest one.
DemonBuild workflow
Planning is open. Design and code are curated.
DemonBuild’s planning stage can use any model. Its design and code stages use only the curated coding catalog — a focused set of 125 models chosen for implementation quality, agentic behavior, context, and cost.
Planning
Any modelUse the model that fits the conversation: inexpensive brainstorming, a huge-context generalist, or a specialist. Planning does not have to stay inside the coding set.
Design & code
Curated onlyVisual design and implementation draw only from the 125-model DemonBuild coding catalog. It is deliberately small enough to be useful and will grow as new candidates prove out.
DeepSeek V4.1 Flash Abliterated FP8
FeaturedThe highlighted design/code choice for visual passes and long implementation runs. 763B, 1M context, 128K max output, image input, and uncensored FP8 — $1.25 / $2.50 per million tokens.
On this page
1. Ask five questions before looking at names
What is the output?
A function, a SQL query, a chat response, an image description and a tool call are different tasks. A strong conversational model is not automatically a strong coding or tool-use model.
How hard is a typical request?
Renaming a variable and tracing a race condition should not have the same model budget. Separate routine work from the requests that truly need deeper reasoning.
How much must it see?
One function needs little context. A repository trace needs much more. Context is the total input plus output budget, not free extra space.
Does it need to act?
If your software expects JSON, function calls, screenshots or tool use, check those capabilities explicitly. Do not infer them from a high benchmark score.
What does a mistake cost?
A typo in a docstring is cheap. A plausible but wrong migration is not. Spend more on review and stronger models when failure is expensive.
What is your latency budget?
Interactive completion favors a small, fast model. Overnight batch jobs can trade speed for quality. Reasoning models also spend output tokens before the answer.
2. Read the model card, not just the name
In the catalog, the useful fields are the model's exact ID, context window, input and output price per million tokens, modality and feature tags. The name can hint at the base model and fine-tune, but it is not a quality score.
| Field | What it tells you | What it does not tell you |
|---|---|---|
| Exact model ID | What to send in the API's model field. | Whether two similarly named fine-tunes behave alike. |
| Context | Maximum combined prompt and response capacity. | That quality stays perfect when the window is nearly full. |
| Input / output price | Your cost per million tokens on each side. | Total task cost — retries and long outputs matter. |
| Modality | Text-only or image-capable input. | Whether image reasoning is good at your particular screenshots. |
| Tool-use tag | The route is intended for function/tool-calling workloads. | That every client framework or schema will work identically. |
The only benchmark that matters is your workload. Keep 10–30 real requests with known-good answers. A model that passes those is more useful than one with an impressive name and no evidence on your task.
3. Choosing a coding model
Coding performance has at least four separate axes: writing code, understanding existing code, following repository constraints, and operating tools. A model can be excellent at a standalone Python function and poor at a ten-step agentic refactor.
Start with the shape of the work
| Work | What matters most | Sensible starting class |
|---|---|---|
| Autocomplete, snippets, boilerplate | Low latency and low cost | Small 0.5B–4B code model |
| Single-function generation, unit tests | Instruction following and language coverage | Small/mid code model, roughly 7B–14B or efficient MoE |
| Debugging across a few files | Context use and reasoning over evidence | Mid-size or newer code-focused model |
| Framework migration, multi-file refactor | Recent knowledge, context, planning | Newer large-context code model |
| Agent that edits, runs tests and retries | Tool calling, recovery, long-horizon consistency | Code/agent flagship, not merely a chat flagship |
| Security or concurrency bug | Reasoning quality and independent verification | Strong model plus tests; consider a second-model review |
General models still have a place. Explaining code, writing documentation, designing an API or discussing architecture does not always require a code specialist. For direct code generation and repository edits, a code-focused checkpoint is the better first candidate.
4. Old vs new: recency matters, but it is not everything
When newer usually wins
- Modern frameworks and changing APIs. A newer training cutoff is more likely to know current library conventions and less likely to invent an API that was removed two releases ago.
- Agentic coding. Recent models are more often trained on tool calls, iterative repair and long sequences of related edits — not just isolated code completion.
- Instruction discipline. Newer checkpoints commonly do better at “change only this file,” “return a diff,” and “do not add dependencies.”
- Efficiency. New architectures and MoE designs can deliver better quality per dollar than older, larger dense models.
When an older model is still a rational choice
- Stable languages and timeless tasks. SQL, regex, shell snippets, algorithms and mature standard libraries change slowly.
- A proven prompt. If an older model already passes your regression set, replacing it creates a new testing burden for no immediate benefit.
- Specialist fine-tunes. A newer general model may know more, while an older domain specialist follows your exact output format better.
Do not confuse base-model age with fine-tune age. A community fine-tune can be uploaded recently while its base model is much older. Recency of the upload is not recency of the underlying knowledge.
Our own catalog illustrates why price is not an age or quality ranking: at the time of writing, Qwen3-Coder-Next has a 262K context and lower listed input/output prices than several older Qwen2.5-Coder variants. Newer can be cheaper. Test it rather than assuming the older, dearer option must be better.
5. Parameters: a capacity hint, not a ranking
7B means roughly seven billion learned weights. More parameters can store more knowledge and represent subtler patterns, but training data, post-training, architecture and quantization can easily beat a raw size advantage.
0.5B–4B
Fast transformations, simple completion, constrained formats. Expect more mistakes on ambiguous instructions and unfamiliar bugs.
7B–14B
A practical everyday tier for functions, tests and explanations. Often the best first experiment for single-file work.
20B–40B
More headroom for debugging, unfamiliar code and multi-step instructions. A common sweet spot for serious interactive coding.
70B+
Worth testing for architecture, difficult refactors and subtle bugs. Do not assume every request deserves this tier.
Dense vs MoE: what “480B-A35B” means
A dense model activates all of its weights for each token. A Mixture-of-Experts (MoE) model activates only some experts: in a name like 480B-A35B, 480B is total parameters and about 35B are active per token. Total size relates to capacity; active size is a closer hint to serving cost and speed. Neither number alone predicts code quality.
Quantization and suffixes
Names such as BF16/FP16, Q8 and Q4 describe weight precision or packaging. Lower precision can reduce serving cost but may change outputs, especially on difficult reasoning. Treat different quantizations as different candidates when quality is critical. Also check whether a checkpoint is a base model or an instruct/chat fine-tune: for normal API prompts, you usually want the instruct variant.
6. Cost vs quality: match spend to complexity
Prices are per million tokens, with separate input and output rates. A rough request cost is:
cost = input_tokens / 1,000,000 × input_price
+ output_tokens / 1,000,000 × output_price
For example, a request using 10,000 input tokens and 2,000 output tokens costs $0.0086 at $0.50/$1.80, versus $0.0276 at $1.52/$6.20. That is about 3.2× per request. Whether the premium is justified depends on how often the stronger model prevents a retry or a bad edit.
The high end makes the trade-off starker: the same 10,000-input / 2,000-output request on a $48/$80 model costs $0.64 — roughly 74× the $0.0086 budget example. That can still be the economical choice for a difficult repository repair if it succeeds in one attempt, but it is hard to justify for boilerplate.
Think in successful tasks, not tokens
| Complexity | Examples | Selection strategy |
|---|---|---|
| Low and repeatable | Format conversion, boilerplate, simple tests, docstrings | Use the cheapest model that passes your tests. Savings compound at volume. |
| Medium | New functions, ordinary bug fixes, a small feature | Start in the mid tier. Escalate only when it fails the same test twice. |
| High | Multi-file changes, unfamiliar frameworks, data migrations | Pay for context and stronger reasoning. Require tests or a diff review. |
| Critical | Security, money movement, irreversible production changes | Use a strong model and independent verification. Model savings are not the priority. |
A cheaper model can cost more per solved problem if it needs five attempts, produces 10,000 tokens of irrelevant reasoning, or breaks code you must debug. Conversely, a flagship used for every docstring is wasted spend. Measure cost per accepted answer.
7. Context windows: buy enough, not the biggest number
The context window covers input plus output: system prompt, conversation history, source files, tool results and the response all share it. A model with a 32K window cannot accept 32K of source and also return a long patch.
- Single function or small file: 32K is usually ample.
- Several files and logs: leave room for tool output and the response; trim irrelevant code.
- Repository-scale context: consider a large-window model such as Qwen3-Coder-Next (262K in our catalog), or better, retrieve only relevant files.
Keep roughly 20–30% headroom rather than packing the window to its limit. More context can help, but irrelevant context costs money and can distract the model. Output limits are a separate constraint from the context window; a huge input window does not guarantee an equally huge single response.
8. Coding agents need more than coding ability
An agent loop asks the model to choose tools, interpret errors, revise its plan and stop when done. For that workload, prioritize:
- Reliable tool/function calling with your actual client and schemas.
- Long-horizon consistency — does it remember constraints after ten tool results?
- Recovery behavior — does a failing test lead to a focused fix or a full rewrite?
- Enough output budget for patches and structured calls.
Use low temperature for deterministic edits, validate tool arguments in your code, and make tests — not the model's confidence — the acceptance gate. A model that writes beautiful code but calls tools inconsistently is the wrong agent model.
9. DemonBuild coding starting points
These recommendations all belong to the 125-model DemonBuild design/code set. Prices below are per million tokens and can change; the linked model page is authoritative. Start with the featured DeepSeek, then compare against the lane that matches your context and quality needs.
| Candidate | Context | Input / output | Why try it |
|---|---|---|---|
| DeepSeek V4.1 Flash Abliterated FP8 | 1M | $1.25 / $2.50 | Featured for DemonBuild. Uncensored FP8, image input, and 128K output for visual design passes and long implementation runs. |
| GLM 5.3 | 1M | $0.75 / $3.50 | Low input price for very large design and code contexts, with 128K output headroom. |
| Qwen3-Coder-Next | 262K | $0.64 / $4.60 | Budget-friendly coding candidate for large file sets and long tool traces. |
| Qwen3.8-27B-OBLITERATED | 32K | $6.40 / $48.00 | Recent uncensored 27B option for direct code generation and agentic tasks. |
| Qwen3.6-35B-A3B-Uncensored-Genesis-Final | 32K | $1.60 / $16.00 | Efficient uncensored MoE candidate when you want a smaller serving footprint. |
| Qwen3-Coder-480B-A35B-Instruct | 32K | $1.52 / $6.20 | Flagship-scale code and agentic model for difficult implementation work. |
| GAIR/OpenSWE-72B | 32K | $48.00 / $80.00 | Premium software-engineering specialist for hard repository tasks, not routine snippets. |
| Qwen3.8-2.4T-A95B | 262K | $4.00 / $16.00 | Very large model for architecture, complex multi-file reasoning, and difficult refactors. |
For the complete whitelist, use the DemonBuild mini catalog. Planning remains open to any model; design and code stay inside that set.
10. A cheap, reliable selection workflow
Build a tiny regression set. Save 10–30 real prompts: easy, typical and hard. Include the expected tests, schema or review criteria.
Test three different classes. Try a cheap code model, a mid/newer model and one stronger candidate. Keep the prompt, temperature and context identical.
Measure accepted output. Record pass rate, latency, tokens and retries. Calculate cost per accepted answer, not just cost per call.
Route routine work to the cheapest winner. Keep the stronger model for failures and high-complexity requests. You can implement escalation with a second API call using a different model ID.
Pin, monitor and retest. Use the exact model ID in production. When you change models, rerun the same set. Do not silently swap a working configuration because a new name appears.
A practical default: small model for boilerplate → mid/newer code model for ordinary features → flagship for difficult debugging and agentic recovery → tests and human review for critical changes.
11. The same logic outside coding
Chat and roleplay
Prioritize instruction following, writing style and enough context for the conversation. A coding leaderboard tells you little about prose or character consistency.
Long documents
Context size matters, but retrieval matters too. Send the relevant sections rather than paying to repeatedly process an entire library.
Images
Choose a vision-capable model and test your real screenshots or documents. Text-only models cannot be prompted into seeing an image.
Structured extraction
Small instruct models often perform well with a tight schema and examples. Validate the JSON; escalate only the records that fail.
Reasoning
Reasoning variants can help on hard problems, but their hidden or visible thinking increases output tokens and latency. Avoid paying that cost for simple lookups.
Specialists
SQL, translation and domain fine-tunes can outperform generalists in a narrow lane. Keep a general fallback for out-of-scope requests.
12. Common questions
Is the biggest model always best?
No. Training quality, recency, specialization and your prompt can matter more than parameter count. Big models also do not guarantee correct tool use.
Should I always use the newest model?
No. Prefer newer for changing frameworks and agentic work, but keep an older model when it already passes your regression tests reliably and economically.
Why is output often priced higher than input?
Generating tokens is sequential work, while reading a prompt is processed differently. Long answers can therefore dominate a request's cost even when the prompt is large.
Should I use a reasoning model for all coding?
Usually not. Reasoning helps on difficult debugging and design, but simple edits rarely justify the extra output and latency. Route by complexity.
What temperature should code use?
Start low — around 0 to 0.2 for exact edits and structured output. Raise it only when you deliberately want varied solutions, then validate the result.
How do I try two models without rebuilding my app?
Change only the model value in the same OpenAI-compatible request. The API docs show the request shape, and the playground is the quickest manual comparison.
Your turn
Take one real task. Try three models.
You will learn more in ten minutes than from an hour of model names. Start cheap, keep the winner, and escalate only when the work demands it.