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

GPT-6.1 Sol workflow adaptation

Checked 2026-10-06. Read for native Responses Multi-agent, API migration, or long-running Sol work. This skill configures no runtime and supplies no delegation authorization.

Native Multi-agent beta

Official Multi-agent documentation establishes these API facts:

• Enable with multi_agent.enabled and the responses_multi_agent=v1 beta opt-in. Children share the request model and tools; this cannot implement a Luna/Sol/Astra mixture within one request.
• max_concurrent_subagents counts active descendants across the tree, excluding root; its default is 3. Do not transfer that counting rule to a different host.
• Hosted multi_agent_call actions execute server-side. Client code handles function_call from every agent, pairing outputs by call_id.
• HTTP continuation must preserve the returned items. WebSocket can inject completed function outputs; track injection acknowledgements. If the response already completed, continue with the returned unaccepted output rather than re-executing its tool.
• Preserve agent attribution and encrypted messages for replay. Present the root's final_answer, keeping worker text separate. Response completion is not artifact acceptance or proof of a child's model identity.
• /responses/compact, reasoning.summary, and max_tool_calls are unsupported. Automatic compaction runs per agent. Do not combine this mode with single-agent dynamic effort updates.

Recheck beta schemas before implementation; an available model alone does not establish a compatible SDK, gateway or client.

Select the mechanism before dispatch

The following are this project's engineering choices, not additional API capabilities:

Work / available mechanism	Routing decision
Fixed reads, transforms or one slow external operation	Use direct/concurrent tools; another agent does not remove the I/O dependency.
Independent reasoning with native API Multi-agent available and authorized	Use bounded same-model Sol lanes; root resolves cross-lane decisions.
Work benefits from different model tiers	Use actual host per-child selection or an explicitly scoped application orchestrator; do not fake a native child override.
Shared mutable contract, deterministic ordered graph or immediate dependency	Keep it serial; native delegation remains optional.

Existing ownership, failure-count and acceptance rules apply to both mechanisms. Separate context is not separate filesystem or tool authority. Since native children share tools, a read-only assignment is not an enforced sandbox. The application must enforce permitted actions before executing client tools. Keep external gates parent-owned; a worker's proposal is not permission to perform them.

Define a useful outcome, baseline, file AND semantic owner, permitted actions, acceptance and escalation. Give Sol room to investigate and implement a coherent slice instead of prescribing a long chain of microtasks. Retain only relevant evidence in each context. Independent investigations can compare hypotheses; overlapping patches still need one owner. Parent review capacity limits useful width even when the API permits more descendants.

Request compatibility and long-task continuity

Migration guidance requires supported effort and Responses for tools. With 6.1's reasoning enabled, remove temperature, top_p, top_logprobs, Chat Completions logprobs, and Responses message.output_text.logprobs includes. These are request compatibility changes, not permission to rewrite unrelated settings.

Dynamic effort updates apply to standard single-agent mode. Preserve request-level effort and ordered updates; automatic compaction/truncation is incompatible. Do not use this mechanism to claim per-child effort changes in native Multi-agent. For native mode, retain per-agent conversation items through its compaction; for Codex, recover actual pending IDs and owners after host compaction.

Async tools, steering and context recovery remain covered in GPT-6 adaptation; they are family workflow capabilities, not newly invented 6.1 features. Use supported controls and verify adoption before dependent work. Keep stable instructions and append bounded task deltas where appropriate, but preserve required tool/history items; cheaper cached input does not justify copying every conversation into every worker.

Acceptance evidence

Validate a real integration with a small authorized independent task before expanding it: attribute every tool call, return each result once, retain history, check the final artifact and audit remaining work. Compare accepted quality, end-to-end time, retry/review cost and actual usage against the existing route. Static documentation and synthetic fixtures cannot prove beta availability, runtime identity, speed or cost improvements.