Get one model stable first
The usual mistake is not "the model is too weak"—it is adding fallback, routing, and multiple providers before the first model runs reliably.
When a single model is enough
- You are still validating your first channel loop
- You have few skills
- Task types are similar
- You care more about debugging than model limits
A single model gives:
- Clearer failure points
- Easier cost estimation
- A simpler view of context and tool usage
When to add fallback
Add fallback (not full routing) when:
- The primary model occasionally fails
- You want a weaker but usable backup for critical flows
- You need a safety net without task-specific routing
Fallback makes the system more resilient, not smarter.
When routing is worth it
Task-based routing fits when:
- You have distinct task layers
- You know which tasks need stronger models
- You know which tasks can use cheaper models
- You accept extra config and debugging complexity
If you cannot clearly say "which task goes to which model," routing is probably too early.
A sensible upgrade order
- Single model
- Two-model split (simple vs complex tasks)
- Fallback chain
- Task-specific routing
Doing this in reverse usually creates complexity before understanding.
Avoid early complexity
- Do not configure 4–5 fallback layers at once
- Do not set up routing for every task type from day one
Start with one model, validate it, then add fallback or routing incrementally.
Next steps
- Cost control
- Coding Plan providers
- Official docs → docs.openclaw.ai
- Issues → GitHub Issues