Problem
Diffuin's current model-routing strategy generally does the opposite of the ideal intelligence allocation: cheaper models are used for planning/review while more capable models are reserved for implementation.
Planning and review are often the highest-leverage stages of an SWE agent workflow. A bad plan can cause a large implementation to go in the wrong direction, while a weak review can miss architectural mistakes, regressions, or edge cases. Routine implementation, on the other hand, can consume many tokens while being relatively mechanical.
Proposed routing strategy
Prefer the highest-intelligence model for:
- Repository/issue investigation
- Architecture and implementation planning
- Identifying affected systems/files
- Reasoning about edge cases and regressions
- Difficult debugging or ambiguous implementation work
- Final diff/PR review
Prefer cheaper models for:
- Routine implementation from a detailed plan
- Mechanical edits across files/call sites
- Boilerplate
- Running builds/tests and fixing straightforward failures
- Applying specific changes requested by review
A typical workflow could be:
- Smart model — investigate + plan
- Understand the issue and existing code.
- Determine the correct approach and affected areas.
- Produce a detailed implementation plan and acceptance criteria.
- Cheaper model — implement
- Follow the plan closely.
- Make the edits and run relevant builds/tests.
- Escalate when the plan conflicts with the actual code or difficult reasoning is required.
- Smart model — review
- Review the resulting diff against the issue and plan.
- Check correctness, architecture, regressions, and missed edge cases.
- Cheaper model — apply review fixes
- Make concrete requested corrections and re-run verification.
Rationale
This should provide better intelligence-per-token/cost. Planning has disproportionate leverage: spending more intelligence up front can prevent a much larger implementation from following a flawed approach. Similarly, final review benefits from stronger reasoning because its purpose is specifically to catch mistakes the implementation pass missed.
The expensive model should still be available during implementation when the task involves difficult debugging, reverse engineering, concurrency, subtle runtime behavior, unfamiliar interop, or when the cheaper model becomes stuck.
Possible implementation
Model selection could become stage-aware rather than simply assigning the strongest model to implementation. For example:
planning: high intelligenceimplementation: economical/default intelligencereview: high intelligencefixes: economical/default intelligence- escalation from implementation/fixes to high intelligence when necessary
Ideally this remains configurable so users can choose between quality-first, balanced, and cost-first routing strategies.
Problem
Diffuin's current model-routing strategy generally does the opposite of the ideal intelligence allocation: cheaper models are used for planning/review while more capable models are reserved for implementation.
Planning and review are often the highest-leverage stages of an SWE agent workflow. A bad plan can cause a large implementation to go in the wrong direction, while a weak review can miss architectural mistakes, regressions, or edge cases. Routine implementation, on the other hand, can consume many tokens while being relatively mechanical.
Proposed routing strategy
Prefer the highest-intelligence model for:
Prefer cheaper models for:
A typical workflow could be:
Rationale
This should provide better intelligence-per-token/cost. Planning has disproportionate leverage: spending more intelligence up front can prevent a much larger implementation from following a flawed approach. Similarly, final review benefits from stronger reasoning because its purpose is specifically to catch mistakes the implementation pass missed.
The expensive model should still be available during implementation when the task involves difficult debugging, reverse engineering, concurrency, subtle runtime behavior, unfamiliar interop, or when the cheaper model becomes stuck.
Possible implementation
Model selection could become stage-aware rather than simply assigning the strongest model to implementation. For example:
planning: high intelligenceimplementation: economical/default intelligencereview: high intelligencefixes: economical/default intelligenceIdeally this remains configurable so users can choose between quality-first, balanced, and cost-first routing strategies.