consult: configurable per-lane models and per-review-type lane selection

[waleedkadous]

Problem (owner-directed request from a production workspace, 2026-07-29)

Consult hardcodes the model per lane (commands/consult/index.ts — claude lane pinned to claude-opus-4-6, codex lane to gpt-5.4 with medium reasoning). Workspaces cannot run newer models (e.g. claude-opus-5 for spec/plan reviews, gpt-5.6 for the codex lane) without patching dist or shadow-forking protocol files.

Ask 1 — per-lane model config

Read per-lane model ids from .codev/config.json, e.g.:

{ "consult": { "models": { "claude": "claude-opus-5", "codex": "gpt-5.6" } } }

Fail fast on an unknown/invalid id (no silent fallback to the hardcoded default — per the fail-fast convention).

Ask 2 — per-review-type lane selection

Config-level porch.consultation.modelsByType (e.g. {spec:[...], plan:[...], impl:[...], pr:[...]}) so lane composition can differ by review type. The requesting workspace implemented this today by tier-2-shadowing spir/aspir/pir protocol.json copies — which works but recreates exactly the stale-shadow-copy rot class that bit this repo (17 drifted files, fixed in PR #1281). A sanctioned config mechanism removes the incentive to fork protocol files.

Evidence offer

The requesting workspace has lane-value data from production use (codex load-bearing at every review type; claude unique-finder at spec/plan; gemini ~zero unique findings and the only flaky lane) and is happy to share as input for defaults. Matches this repo's own experience (Codex caught the decisive defect in six consecutive review rounds on recent projects; the agy/gemini lane is #1032/#1033-degraded).

Note

Config > protocol precedence is already porch's documented model-list rule; this extends the same principle to consult lane models. PIR's CMAP-2 cost invariant (config can silently inflate lighter protocols) should be considered in the design — per-protocol scoping may need to ride along.

[waleedkadous]

Addendum (owner request): bump the hardcoded defaults to current models

In addition to making lane models configurable, the fix should update the built-in defaults to the current model generation so an unconfigured workspace gets modern lanes out of the box.

Verified against the current Anthropic model catalog (checked 2026-07-28, not from memory):

• Claude lane default: claude-opus-4-6 → claude-opus-4-8 (current Opus-tier; 1M context). Note for the requesting workspace: claude-opus-5 does not exist — the Claude 5 family is claude-fable-5 (premium tier, ~2× Opus pricing) and claude-sonnet-5; the current Opus line is 4.x with claude-opus-4-8 newest. Config validation should fail fast on claude-opus-5 and similar guesses — which is exactly the fail-fast behavior Ask The Gestalt Problem - Features Developed in Isolation Without System Awareness #1 specifies. (If a workspace wants to pay for Fable-class review, claude-fable-5 as an explicit config value is the supported path; it should not be the default given cost.)
• Codex lane default: gpt-5.4 → gpt-5.6 per the requesting workspace's report that it's current. The builder must verify that model id against the OpenAI/codex CLI's own catalog before baking it in (same never-guess-model-ids rule) and keep medium reasoning unless evidence says otherwise.
• Migration note for the builder: on current Anthropic models, thinking/effort parameters differ from older generations — if the consult client sets model parameters beyond the id, check them against the current API surface rather than assuming the 4.6-era shapes.

[waleedkadous]

Correction to my previous addendum

claude-opus-5 EXISTS — my earlier claim that it doesn't was wrong, based on a stale cached model catalog. Functionally verified today: claude --model claude-opus-5 runs and the model self-identifies as claude-opus-5. The owner corrected me.

Revised guidance for the builder:

• Claude lane default: claude-opus-5 (as the requesting workspace originally asked). Verify against the live Models API at implementation time — not against any cached catalog (that's how my error happened).
• The fail-fast-on-unknown-id validation in Ask The Gestalt Problem - Features Developed in Isolation Without System Awareness #1 should validate against the live /v1/models endpoint or a functional probe, never a baked-in list that goes stale.
• gpt-5.6 for the codex lane stands, same live-verification requirement.