delegation-tieringlisted

# Delegation and model tiering The operative defaults live in `~/.claude/rules/delegation.md`. This is the reasoning, the evidence, and the cases that file is too short to carry. Research date **2026-09-16**. Where a number is vendor-run or unreplicated it says so. Treat every tier boundary below as extrapolation unless it names a Claude-tier measurement. ## Runtime mapping A shared role names one of four capability classes, strongest first — `frontier`, `strong`, `standard`, `light` — in its contract's `tier:` line, and each adapter's `bindings.json` maps the classes it has qualified to native models in a `tiers` table. The class is a statement about the work; the table is the only place a provider's model names appear. An unmapped class resolves to the nearest *stronger* mapped class and otherwise inherits the session model — never downward, because a weaker model than the role asked for is a silent failure. Both adapters map all four. Claude Code's table uses version-free aliases. Codex has none — every id carries a version and keeps resolving after its successor ships — so `harness tiers check` reads the catalog Codex fetches from its provider and flags a mapped model that is gone, superseded or out of order. `tiers.<runtime>.<class>` in your config remaps a class in one line; on a provider that lacks these ids, override a role's `model` to `inherit` in `role_bindings`. Provider model names and benchmark examples below describe their original evaluation context; they