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

5.5 KiB

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 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 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 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 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 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 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.