Dynamic Model Routing
Dynamic routing lets users keep a provider fixed while allowing Coco to choose a task-appropriate model.
It is enabled by setting service.model to dynamic.
json
1{
2 "service": {
3 "provider": "openai",
4 "model": "dynamic",
5 "dynamicModelPreference": "balanced",
6 "dynamicModels": {
7 "summarize": "gpt-4.1-nano",
8 "commit": "gpt-4.1-mini",
9 "commitSplit": "gpt-4.1",
10 "changelog": "gpt-4.1",
11 "review": "gpt-4.1",
12 "largeDiff": "gpt-4.1"
13 }
14 }
15}Tasks
Supported task keys are:
summarize: routine diff compression.commit: final commit message generation.commitSplit: structured plan generation forcoco commit split. Floored abovecommit(even incostpreference) because the split planner emits JSON with strict cross-group constraints (every staged file claimed exactly once, no duplicate file/hunk assignments, hunk-vs-file mode exclusivity) that weaker models routinely violate.changelog: final changelog copy generation.review: code review analysis.recap: recap generation.repair: parsing repair and retry work.largeDiff: large branch or changelog diff condensation.
Routing Inputs
The current resolver uses:
- Provider:
openai,anthropic, orollama. - Task: one of the task keys above.
- Preference:
cost,balanced, orquality. - User overrides:
service.dynamicModels.
Explicit models are preserved. If service.model is not dynamic, Coco uses that model for every task.
Defaults
Defaults are provider-specific and intentionally conservative:
- Summarization uses smaller/faster models where available.
- Commit/changelog generation uses balanced models.
- Review, repair, and large-diff tasks use stronger or larger-context models.
User overrides replace individual tasks without requiring a full profile.
Backward Compatibility
Existing configs continue to work unchanged. The new fields are optional. dynamicModels
is ignored unless service.model is dynamic, but it is still validated when dynamic
routing is resolved so invalid task names fail clearly.