@open-agent-toolkit/cli 0.2.18 → 0.2.20

package/assets/skills/subagent-orchestration/references/evidence-and-refresh.md

@@ -1,10 +1,10 @@
 # Evidence and Refresh Policy
 
 ```yaml
-guidance_version: 2026-07-21
-last_verified: 2026-07-21
-review_after: 2026-09-04
-stale_after: 2026-10-19
+guidance_version: 2026-07-25
+last_verified: 2026-07-25
+review_after: 2026-09-08
+stale_after: 2026-10-23
 ```
 
 This file governs dated provider examples. It does not override a live catalog,
@@ -17,8 +17,11 @@ authorization boundary.
 - `review-required`: older than 45 days, a newer family is observed, or a material control, price, tool, context, alias, or harness change is detected.
 - `stale`: older than 90 days, named models are unavailable or deprecated, or the launching surface can no longer express the recorded controls.
 
-Provider mappings in this package become review-required on 2026-09-04 and
-stale on 2026-10-19 unless re-verified earlier.
+Provider mappings in this package become review-required on 2026-09-08 and
+stale on 2026-10-23 unless re-verified earlier, or on the earlier date a
+reference states in its own header. `provider-cursor.md` carries an earlier
+2026-09-04 review date because its catalog was not re-verified in the
+2026-07-25 refresh.
 
 ## Immediate Review Triggers
 
@@ -61,24 +64,61 @@ When evidence is incomplete, retain the incumbent or route one class up.
 
 Do not use aggregate leaderboard rank as a universal model order.
 
+## Comparable-Rung Analysis
+
+For cross-provider analysis, show same-labelled effort rungs first when they
+exist, then show empirically interesting practical substitutions as a separate
+view. Label the model, effort, service tier, harness, benchmark version, and
+retrieval date for every row.
+
+Same-labelled rungs are comparable observations, not equivalent controls.
+CursorBench, provider-native coding-agent harnesses, and common-agent harnesses
+produce different Opus-to-Sol relationships. Preserve that disagreement; never
+publish a provider-independent effort conversion.
+
 ## Current Evidence Summary
 
 - OpenAI positions GPT-5.6 Sol as frontier, Terra as balanced, and Luna as
   high-volume. Official guidance starts at medium generally, but independent
   coding-agent data shows meaningful Luna/Terra quality cliffs below high for
   repository work. The dated mechanical Codex floor is therefore Luna high.
-- Anthropic positions Sonnet 5 as the speed/intelligence workhorse, Opus 4.8 as
-  a complex coding and enterprise model, and Fable 5 as the most capable widely
-  released model. Their effort defaults and recommendations differ by model.
+- Post-release Opus 5 evidence supports medium for normal substantive Claude
+  work and high for hard reasoning. Use xhigh for a reasoning-depth bottleneck
+  or evaluated long-horizon gain; max is selective and requires an effort
+  sweep. Consequence adds independent review rather than automatically raising
+  effort.
+- Sonnet 5 is a conditional route when measured latency, throughput, access,
+  rate limits, or end-to-end workload economics win. Fable 5 is an
+  eligibility-gated specialist; its missing-domain-concept or long-horizon
+  reviewer instantiation remains provisional, and zero-data-retention
+  requirements exclude the current route.
 - CursorBench supports Composer 2.5 as an economical bounded coding worker.
   Cursor explicitly documents Composer fast as the same intelligence at a
   higher latency tier price.
+- Mechanical reconnaissance remains harness-specific: Luna high in Codex,
+  Haiku 4.5 in Claude, and Composer 2.5 in Cursor. Direct API mini or nano
+  routes are limited to strict extraction, classification, or similarly
+  mechanically verified work.
 - OpenAI's long-context evidence disqualifies Luna for some very large-context
-  work even when Luna's nominal context window accepts the input.
-- Anthropic documents benign false positives from Fable's stronger cyber
-  classifier. This is operational evidence to consider when routing
-  cyber-sensitive work, not a capability weakness or a reason to invert the
-  general Opus-first policy.
+  work even when Luna's nominal context window accepts the input. Sol's current
+  direct-API requests above 272K input tokens carry a 2× input and 1.5× output
+  price step.
+- Sol's measured advantage is trajectory efficiency, not universal list-price
+  leadership. Opus output token pricing can be lower while Sol costs less per
+  completed task through fewer tokens, steps, turns, or recoveries.
+- Two independent benchmarks show top-end Opus effort is non-monotonic:
+  Artificial Analysis Coding Agent Index (xhigh 67, max 66) and Frontier-Bench
+  (xhigh 44.4%, max 43.3%), both retrieved 2026-07-25. Frontier-Bench is
+  vendor-operated and its figure rests on a single self-reported row with no
+  independently verified counterpart, so weight it below the Coding Agent Index
+  rather than treating the two as equal evidence. CursorBench 3.2 is monotonic
+  over the same range, 69.3% to 70.0%; its contribution is economic, since
+  marginal cost per score point is roughly 3.75x worse above high than below
+  it. Together these support treating max as a route requiring justification,
+  not a strictly better rung.
+- Cyber-sensitive and valid dual-use work should start on Opus 5 with
+  documented fallback handling where safeguards block the workflow. Opus 4.8
+  remains a compatibility fallback, not the universal primary.
 - Cursor disclosed that Cursor repository data entered Grok 4.5's training
   mixture. Its CursorBench ranking is evidence of competitiveness, not proof
   of superiority over nearby frontier models. Practical use supports Grok 4.5
@@ -86,8 +126,99 @@ Do not use aggregate leaderboard rank as a universal model order.
   implementation, and hard-reasoning economy routes, with cross-family review
   retained for consequential conclusions.
 
+## Speed and Wall-Clock Contract
+
+Speed evidence must satisfy the multi-measure contract defined in
+`model-selection-principles.md`, which is the single authority for which
+measures are required and which are recorded when available. Do not restate a
+divergent list here.
+
+Every load-bearing quantitative claim requires claim-level provenance:
+
+- a direct result locator, retrieval date, and stable source identity;
+- exact model selector, effort, reasoning mode, service tier, harness, and
+  benchmark version;
+- metric definition, aggregation basis, exclusions, and extraction method;
+- absolute input values before any derived ratio or delta;
+- the formula and units for each derived value;
+- cache, fallback, refusal, retry, and completion treatment;
+- unresolved source gaps stated explicitly rather than inferred away.
+
+The Coding Agent Index time measure is average active agent wall time per task.
+It excludes environment startup and verifier or judge time, and must not be
+relabeled as total user-observed elapsed time. AA-Briefcase time remains
+definition-unverified and must not be compared directly with it. Mutable
+leaderboards require row-level locators; a homepage or aggregate rank is not a
+sufficient source.
+
+This file records reconciled conclusions and the values that drive a rule, not
+the full ledger behind them. Every figure quoted here must name a publicly
+resolvable source: the benchmark, its version, and the retrieval date, so a
+reader outside the authoring environment can check it. Do not cite a private
+research artifact as a locator — an internal packet may hold the working
+arithmetic, but it cannot serve as provenance for published guidance.
+
+## Research Independence and Acceptance
+
+A policy refresh requires:
+
+1. a neutral research brief and isolated independent author lanes;
+2. a source ledger with claim-level provenance for each lane;
+3. reciprocal or independent review that did not author the claim under review;
+4. fact reconciliation before routing synthesis;
+5. a cross-model synthesis that preserves contradictions and uncertainty;
+6. explicit human acceptance of the update scope;
+7. canonical-first application;
+8. downstream parity verification by read-back.
+
+The author and reviewer may use the same evidence, but reviewer output must be
+independently produced. Agreement is not proof. Record disagreements and their
+resolution; do not collapse them into an unsupported consensus.
+
+## Live-Catalog and Downstream Gates
+
+Before adding or changing a selector, verify the live launching surface,
+resolved identity, effort or thinking control, service tier, and absence of
+silent fallback. Direct-provider evidence can nominate a harness candidate but
+cannot prove its alias.
+
+A selector ships only after a live probe verifies those controls for that
+specific mapping. Verification does not generalize: neither across rungs of one
+family nor across families, because a harness may substitute a default for any
+component it cannot resolve. Probe a non-default rung as well, or a result that
+merely matches the family default cannot distinguish an honored parameter from
+an ignored one.
+
+The six Cursor `claude-opus-5` and `claude-opus-4-8` mappings shipped on
+2026-07-25 met this gate; their resolved identities are listed in
+`provider-cursor.md`.
+
+After canonical changes:
+
+1. inventory exact mirrors, wrappers, generated views, and application-specific
+   consumers before synchronization;
+2. use each consumer's supported sync or bundle mechanism;
+3. read back every consumer, including each machine where user-scope copies
+   exist;
+4. require byte-for-byte equality for mirrors and documented semantic parity
+   for intentional wrappers;
+5. search live prompts, rules, code, and configuration for copied historical
+   selectors or effort defaults;
+6. record intentional exceptions and fail the gate while unexplained
+   divergence remains.
+
 ## Reverification Record
 
+One record describes one provider reference. When a single refresh cycle
+updates several provider references, emit one record per provider inside a
+`records:` list and lift the cycle-level fields — `verified_at`, `sources`,
+`claim_provenance`, `independent_author`, `independent_reviewer`,
+`incumbent_changes`, `reason`, `downstream_consumers`, `downstream_parity`, and
+`unresolved_items` — to the parent so they are stated once rather than
+duplicated per provider. Each record then carries only `provider`,
+`harness_context`, `catalog_source`, `models_considered`, `controls_verified`,
+and `eligibility_verified`.
+
 When updating a provider reference, record:
 
 ```yaml
@@ -97,7 +228,14 @@ harness_context: exact launching surface
 catalog_source: tool schema | CLI list | API catalog | UI snapshot
 models_considered: exact selectors
 controls_verified: effort, service tier, reasoning mode, context, tools
-sources: official docs and relevant benchmarks
+eligibility_verified: retention, access, pricing thresholds, safeguards
+sources: direct locators for official docs and relevant benchmark rows
+claim_provenance: selector, effort, harness, metric, locator, retrieval date
+independent_author: identity and model family
+independent_reviewer: identity and model family
 incumbent_changes: additions, replacements, removals, or none
 reason: scheduled review or trigger
+downstream_consumers: mirrors, wrappers, generated views, applications
+downstream_parity: hashes or documented semantic comparison
+unresolved_items: gaps, provisional routes, and deferred probes
 ```

package/assets/skills/subagent-orchestration/references/model-selection-principles.md

@@ -12,11 +12,24 @@ Never select from a model family name alone. Preserve these axes separately:
 - provider-native effort or reasoning selector;
 - service tier, including fast or priority variants;
 - reasoning mode when the provider exposes one independently of effort;
+- task class and the reasoning depth the work requires;
+- consequence and the independent-review requirement it creates;
+- reviewer role and the anticipated failure mode that reviewer should catch;
+- eligibility, including selector availability, retention policy, access,
+  context, safeguards, and harness-version constraints;
 - role, context inheritance, authority, deadline, and route.
 
 Do not normalize effort labels across providers. `medium`, `high`, `xhigh`,
 `max`, extended thinking, adaptive thinking, and provider-specific modes have
-different semantics. The exact pair or tuple is the route.
+different semantics. Compare same-labelled rungs only as an analysis view
+within a named harness, never as evidence that the labels are equivalent. The
+exact pair or tuple is the route.
+
+Task class, effort, consequence, reviewer role, and eligibility are related but
+independent decisions. Reasoning depth determines effort escalation.
+Consequence normally adds independent review, root-owned authorization, or
+stronger verification; it does not automatically force the highest effort.
+Eligibility filters the candidate set before capability or economy is compared.
 
 ## Five Task Classes
 
@@ -59,7 +72,27 @@ the task.
   adversarial behavior, or expensive failure dominates.
 
 Narrow a poorly decomposed task before escalating its model. Model capability
-never repairs an over-broad objective.
+never repairs an over-broad objective. A consequential classification does not
+by itself justify top effort; raise effort only when deeper reasoning is also a
+bottleneck.
+
+## Eligibility
+
+Eliminate ineligible routes before ranking capability, cost, or speed. Verify:
+
+- the exact selector and required effort or thinking control exist in the live
+  launching surface;
+- retention, data-handling, authorization, and safeguard behavior permit the
+  workload;
+- account access, rate limits, service-tier commitments, and harness version
+  permit the route;
+- the context window, long-context quality, and threshold pricing fit the
+  input;
+- tool support and fallback behavior are understood and do not silently change
+  the selected route.
+
+Provider evidence can nominate a candidate. It cannot prove that another
+harness exposes the same selector or control.
 
 ## Long Context
 
@@ -88,9 +121,41 @@ the final answer is short.
 
 A fast or priority tier is a latency control unless the provider explicitly
 documents a capability difference. It does not satisfy a higher task-class
-floor. Choose it only when wall-clock latency is worth the price and record it
+floor. Choose it only when measured latency is worth the price and record it
 separately from the model and effort.
 
+Speed is a multi-measure contract, not a single throughput number. This section
+defines that contract; other references cite it rather than restating their own
+version.
+
+Required in any speed claim:
+
+- time to first token;
+- active agent runtime;
+- total user-observed elapsed time;
+- output tokens;
+- steps, turns, or tool calls;
+- completion rate and variance.
+
+Time to first token is required, not substitutable. Where a harness cannot
+expose it, record it explicitly as not-reported rather than silently omitting
+it or supplying a different measure in its place; an absent measure and an
+unmeasurable one are different claims.
+
+Record additionally when available:
+
+- first useful action, which is a complement to time to first token and never
+  a replacement for it;
+- output rate;
+- input and cached-input tokens;
+- retries, recoveries, refusals, and operator interventions;
+- service tier, rate limits, and agent-slot occupancy;
+- cost per attempted and completed task.
+
+Do not relabel active runtime as total elapsed time, and do not infer latency
+from tokens or steps. Trajectory measures cannot substitute for measured
+latency. Compare list pricing separately from total trajectory cost.
+
 ## Independent Review
 
 For high-risk diffs and foundational decisions, prefer an author and reviewer
@@ -98,6 +163,13 @@ from different model families or providers. Agreement is not proof; disagreement
 is evidence that the root must resolve. The root verifies every load-bearing
 claim and retains final judgment.
 
+Choose the reviewer according to the failure mode the reviewer should catch:
+engineering execution, tool trajectory, missing domain concepts, factual
+knowledge, policy interpretation, or adversarial weakness. Named reviewer
+instantiations in provider guidance are dated and provisional unless a relevant
+evaluation qualifies them. Reviewer independence never transfers authorization
+away from the root.
+
 ## Staleness
 
 Read `evidence-and-refresh.md` when provider guidance is review-required or

package/assets/skills/subagent-orchestration/references/provider-claude.md

@@ -1,7 +1,7 @@
 ---
-guidance_version: 2026-07-22
-last_verified: 2026-07-22
-review_after: 2026-09-04
+guidance_version: 2026-07-25
+last_verified: 2026-07-25
+review_after: 2026-09-08
 ---
 
 # Claude Model Selection
@@ -15,12 +15,15 @@ the dated model examples below. Launch mechanics for OAT dispatch live in
 
 - `claude-haiku-4-5`: fastest economical class for straightforward,
   high-volume, mechanically verified work.
-- `claude-sonnet-5`: normal workhorse for coding, tool use, knowledge work, and
-  agentic execution.
-- `claude-opus-4-8`: strong complex coding and enterprise route and the
-  default for hard-reasoning and consequential work.
-- `claude-fable-5`: exceptional escalation route for the most difficult
-  long-running agents, coding, and frontier knowledge work.
+- `claude-opus-5`: normal substantive route and the default for
+  interpretation-heavy implementation, hard reasoning, and consequential work.
+- `claude-sonnet-5`: conditional route when measured latency, throughput,
+  access, rate limits, or established-workflow economics beat the relevant
+  Opus route.
+- `claude-fable-5`: eligibility-gated specialist for a directly relevant
+  failure mode, not a universal escalation above Opus.
+- `claude-opus-4-8`: compatibility or documented safeguard fallback, not the
+  current general primary.
 
 Claude Mythos 5 is invitation-only and intended for approved defensive cyber
 work. It is not a general routing candidate unless the organization explicitly
@@ -30,52 +33,109 @@ provisions and authorizes it.
 
 Never normalize Claude effort against OpenAI or Cursor labels.
 
-- Sonnet 5: high is the default workhorse; medium is the cost-saving step down;
-  xhigh is for the hardest coding and agentic work; max is exceptional.
-- Opus 4.8: start at xhigh for coding and agentic work; use high for other
-  intelligence-sensitive work; lower only after evaluation.
-- Fable 5: start at high; use xhigh for capability-sensitive work; max is
-  exceptional; medium/low are routine-work controls, not the default economy
-  substitute for Sonnet.
+- Opus 5: use medium for normal substantive work and high for hard reasoning,
+  architecture, ambiguity, and deep review. Use xhigh only when reasoning depth
+  is the bottleneck or an evaluated long-horizon workload benefits. Max is
+  exceptional and requires a workload-specific effort sweep or an explicit
+  quality-first exception.
+- Sonnet 5: use medium or high only when measured latency, throughput, access,
+  or workload economics justify the conditional route. Do not preserve xhigh
+  or max as generic workhorse settings.
+- Fable 5: use high or xhigh only for a qualified specialist case. Max is
+  exceptional; medium or low are not routine economy substitutes for Opus.
 - Haiku 4.5 does not expose the same adaptive-effort surface. Use only controls
   present in the live schema.
 
 Effort changes tool-call behavior as well as prose. Record it independently.
-For Opus 4.8 direct API calls, verify adaptive thinking is enabled as required
-by the current API contract. Fable adaptive thinking is always on in the
-current API.
+Opus 5 adaptive thinking is on by default; current direct-API behavior rejects
+disabling thinking at xhigh or max. Verify the live schema before launch.
+Changing effort or speed can invalidate prompt caches. Fable adaptive thinking
+is always on in the current API.
 
 ## Dated Task-Class Matrix
 
-| Task class               | Default        | Economy                                              | Escalation                                   | Floor notes                                                                               |
-| ------------------------ | -------------- | ---------------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------------------------- |
-| `mechanical-recon`       | Haiku 4.5      | Same, with strict output and mechanical verification | Sonnet 5 medium                              | Haiku is below floor for semantic audits and silent-miss-prone exploration.               |
-| `intelligent-recon`      | Sonnet 5 high  | Sonnet 5 medium                                      | Sonnet xhigh or Opus 4.8 xhigh               | Do not use Sonnet low for coding or open-ended recon.                                     |
-| `default-implementation` | Sonnet 5 high  | Sonnet 5 medium                                      | Sonnet xhigh or Opus 4.8 xhigh               | Fable low/medium is not the routine economy route.                                        |
-| `hard-reasoning`         | Opus 4.8 xhigh | Sonnet 5 xhigh                                       | Fable 5 xhigh for exceptional escalation     | Unresolved ambiguity or exceptional novelty must justify Fable's incremental cost.        |
-| `consequential`          | Opus 4.8 xhigh | No routine economy route                             | Fable 5 xhigh or max plus independent review | A consequential label alone does not justify Fable; retain root authorization and review. |
+These routes are dated guidance and benchmark-derived routing hypotheses.
+Evaluate them on representative local work before treating fine boundaries as
+stable.
+
+| Task class               | Default                             | Economy                                                | Escalation                                          | Floor notes                                                                                     |
+| ------------------------ | ----------------------------------- | ------------------------------------------------------ | --------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+| `mechanical-recon`       | Haiku 4.5                           | Same, with strict output and mechanical verification   | Opus 5 medium                                       | Haiku is below floor for semantic audits and silent-miss-prone exploration.                     |
+| `intelligent-recon`      | Opus 5 medium                       | Sonnet 5 medium/high only when its measured route wins | Opus 5 high                                         | Do not use Sonnet low for coding or open-ended recon.                                           |
+| `default-implementation` | Opus 5 medium                       | Sonnet 5 medium/high for evaluated bounded throughput  | Opus 5 high                                         | Fable is not a routine implementation or economy route.                                         |
+| `hard-reasoning`         | Opus 5 high                         | Opus 5 medium only after narrowing and evaluation      | Opus 5 xhigh for a reasoning-depth bottleneck       | Use max only after a workload-specific effort sweep.                                            |
+| `consequential`          | Opus 5 high plus independent review | No routine economy route                               | Opus 5 xhigh when deeper reasoning is also required | Consequence adds review and root authorization; it does not automatically require xhigh or max. |
 
 ## Root and Subagent Cost Posture
 
 Preserve strong, low-volume root orchestration. Root calls are
 coherence-critical and comparatively infrequent, while bounded subagents carry
 most execution volume. Capture routine savings in higher-volume subagents by
-routing mechanical work to Haiku and normal implementation to Sonnet instead
-of weakening the root orchestrator.
+routing mechanical work to Haiku and using Sonnet only where a measured
+high-volume route wins instead of weakening the root orchestrator.
 
 Opus remains the hard-reasoning and consequential root default. Escalate the
 root from Opus to Fable only when unresolved ambiguity, exceptional novelty or
-consequence, or a directly relevant Fable strength is expected to justify the
-incremental cost. A consequential classification by itself is insufficient.
+consequence, or a directly relevant Fable strength exposes a failure mode that
+Fable is expected to catch and eligibility permits it. This named Fable
+instantiation is provisional.
+
+A consequential classification by itself is insufficient.
+
+## Conditional and Specialist Routes
+
+Sonnet remains available when time to first token, active runtime, total elapsed
+time, throughput, access, rate limits, or end-to-end workload economics win for
+the actual harness. Compare against the relevant Opus effort and service tier,
+not an unrelated maximum-effort latency row. A lower token price alone does not
+prove lower trajectory cost.
+
+Choose specialist reviewers by anticipated failure mode. Fable is a
+provisional candidate for latent-knowledge, missing-domain-concept,
+sparse-context, long-horizon, or additional-perspective work. It is unavailable
+where zero data retention is required because the current route requires
+30-day retention. Provider availability, retention, and controls must be
+verified before selection.
+
+## Eligibility, Retention, and Service Constraints
+
+Eligibility filters the candidate set before capability or economy is compared.
+A route that fails one of these gates is unavailable regardless of benchmark
+standing. These are dated facts verified 2026-07-25; reverify against the live
+schema and the organization's actual plan before launch.
+
+| Constraint          | Opus 5                 | Sonnet 5      | Fable 5                    | Haiku 4.5     |
+| ------------------- | ---------------------- | ------------- | -------------------------- | ------------- |
+| Zero data retention | eligible               | eligible      | **unavailable**, needs 30d | eligible      |
+| Priority Tier       | not supported          | not supported | supported                  | verify live   |
+| Fast mode           | gated research preview | no            | no                         | no            |
+| Long context        | 1M at standard rates   | 1M standard   | 1M standard                | verify live   |
+| Claude Code minimum | version-gated          | version-gated | version-gated              | version-gated |
+
+- Zero data retention removes Fable from the route set outright. Check the
+  retention requirement before selecting a specialist reviewer.
+- Priority Tier commitments are closed to new buyers, so this matters only for
+  an existing commitment. Do not infer availability from another Claude family.
+- Fast mode is a gated latency purchase, not a capability rung.
+- Claude 4.6 and later families use their full 1M context windows at standard
+  rates. Do not carry a competitor's long-context surcharge model across to
+  Claude; the Codex Sol threshold step is a Sol fact, not a general one.
+- Claude Code enforces family-specific minimum versions. Verify the installed
+  runtime rather than assuming the catalog entry is launchable.
+
+Record service tier independently and apply the multi-measure speed contract
+from `model-selection-principles.md`.
 
 ## Cyber-Sensitive Evidence
 
-Fable 5 has a stronger cyber classifier that may flag benign coding and
-debugging work. For security review, vulnerability triage, auth boundaries,
-permissions, and other dual-use workflows where false-positive blocking would
-break the run, Opus 4.8 xhigh remains the operational default. Pair
-consequential findings with an independent provider review.
+For security review, vulnerability triage, auth boundaries, permissions, and
+other valid dual-use workflows, start with Opus 5 at the effort warranted by
+reasoning depth and pair consequential findings with an independent provider
+review.
 
+If a safeguard blocks a valid workflow, record the refusal, preserve the
+authorization boundary, and use a documented compatible fallback. Opus 4.8 is
+the current fallback target where necessary, not the universal cyber primary.
 Do not infer that a stronger safety classifier is a capability weakness. It is
 evidence about predictable workflow completion and refusal behavior, not an
 exception that inverts the general Opus-first policy.

package/assets/skills/subagent-orchestration/references/provider-codex.md

@@ -1,7 +1,7 @@
 ---
-guidance_version: 2026-07-22
-last_verified: 2026-07-22
-review_after: 2026-09-04
+guidance_version: 2026-07-25
+last_verified: 2026-07-25
+review_after: 2026-09-08
 ---
 
 # Codex and OpenAI Model Selection
@@ -33,24 +33,50 @@ name includes `codex`.
 
 ## Dated Task-Class Matrix
 
-| Task class               | Default                 | Economy                                                                                            | Escalation                                           | Floor notes                                                    |
-| ------------------------ | ----------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------------------------- |
-| `mechanical-recon`       | `gpt-5.6-luna`, `high`  | Direct API only: `gpt-5.4-mini` medium; `gpt-5.4-nano` medium for strict extraction/classification | `gpt-5.6-terra`, medium or high                      | Do not use Luna none/low for broad repository work.            |
-| `intelligent-recon`      | `gpt-5.6-terra`, `high` | Terra `medium` with tight scope and verification                                                   | Sol `medium`, then `high`                            | A silent miss disqualifies Terra none/low.                     |
-| `default-implementation` | `gpt-5.6-sol`, `medium` | Terra `high` for independently bounded, strongly tested work                                       | Sol `high`                                           | Luna is not the normal implementation lead.                    |
-| `hard-reasoning`         | `gpt-5.6-sol`, `high`   | Sol `medium` only after narrowing the problem                                                      | Sol `xhigh`                                          | Do not automatically escalate Terra to xhigh/max; move to Sol. |
-| `consequential`          | `gpt-5.6-sol`, `xhigh`  | No routine economy route                                                                           | Sol `max`, or a separately evaluated Sol `pro` route | Require independent review and root-owned authorization.       |
+| Task class               | Default                                        | Economy                                                                                            | Escalation                                                                                                       | Floor notes                                                                                     |
+| ------------------------ | ---------------------------------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+| `mechanical-recon`       | `gpt-5.6-luna`, `high`                         | Direct API only: `gpt-5.4-mini` medium; `gpt-5.4-nano` medium for strict extraction/classification | `gpt-5.6-terra`, medium or high                                                                                  | Do not use Luna none/low for broad repository work.                                             |
+| `intelligent-recon`      | `gpt-5.6-terra`, `high`                        | Terra `medium` with tight scope and verification                                                   | Sol `medium`, then `high`                                                                                        | A silent miss disqualifies Terra none/low.                                                      |
+| `default-implementation` | `gpt-5.6-sol`, `medium`                        | Terra `high` for independently bounded, strongly tested work                                       | Sol `high`                                                                                                       | Luna is not the normal implementation lead.                                                     |
+| `hard-reasoning`         | `gpt-5.6-sol`, `high`                          | Sol `medium` only after narrowing the problem                                                      | Sol `xhigh`                                                                                                      | Do not automatically escalate Terra to xhigh/max; move to Sol.                                  |
+| `consequential`          | `gpt-5.6-sol`, `high`, plus independent review | No routine economy route                                                                           | Sol `xhigh` when deeper reasoning is required; `max` or a separately evaluated `pro` route only after evaluation | Consequence adds review and root authorization; it does not automatically require xhigh or max. |
 
 `reasoning.mode: "pro"` is a separate quality/latency/cost control on GPT-5.6,
 not a model slug and not an effort label. Record it independently. Evaluate it
 against max or xhigh on representative consequential work before adopting it.
 
+The task-class ladder is work-shape based. Sol is the code-first,
+trajectory-efficient route for implementation and hard reasoning; this does
+not establish a provider-independent ranking against interpretation-heavy
+models in other harnesses. Consequential work requires independent review and
+root-owned authorization. It does not automatically force Sol xhigh or max:
+choose effort from reasoning depth, then add the consequence controls.
+
 ## Long-Context Floor
 
 For very large context, prefer Sol or Terra. Published GPT-5.6 results show a
 large Luna retention drop in the 256K-to-1M range. Large context does not change
 the task class, but it may disqualify Luna, mini, or nano.
 
+For Sol requests above 272K input tokens, the current direct-API price step is
+2× input and 1.5× output. Apply the threshold to the whole request and verify
+the live pricing contract before cost-sensitive dispatch. Crossing this
+threshold can change the economical route even when Sol remains the capability
+choice.
+
+## Trajectory Economics
+
+Token list price and total trajectory cost are separate. A model with a higher
+output-token price can still cost less per completed task when it uses fewer
+output tokens, steps, tool calls, retries, or recoveries. Conversely, a cheap
+attempt is not economical when completion rate is low or operator intervention
+is high.
+
+Evaluate input, cached-input, and output tokens together with the multi-measure
+speed contract from `model-selection-principles.md`. Do not use token price
+alone as a proxy for wall-clock efficiency, and do not infer latency from
+trajectory length without a measured runtime.
+
 ## Tool-Heavy Work
 
 Use Programmatic Tool Calling only for bounded processing such as filtering,