Another one? What does this PR do?

Add a tier-based delegation config which overrides model/provider for easier/harder tasks. Critical design choices:

• Tiers are a small hardcoded set: "small" | "medium" | "large"
• Tiers can replace only model/reasoning OR whole provider block
• Tier not configured = falls back to normal delegation config, which falls back to base model (full backcompat)
• Defaults to medium tier (thus "small" = cheap, "large" = fancy)

Why tier-based? Virtually all open issues request for per-task model overrides.

• If we expose just model we don't support provider / local... unless we expose ALL of them to tool (schema pollution)
• Naturally supports reasoning effort as well (also without extra tool parameter)
• Small fixed tier set allows it to be included directly in tool schema, agent doesn't need to query a dynamic list
• Agent can't hallucinate models and extremely unlikely to typo common word
• Too many choices are counterproductive - few restricted choices = less doubting, more deterministic
• Agent can understand and use tier instinctively, don't need to include long explanations or skills to be useful
• Models evolve - if we include baseline guidance about what models to use it'll be outdated soon anyways
• User can change mapping without re-teaching the agent anything (and agent won't have contradictory memory)
• Agent can't put you on fanciest-fast-mode-token-burner model behind your back

I believe these 3 tiers should cover most reasonable use cases fairly well (I want one task to be cheaper/faster than my normal agent = "small", I want one task to use the fanciest model = "large"). User is free to make small/large as small/large as they want, or to leave some to be silently equivalent (e.g. only want smaller, not bigger). Adding more is trivial, removing is not, better to start small.

To minimize schema growth, I also explicitly kept tier top-level-only (all tasks in a batch use the same tier), as I believe the likelyhood of several tasks in a same batch requiring different tiers to be very low. This should be trivial to extend if truly desired.

Related Issue

Plenty of related issues/PRs: #34489, #18591, #17685, #32555, #31537, etc.

But no PR currently addresses a fixed tier set as proposed here.

Interesting ones:

• Feature Request: Dynamic model routing based on task complexity #30652 mentions more complex auto-routing (auxiliary-based complexity rating?), overbuild for simple use cases, likely to get stuck in design paralysis, no current implementation
• feat(delegate): model tiers + list_models tool (builds on #7586) #7957 includes dynamic tiers which require the agent to use a separate tool to fetch the list

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

How to Test

• Ask agent to call delegate_task with tier, and report what model was used.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Ubuntu 24.04

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

• This skill is broadly useful to most users (if bundled) — see Contributing Guide
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs

POC of model-only override and backcompat:

POC of provider override:

POC of agent being able to use tier intuitively (fresh new session, no extra skill, just tool schema):