Redesign GPT-6 routing and proactive Luna fleet workflow

skills/codex-subagent-router/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: codex-subagent-router
-description: Decide when Codex subagents help, route bounded work across Astra, Sol, Terra and Luna, and manage child evidence and lifecycle. Use for delegation requests, routing decisions, or subagent audits; inspecting this skill does not itself authorize spawning.
+description: Route authorized Codex subagents across GPT-6 Luna, Sol and Astra; manage ownership, lifecycle and evidence. Use for delegation, routing decisions or subagent audits. Discovery alone does not authorize spawning.
 ---
 
 # Codex Subagent Router
@@ -11,8 +11,8 @@ Make delegation useful, observable and bounded. Preserve the selected parent mod
 
 Classify the request before using child tools:
 
-- **Audit or advice:** inspect rules, configuration and available tools; report findings without spawning or changing settings.
-- **Authorized execution:** the user requested delegation, or an applicable instruction explicitly authorizes it. Within that scope, actively delegate independent useful slices while the parent advances other work.
+- **Routing audit or advice only:** inspect rules, configuration and available tools; report findings without spawning or changing settings. Ordinary code review can use authorized read-only children under a standing parallel-work policy; it does not authorize edits.
+- **Authorized execution:** the user requested delegation, or an applicable instruction explicitly authorizes it, including an active standing parallel-work policy. Within that scope, proactively dispatch useful independent slices while the parent advances other work; do not wait for another invitation to use agents.
 - **No delegation authorization:** work locally. Automatic skill discovery, model availability, task complexity and a request to edit this skill do not grant permission to spawn.
 
 Honor higher-priority host restrictions even when a lower-priority rule permits delegation. Do not request authorization repeatedly after it has been granted. Never turn a routing recommendation into a new user-owned task.
@@ -23,22 +23,43 @@ Before dispatch classify each candidate:
 - **C:** a bounded investigation/draft that needs latest-baseline parent integration.
 - **S:** an immediate dependency, overlapping contract/state, permissions, production mutation, PR/merge/deploy or final acceptance; keep it in the parent.
 
-Spawn only P/C work with a concrete output and useful parent work available. Do not spawn for one command, ceremonial probes, duplicate reviews or a model quota. Batch homogeneous small work.
+Spawn only P/C work with a concrete output and useful parallel benefit. Prefer useful parent work alongside children; when the host permits, multiple independent children may run while the parent waits to synthesize and accept their results. Honor any stricter host requirement for concurrent parent work. Do not spawn for one command, ceremonial probes, duplicate reviews or a model quota. Batch homogeneous small work.
+
+Choose the execution mechanism before a model: local tools for fixed commands/transforms, host-supported concurrent or async tools for independent I/O, and authorized children for useful independent reasoning or implementation. Waiting on a tool alone is not a reason to create an agent. Prefer a coherent outcome with acceptance over many tiny handoffs; bound ambiguity and ownership rather than prescribing every reasoning step.
+
+## Proactive Luna fleet
+
+Once authorized, parallel execution is the default for ready independent work. At the first useful decomposition and after each material result or scope change, look for slices that can run alongside the parent's critical path. Dispatch those slices promptly instead of finishing the parent's entire investigation first. Do not require proof of measured speedup before a clearly useful split.
+
+- Fan out bounded Luna assignments by independent evidence source, module, test suite or settled file/semantic ownership. Useful lanes include source inventory, artifact comparison, fixed validation, focused first-pass review and settled patches. Batch tiny homogeneous items into meaningful assignments.
+- Keep a small ready queue. Use as many actually available child slots as useful independent work and parent review capacity support; there is no fixed one-child or two-child ceiling. Reserve the parent when the host counts it. For example, four total active slots permit at most three concurrent children alongside the parent, not an unlimited fleet.
+- Refill available capacity when a result is handed back: accept/triage it, reuse an eligible idle child or dispatch the next ready slice. Do not wait for a whole wave if another independent slice is ready. Verify actual capacity; completed or interrupted does not necessarily mean released.
+- The parent owns contract decisions, cross-result synthesis and acceptance, and advances a parent-suitable critical-path slice when one is available. Integrate incrementally. If review backlog, conflicting ownership, I/O contention or rate limits becomes the bottleneck, reduce new dispatch and drain it.
+- One owner per file AND shared semantic contract. Parallel disjoint writes only when the host permits them; shared registries, integration and external gates remain serial. Read-only workers also need stable baselines and coordinated mutable sessions.
+- Choose Sol directly for slices requiring open-ended investigation or design, and Astra for the hardest synthesis. A fleet is a capacity strategy, not an instruction to force every task onto Luna or to duplicate the same review.
+
+Stay local for a trivial task, no useful parallel benefit, an immediate dependency with no independent work, or inadequate host support. State the relevant reason briefly when a requested parallel run cannot proceed; do not produce a routing report for every small task. Standing authorization does not authorize recursive unbounded fan-out, new user-owned tasks, configuration changes or external writes.
 
 ## Select a supported route explicitly
 
 | Work shape | Initial route |
 | --- | --- |
-| Known-source collection, fixed checks, logs | Luna low/medium |
-| Bounded classification, conversion, settled patch with fixed checks | Luna high |
-| Everyday implementation, debugging, locating/correlating artifacts | Terra medium; high when needed |
-| Bounded complex analysis, design or financial/security evidence | Sol medium; high when needed |
-| Hardest independent synthesis across code, tools and research | Astra medium; high when needed |
+| Known-source collection, fixed checks, logs | GPT-6 Luna low; medium for multi-step work |
+| Bounded classification, conversion, settled patch with fixed checks | GPT-6 Luna medium; high for local reasoning |
+| Everyday implementation, debugging, locating/correlating artifacts | GPT-6 Sol medium |
+| Bounded complex analysis, design or financial/security evidence | GPT-6 Sol medium/high |
+| Hardest independent synthesis across code, tools and research | GPT-6 Astra medium/high |
 | Shared decisions, integration and external/final gates | Current parent, serial |
 
-These are starting heuristics, not measured cost rankings. Pick sufficient capability directly; do not escalate through every model. Missing access/data and tool failures need diagnosis, not a stronger model. After two same-class failures, pause that slice and return the evidence to the parent.
+Luna is the first candidate when inputs are bounded, the contract is settled, correctness is cheaply checkable, and failure is contained. All four conditions matter; a short diff can still hide a shared semantic decision. Use Sol directly when investigation, design choices or cross-file causal reasoning dominate. Use Astra directly for the hardest independent synthesis when expected quality or saved rework justifies it. Do not make high/max Luna a mandatory step before Sol.
 
-Use the lowest adequate supported effort. Use xhigh/max for a concrete depth need or an explicit compatible role requirement; ultra only when exposed and justified by the workload. Model choice and working role are separate. A role named "explorer" is not proof of sandbox isolation.
+These are starting heuristics, not measured task-cost rankings. Lower prices broaden the useful Luna workload; fill supported capacity with useful work under existing authorization, never infer extra host slots from price. Pick sufficient capability directly; do not escalate through every model. Missing access/data and tool failures need diagnosis, not a stronger model. After two same-class failures, stop that slice and return the evidence to the parent; escalate earlier when the contract no longer fits. Preserve useful evidence on handoff instead of restarting discovery.
+
+Resolve exact IDs from the child-tool schema: prefer `gpt-6-luna`, `gpt-6-sol`, `gpt-6-astra` only when exposed. GPT-5.6 models are explicit compatibility routes, not aliases for GPT-6. For a legacy-only host use [routing boundaries](references/routing-matrix.md); do not silently substitute an explicitly required generation. A role bound to GPT-5.6 Luna remains GPT-5.6 even when named `luna_worker`.
+
+Retire Terra from recommended routes and automatic fallbacks: Sol owns ordinary implementation and investigation. Preserve explicitly pinned models and existing configuration; editing this skill does not authorize rewriting them.
+
+Use the lowest adequate supported effort. Use none only for straightforward extraction/conversion when the host exposes it and checks cover the result; low/medium are the usual starts for tool work. Use xhigh/max for a concrete depth need or an explicit compatible role requirement; ultra only when exposed and justified by the workload, never inferred from API support. Model choice and working role are separate. A role named "explorer" is not proof of sandbox isolation.
 
 At dispatch, specify model AND effort when the host permits selection. Otherwise omitted settings may inherit the parent or configured defaults. Prefer a self-contained contract and no history fork; use bounded history only when necessary. Respect full-history/override incompatibilities. Never claim prompt text changed a runtime parameter.
 
@@ -50,7 +71,9 @@ Use the first authorized, low-risk real child task as the capability observation
 
 Treat workspaces as shared unless isolation is confirmed. Tool schemas may lack per-child sandbox, timeout, role or close controls. Contract limits remain instructions, not enforced capabilities. No adequate child route: keep feasible work local and disclose the gap.
 
-Read [runtime and configuration](references/platforms.md) only for configuration/CLI diagnosis. Read [routing boundaries](references/routing-matrix.md) for ambiguous choices or live artifact collection.
+Read [runtime and configuration](references/platforms.md) only for configuration/CLI diagnosis. Read [routing boundaries](references/routing-matrix.md) for ambiguous choices, legacy fallbacks or live artifact collection; read [model economics](references/model-economics.md) for dated prices and cost calibration.
+
+Read [GPT-6 adaptation](references/gpt6-adaptation.md) when async execution, steering, context recovery or dynamic effort changes affect the workflow. API features are not automatically Desktop/CLI capabilities; use only exposed controls.
 
 ## Dispatch, observe, accept
 
@@ -66,4 +89,6 @@ Use [evidence packets](references/evidence-packet.md) when structured evidence i
 
 Load only needed references; keep long logs on disk. Avoid whole-history forks and repeating contracts, packets or prior findings. Account for parent context/reasoning, child usage, waiting, retries and integration when evaluating cost.
 
+After steering or context compaction, recover the current objective, accepted corrections, permissions, baseline, file/semantic owners and pending tool/child IDs before continuing dependent work. Retain valid completed evidence; revalidate only results affected by the change. A queued correction is not proof that a running writer has stopped or adopted it.
+
 Production read-only collection is routable by work shape; mutation and final semantic acceptance stay parent-owned. Do not silently relax a project's literal model-owner requirement. Identify the actual rule and resolve it only through authorized changes.

skills/codex-subagent-router/references/evidence-packet.md

@@ -30,7 +30,7 @@ This fragment illustrates shape; it is not a real tool receipt:
   "tool": "collaboration.spawn_agent",
   "child_id": "synthetic-child",
   "status": "completed",
-  "requested": {"model": "gpt-5.6-terra", "role": "explorer", "effort": "medium"},
+  "requested": {"model": "gpt-6-sol", "role": "explorer", "effort": "medium"},
   "observed": {"model": "unknown", "role": "unknown", "effort": "unknown"},
   "identity_source": "unknown"
 }

skills/codex-subagent-router/references/gpt6-adaptation.md

@@ -0,0 +1,39 @@
+# GPT-6 workflow adaptation
+
+Checked 2026-09-23. Read only when these capabilities affect the task. This reference adapts the routing policy; it does not configure a harness or grant permissions.
+
+## Prompt shape and task granularity
+
+The official [skills and prompts guidance](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra) recommends precise discovery descriptions, progressive disclosure and fewer rigid recipes. Apply that here by giving a goal, constraints, ownership and acceptance; leave implementation choices open unless a contract or fragile operation requires an exact procedure. Put API mechanics here instead of expanding every task prompt.
+
+[GPT-6 guidance](https://developers.openai.com/api/docs/guides/latest-model) highlights Astra's stronger instruction following, long-task coherence and tendency to ask clarifying questions or over-test. Keep authorized routine choices autonomous, resolve real instruction conflicts explicitly, and stop validation once relevant checks pass unless new evidence warrants more. These are Astra observations; evaluate their usefulness for Sol/Luna rather than claiming equal behavior. More capability does not authorize delegation.
+
+## Async tools: overlap useful work
+
+[Async tool calling](https://developers.openai.com/api/docs/guides/async-tool-calling) lets GPT-6 continue independent work while an application executes a function/custom tool; API definitions use `async: true`, with results paired to the original `call_id`. Background response generation is a different mechanism.
+
+In Codex, use the host's exposed job/session IDs, wait and cancellation controls. Track pending work only as needed: ID, owner, baseline, dependency, last state and result. Continue unrelated work while waiting, but do not consume an absent result or declare completion with a required job outstanding. Mutable shared state and dependencies still require serialization. A JavaScript Promise or a shell job is not proof of API async support.
+
+Prefer a fixed tool batch for enumerable reads and transformations. Use a child when the independent slice needs judgment and delegation is authorized. Do not spawn a child simply to wait on another tool. In an API application, the application must execute and reconcile jobs; prompt text cannot add that machinery.
+
+## Steering: preserve progress, reconcile side effects
+
+[Mid-turn steering](https://developers.openai.com/api/docs/guides/steering) is documented for GPT-6 over Responses WebSockets. Acceptance queues the update; it does not cancel running tools, undo writes or establish that the model acted on it.
+
+Treat a user correction as a delta to the active objective. Keep compatible work and accepted evidence. Tell affected children the changed constraint; if ongoing writes conflict, use actual interruption controls, inspect partial changes and verify state before assigning a replacement owner. Reassess late results against the corrected contract and baseline before integration. A status question does not cancel work. Cancellation ends obsolete work, not the obligation to report actions already taken.
+
+The Desktop/CLI message and interruption tools have their own semantics; do not emit WebSocket events through tools that lack those fields. A successful message-send receipt proves delivery/queuing only to the extent the host reports it.
+
+## Effort and context continuity
+
+[Reasoning configuration updates](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) support changing effort between responses in GPT-6 standard single-agent mode. They do not switch model or change a child binding. Keep request-level effort unchanged for cache continuity; record updates in order. The response's effort field still reports the request-level value. Updates cannot be adjacent or combined with automatic compaction/truncation; `/responses/compact` rejects such histories. The documented explicit `compaction_trigger` route requires a fresh effort update after compaction. Recheck compatibility before implementing.
+
+In Codex, do not claim to change active effort without a supported control and receipt. Choose supported effort when dispatching an authorized child. Missing controls are a host limitation, not a reason to launch a nested CLI or edit global configuration.
+
+For long tasks, retain a compact operational checkpoint when needed: goal, corrections, authorization, baseline, completed evidence, next dependency, owners and pending IDs. Preserve actual tool state and required conversation items; a prose summary is not an API tool result. After host compaction, resume from that state rather than rereading everything or repeating accepted work. Large context capacity is not a reason to fork full history into every child.
+
+## Existing capabilities and boundaries
+
+The [GPT-6 family guide](https://developers.openai.com/api/docs/guides/latest-model) identifies computer use, structured outputs, programmatic tool calling, multi-agent orchestration, caching and compaction as continuing capabilities, not all newly introduced in GPT-6. Use structured tools and deterministic code where they fit; use visual/browser tools when UI evidence is actually needed. Confirm host access and shared browser/session ownership. Neither a screenshot nor a passing schema validator proves end-to-end correctness.
+
+The guide's misalignment monitoring is provider-side safety behavior associated with Astra, not a prompt-enabled self-review mode or a substitute for parent acceptance. Do not claim it is available identically for all routes.

skills/codex-subagent-router/references/lifecycle.md

@@ -16,6 +16,14 @@ Read before multi-round coordination, cancellation, or capacity diagnosis. Names
 
 A minimal ledger records child ID, P/C classification, file/semantic ownership, dependency, requested route, last observed state and acceptance. Do not invent timestamps, identities or close events.
 
+## Steering and pending tools
+
+On a correction, update the affected contract and preserve unaffected evidence. Sending an incremental message does not establish that a running child or tool has adopted it. If its writes now conflict, interrupt through available controls, verify the state and inspect partial changes before transferring ownership. Review late results against the current contract and baseline; do not integrate them merely because they completed successfully.
+
+Keep required async tool jobs in the same dependency view as children, using their actual job/session/call IDs. While waiting, advance independent work; before dependent acceptance, collect the real result. Steering and child interruption need not cancel external jobs. Cancel obsolete jobs through the host when supported, otherwise track/report the remaining state. Never resubmit a potentially mutating call solely because its receipt is delayed.
+
+After context compaction, recover objective, permissions, owners, pending IDs and accepted evidence before dispatching more work. Detailed API-versus-host limits are in [GPT-6 adaptation](gpt6-adaptation.md).
+
 ## Cancellation and handback
 
 Interrupting does not undo files or guarantee descendant cancellation. First preserve useful returned evidence, stop affected writers, inspect partial changes, then assign the remaining work to one owner. Never reset shared files wholesale.

skills/codex-subagent-router/references/model-economics.md

@@ -0,0 +1,33 @@
+# Model economics
+
+Read for cost-sensitive routing or when revising defaults. Checked 2026-09-23; recheck official prices before a later price-dependent decision. This is an API reference snapshot, not a Codex subscription quota or billing estimate.
+
+## Verified price basis
+
+USD per million tokens, Standard processing, prompts up to 272K input tokens:
+
+| Exact model ID | Input | Cached input | Cache write | Output |
+| --- | ---: | ---: | ---: | ---: |
+| gpt-6-luna | 0.10 | 0.01 | 0.125 | 0.50 |
+| gpt-6-sol | 2.00 | 0.20 | 2.50 | 10.00 |
+| gpt-6-astra | 10.00 | 1.00 | 12.50 | 50.00 |
+
+Source: [OpenAI pricing](https://developers.openai.com/api/docs/pricing). For equal token volumes and the same billing category, Luna is 1/20 of Sol and 1/100 of Astra; Sol is 1/5 of Astra. These are arithmetic price ratios, not observed savings, speed or success rates.
+
+Long prompts above 272K input tokens charge 2x input/cache rates and 1.5x output for the full request. Processing tier, tools and regional processing can change the bill. Do not multiply Codex subscription usage by API prices or assume a Desktop service tier follows the Standard table.
+
+Retirement comparison: [GPT-5.6 Terra](https://developers.openai.com/api/docs/models/gpt-5.6-terra) lists input 2.00, cached input 0.20 and output 12.00 under the same short-context Standard basis. GPT-6 Sol has equal input/cache-read rates and a 16.7% lower output rate (10 vs 12). Terra therefore offers no token-rate saving in these categories; this does not prove equal token use, latency or quality per task.
+
+## Design implications
+
+Official positioning: [Luna](https://developers.openai.com/api/docs/models/gpt-6-luna) targets focused, high-volume work; [Sol](https://developers.openai.com/api/docs/models/gpt-6-sol) targets complex coding and agentic workflows; [GPT-6 guidance](https://developers.openai.com/api/docs/guides/latest-model) places Astra at the highest capability level. Sol and Luna document API efforts none/low/medium/high/xhigh/max. Actual child models, efforts and role bindings must still come from the host schema.
+
+The engineering policy is three routes: Luna for bounded, settled, cheaply verifiable work; Sol for implementation and investigation requiring judgment; Astra for the hardest independent synthesis. Retire Terra from recommendations and automatic fallbacks: Sol absorbs its former workload and avoids maintaining another routing boundary. This is a routing design choice, not a measured claim that Sol dominates every Terra workload. Price alone does not establish that Luna can perform open-ended development reliably.
+
+## Measure accepted work
+
+Compare the same task shape and acceptance standard. Include parent context/reasoning, every child's usage, tools, retries, parent review and reintegration. For API estimates apply the actual rate to each billed category, including billed reasoning/output tokens without double-counting; keep wall time separate. With unknown usage or billing tier, report unknown cost and observable proxies instead of fabricated savings.
+
+A cheaper child helps only if its savings exceed added orchestration and correction. One avoided parent investigation may matter more than many cheap child tokens. Do not turn the 20x ratio into a twenty-retry allowance, a fan-out quota or permission to duplicate reviews. Keep concurrency tied to useful independent work and actual host capacity.
+
+Broaden Luna assignments after comparable accepted results demonstrate stable quality and lower total effort. Move a task shape directly to Sol when ambiguity, repeated correction or parent rework dominates. For a new generation, use the first authorized useful bounded task as evidence; synthetic parser tests and static scenario reviews cannot establish model quality or latency.

skills/codex-subagent-router/references/platforms.md

@@ -23,13 +23,15 @@ model = "gpt-6-astra"
 model_reasoning_effort = "medium"
 
 [agents]
-default_subagent_model = "gpt-5.6-terra"
+default_subagent_model = "gpt-6-sol"
 default_subagent_reasoning_effort = "medium"
 max_concurrent_threads_per_session = 3
 ```
 
 This is not an automatic router, permission grant or universal host configuration. Never overwrite an existing config to install this example. Preserve user model/provider choices and verify the actual client accepts the keys. Per-agent configuration and host overrides may change resolution.
 
+The Sol default assumes GPT-6 Sol is exposed and suits mixed engineering work. Explicitly route bounded tasks to GPT-6 Luna where supported; do not make Luna a universal fallback for arbitrary inherited work. If only GPT-5.6 children are available, use the [legacy compatibility routes](routing-matrix.md). A fixed `luna_*` role may still bind GPT-5.6 Luna/max: inspect the binding, then use an overridable role if available and appropriate. Do not rename or claim to upgrade a fixed role through prompt text.
+
 The official Codex configuration describes the child-thread limit as excluding the parent. A collaboration tool may expose a different active-slot count including the parent. Use that live tool's counting and release semantics; do not copy either number blindly.
 
 When selecting a route, explicitly request model and effort with a compatible fork mode if supported. Check omitted-setting inheritance, custom-agent bindings and override restrictions. A prompt cannot implement an unsupported model switch.

skills/codex-subagent-router/references/routing-matrix.md

@@ -4,8 +4,11 @@ Read only when the entrypoint leaves a routing choice unresolved.
 
 | Boundary | Decision |
 | --- | --- |
-| Many easy tasks | Batch bounded Luna/Terra slices; volume alone does not justify Astra. |
-| Ordinary cross-file bug | Terra; file count alone does not justify escalation. |
+| Many easy tasks | Partition independent bounded Luna batches across available capacity; size batches to keep coordination and acceptance useful. Volume alone does not justify Astra. |
+| Ordinary cross-file bug | GPT-6 Sol; file count alone does not justify Astra. |
+| Small patch with settled semantics and deterministic acceptance | GPT-6 Luna medium/high if failure is contained; parent checks the diff and behavior. |
+| Small patch changes authentication or a shared schema contract | Parent settles shared decisions; bounded investigation may use Sol. Small size is not evidence of low ambiguity. |
+| Cheap Luna attempts require repeated parent rewrites | Choose Sol directly next time for this shape; count total accepted-task cost. |
 | Difficult accounting discrepancy | Sol reasoning; parent owns the semantic decision. |
 | Coupled architecture across runtimes and tools | Consider Astra directly; keep shared decisions serial. |
 | Missing credential or inaccessible source | Resolve the evidence/environment gap; model escalation cannot supply access. |
@@ -14,9 +17,21 @@ Read only when the entrypoint leaves a routing choice unresolved.
 | Repository requires Sol parent | A Sol child cannot replace that owner; preserve the gate until an authorized supported change. |
 | Accepted output, unknown child model | Accept only after normal parent checks; do not attribute the result to the requested model. |
 
+## Legacy and mixed hosts
+
+Check each route independently. The API catalog does not update an existing session's tool schema.
+
+| Unavailable preferred route | Supported compatibility choice |
+| --- | --- |
+| GPT-6 Luna | GPT-5.6 Luna low/medium for fixed collection/checks, high for settled transformations or patches; otherwise Sol or local work. |
+| GPT-6 Sol for implementation/investigation/complex analysis | GPT-5.6 Sol medium/high, if exposed and adequate; otherwise local work. |
+| GPT-6 Astra | An adequate supported Sol route or local work; disclose a capability gap if neither suffices. |
+
+These are work-shape fallbacks, not capability equivalence claims. Terra is retired from recommended routes and automatic fallbacks; do not select it merely because a legacy host exposes it. Preserve an explicit user-pinned model or existing configuration until an authorized change. If a required model is unavailable, report the exact gap before dependent dispatch. Never invent `gpt-6-terra`. A mixed host may use GPT-6 Sol and GPT-5.6 Luna without reverting every route. Record the exact requested ID and fallback reason. Unknown observed identity stays unknown.
+
 ## Production Artifact Collection
 
-- Luna: use known hosts/endpoints/paths and fixed selectors to read or download actual reports, JSON, logs or job outputs; verify size/hash, parseability, required fields and specified counts. Terra: locate the current output through bounded read-only investigation, diagnose retrieval failures, or correlate logs and artifacts by run/version. Do not launch both by default; use Terra only when discovery or diagnosis is needed.
+- GPT-6 Luna: use known hosts/endpoints/paths and fixed selectors to read or download actual reports, JSON, logs or job outputs; verify size/hash, parseability, required fields and specified counts. GPT-6 Sol: locate the current output through bounded read-only investigation, diagnose retrieval failures, or correlate logs and artifacts by run/version. Do not launch both by default; use Sol only when discovery or diagnosis is needed. Apply the legacy table when these routes are unavailable.
 - Contract: name the production source, expected run/date/version, allowed read operations, bounded time/range/volume, local destination and acceptance checks. Reuse approved access and applicable server tools. Keep secrets out of prompts/receipts. Remote access stays read-only; explicitly allow local artifact writes even for a collector role.
 - Evidence: preserve the actual downloaded artifact and record source, retrieval time/timezone, producer run/version and generation time when exposed, local path, bytes/hash and check results. Unknown provenance stays unknown. Verify the expected run/freshness; mtime or successful download alone does not prove current output. Use immutable run identifiers where possible; detect/retry boundedly if files change during collection.
 - No fixture, cache or old snapshot may stand in for requested live output. If the current artifact is missing, stale, inconsistent or inaccessible, report that gap. Do not trigger jobs, regenerate artifacts, restart services, change permissions/configuration or deploy as part of collection; return such remediation to the parent under existing authorization.
@@ -30,4 +45,4 @@ Use actual usage counters when exposed. Otherwise report observable proxies (cha
 
 If context dominates, narrow inputs and avoid full-history forks. If output dominates, bound logs and returns. If reasoning/retries dominate, clarify acceptance and choose adequate capability/effort directly. Preserve required tests and material findings.
 
-Official model positioning checked 2026-09-14: [Models](https://developers.openai.com/api/docs/models). The route table is an engineering starting strategy, not a measured cost ranking. Runtime tool schemas remain the source for actual child availability.
+Official model positioning checked 2026-09-23: [GPT-6 guidance](https://developers.openai.com/api/docs/guides/latest-model). See [model economics](model-economics.md) for the dated API price basis. The route table is an engineering starting strategy, not a measured task-cost ranking. Runtime tool schemas remain the source for actual child availability.