Horme chooses the model team
One objective can now become connected work across Claude Code and Codex, with Horme choosing the model for each task instead of making you route the work manually.
What changed
Horme now classifies the work inside an objective and routes each meaningful task to a model that fits its type and difficulty. Connected parts of one objective can run on different model families, for example architecture on one model, implementation on another, and an independent review on a third.
- Routine work stays on Tier 1 models: Claude Sonnet 5 or GPT-5.6 Terra.
- Hard, high-risk, or broad multi-file work uses Tier 2 models: Claude Opus 5 or GPT-5.6 Sol.
- The hardest architecture work has a dedicated route to Claude Fable 5.1, and the hardest terminal and DevOps work has a dedicated route to GPT-6 Astra.
- Tiny tasks stay as one Tier 1 step instead of being sent to a frontier model.
Why it matters
You no longer have to decide which model should own each piece of the job, open each agent yourself, and carry context between them. You give Horme the objective and it builds the model team.
What you can do now
- Give Horme one objective and let it keep simple work simple or split larger work into connected tasks.
- See the model assigned to each task.
- Pin an exact model when you want explicit control. A pin holds through delayed starts and retries. If the pinned model cannot run, Horme stops and says so rather than quietly substituting another.
Limits
- Provider availability and your own Claude Code and Codex plan limits still apply. When a provider is known to be unavailable, Horme uses only fallbacks its routing policy allows.
- If a Tier 1 attempt fails verification, Horme may escalate once to the matching Tier 2 model inside the existing retry budget. It does not keep escalating.
- Routing follows a fixed, versioned policy. It does not yet learn from past outcomes.