Adapt Sol 6.1 native multi-agent and workflow compatibility

skills/codex-subagent-router/SKILL.md

@@ -29,6 +29,8 @@ Spawn only P/C work with a concrete output and useful parallel benefit. Prefer u
 
 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.
 
+GPT-6.1 Sol also supports native Responses Multi-agent beta. Its children share the request model/tools; the tiered route table below applies only where the host actually permits per-child selection. Read [Sol 6.1 adaptation](references/sol61-adaptation.md) before using native Multi-agent or reconciling it with host routing. Neither beta enablement nor this reference authorizes delegation.
+
 For queue states, integration backpressure and proactive expert formations, read [fleet scheduling](references/fleet.md).
 
 ## Proactive Luna fleet
@@ -79,6 +81,8 @@ Read [runtime and configuration](references/platforms.md) only for configuration
 
 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.
 
+For 6.1-specific request compatibility, native tool-result attribution and compaction limits, read [Sol 6.1 adaptation](references/sol61-adaptation.md). Native Multi-agent's automatic compaction is not compatible with standard single-agent dynamic effort updates; choose a supported mode rather than combining every feature.
+
 ## Dispatch, observe, accept
 
 Give a compact contract: goal/symptom; baseline and non-goals; read/write/forbidden paths and semantic owner; requested model/effort/working role and real isolation; permitted actions; acceptance; return evidence; escalation. Include a time/checkpoint budget when useful, but do not call it an enforced timeout unless the host supplies one.

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

@@ -19,6 +19,8 @@ If the next action is immediately dependent on an unassigned task, keep it local
 
 ## Choose a formation for the task
 
+First identify whether execution uses host-managed per-child routes or [native Responses Multi-agent](sol61-adaptation.md). Native mode uses the request's model/tools across the tree; use several focused Sol lanes there, not fictional Luna/Astra child overrides. The formations below describe work ownership; mixed models require actual host support.
+
 - Independent investigation: several focused investigators may cover distinct sources, consumers or falsifiable hypotheses. They should not all produce the same broad summary.
 - Settled implementation: multiple GPT-6 Luna workers own bounded, settled, independently checkable slices; use GPT-6.1 Sol directly when implementation requires investigation or design judgment. Shared registries, schema and generated outputs require one owner even when paths differ.
 - Difficult consequential decision: an Astra specialist analyzes the bounded uncertainty while the parent and other workers advance unaffected work. Gate dependent implementation on the parent's accepted contract. Read [expert intervention](escalation.md) for triggers and progress-based continuation.

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

@@ -4,6 +4,8 @@ Checked 2026-09-23. Read only when these capabilities affect the task. This refe
 
 GPT-6.1 Sol migration checked 2026-10-06: use the exact `gpt-6.1-sol` ID only when the relevant host exposes it. Preserve supported effort; its API rejects none/minimal and requires Responses for tools. Start at low when replacing an unsupported effort and verify representative work. [Model specifications](https://developers.openai.com/api/docs/models/gpt-6.1-sol) and [migration guidance](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6.1-sol) take precedence over older GPT-6 Sol assumptions. The workflow capability sections below retain their own original verification date; do not infer per-model or host support from family membership.
 
+Read [Sol 6.1 adaptation](sol61-adaptation.md) for native Responses Multi-agent beta and its distinct tool, history and compaction contracts. The single-agent effort procedure below must not be combined with that mode.
+
 ## 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.

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

@@ -38,6 +38,8 @@ The official Codex configuration describes the child-thread limit as excluding t
 
 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.
 
+Native Responses Multi-agent beta is a separate mechanism: children share the request model and tools, and its active-descendant limit excludes root. Codex host schemas may expose per-child model overrides and different slot semantics. Select the actual mechanism first; do not put API beta fields into Codex TOML or promise cross-model native children. See [Sol 6.1 adaptation](sol61-adaptation.md) for beta opt-in, history handling and incompatible request options.
+
 ## Diagnosis and safe fallbacks
 
 Resolve the executable actually used by the relevant client, inspect its help/schema and record its version when needed. Do not prescribe speculative CLI flags or launch model calls merely to print a marker. Use an authorized real task to verify child execution.

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

@@ -0,0 +1,43 @@
+# 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](https://developers.openai.com/api/docs/guides/responses-multi-agent) 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](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6.1-sol) 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](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) 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](gpt6-adaptation.md); 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.