OpenCodex Fusion: user-defined lead/main + oracle/sidekick pairs from any exposed models

Start by tracing the existing model catalog, combo routes, sub-agent surface, and supported client/API entry points; the issue links the relevant sub-agent and combo guides. Map how model selection, routing, streaming, cancellation, tool calls, and usage history currently work. Done requires a scoped design and implementation plan covering the profile lifecycle and client compatibility.

Area

Multiple areas

What are you trying to accomplish?

Create and save a custom Fusion combination by independently choosing a primary lead/main model and a secondary oracle/sidekick model from the models OpenCodex already exposes. Lead and main are names for the same primary role; oracle and sidekick are names for the same secondary role. This proposal defines two model slots, not four different role types.

The pair should not be limited to a built-in combination, a single provider, or a vendor-curated preset. Any two compatible entries from the OpenCodex model catalog should be selectable, including entries reached through different providers or routing backends.

The resulting provider-neutral pair should be selectable like one model by any client already supported by OpenCodex. Each slot should retain its chosen model route and reasoning effort. A model should be eligible for either slot whenever its advertised capabilities satisfy the configured policy; fusion/* entries should be excluded from slot selection to prevent recursive Fusion profiles.

The lead/main model should remain in charge of the session: interpreting ambiguous work, deciding when to consult or delegate, reviewing the oracle/sidekick output, and producing the final response. The oracle/sidekick should run in an independent context and contribute second-pass reasoning, critique, research, or bounded execution according to the profile's tool policy and the connected client's capabilities.

What prevents this today?

OpenCodex can expose models from multiple providers, expose separate workers, configure preferred sub-agent models and efforts, and provide fallback chains, but its documentation correctly states that these settings provide guidance rather than proxy-side orchestration and that OpenCodex does not decide when the main agent delegates.

Existing combo/* routes provide failover or weighted distribution. They still select one target for an attempt; they do not let someone select one catalog model for the lead/main slot and another for the oracle/sidekick slot, run both with independent contexts, or return the secondary model's result to the primary model before the user-facing response.

As a result, this workflow currently depends on harness-specific prompting or native collaboration behavior. A custom pairing cannot be saved once and selected consistently across OpenCodex-connected clients.

What should OpenCodex do?

Add user-defined Fusion profiles, with "OpenCodex Fusion" as a possible user-facing name. A profile should define:

• A lead/main model selected from the current OpenCodex model catalog, plus its reasoning effort.
• An oracle/sidekick model independently selected from the same catalog, plus its reasoning effort.
• A separate tool/authority policy for the oracle/sidekick, such as read-only consultation or access to a supported delegated worker surface. The choice of name must not determine authority.
• A trigger policy such as on-demand or required-once-per-turn.
• Bounded consultation count, depth, timeout, and independent fallback behavior for each model.
• A clear failure policy, with lead/main takeover as the safe default when the oracle/sidekick is unavailable.

The CLI and dashboard selectors should use the same effective catalog that OpenCodex exposes to connected clients, after account, provider, entitlement, and capability filtering. Built-in recommended profiles could be offered as conveniences, but must not replace arbitrary user-defined pairings. The two models may come from the same provider or different providers, and profiles should continue to resolve their saved model IDs through OpenCodex's normal routing configuration.

flowchart LR
    C[OpenCodex model catalog]
    C --> L[Choose any compatible lead / main]
    C --> S[Choose any compatible oracle / sidekick]
    L --> P[Saved Fusion profile]
    S --> P
    P --> V[Virtual model: fusion/my-pair]
    V --> H[Any supported client]

Expose each profile as a virtual model such as fusion/<name> through the same catalogs and API surfaces already presented to supported clients. Selecting that model should preserve the client's normal streaming, tool-call, cancellation, and continuation behavior.

From the client's perspective, the lead/main model remains the only user-facing agent. OpenCodex should handle oracle/sidekick exchanges internally, give the secondary model an independent per-session context, and pass compact briefs, results, and feedback between the two slots. The lead/main model should review secondary output before returning a final answer or client-facing tool call.

For an on-demand profile, the lead/main model should receive a private consultation or delegation capability that OpenCodex resolves without leaking an unresolved internal tool call to the client. A required profile should guarantee one completed collaboration round before the lead/main model produces its final response.

The oracle/sidekick model's authority must be explicit and independent of its label. It may be read-only or implementation-capable when an existing supported worker/tool surface is available. Otherwise, OpenCodex should report the unsupported capability or fall back to consultation-only behavior; it should never imply that code was edited or tested when no such tool path exists.

Usage and request history should attribute model, token, latency, and cost information to the lead/main and oracle/sidekick separately while also showing a combined Fusion total. Recursive Fusion calls should be rejected or bounded to one level.

sequenceDiagram
    participant H as Connected client
    participant F as OpenCodex Fusion
    participant L as Lead / main model
    participant S as Oracle / sidekick model

    H->>F: Turn using fusion/my-pair
    F->>L: Normalized turn and collaboration capability
    L->>F: Brief, consultation, or delegated task
    F->>S: Bounded work in independent context
    S-->>F: Advice, result, or feedback
    F-->>L: Oracle / sidekick output
    L-->>F: Final response or client tool call
    F-->>H: Existing client protocol

Example usage or interface

One possible CLI surface, where both IDs come from ocx models list:

ocx fusion create my-pair \
  --lead MODEL_ID_FROM_CATALOG \
  --lead-effort high \
  --sidekick ANOTHER_MODEL_ID_FROM_CATALOG \
  --sidekick-effort medium \
  --secondary-tools read-only \
  --trigger on-demand

ocx fusion list
ocx fusion show my-pair

--main could be accepted as an alias for --lead, and --oracle as an alias for --sidekick. Alternatively, the implementation could use neutral internal names such as primary and secondary while the UI displays Lead / Main and Oracle / Sidekick.

Both model arguments should accept any currently exposed model IDs that meet the configured capability policy. Choosing models from different providers should require no harness-specific configuration beyond the provider setup OpenCodex already uses.

The resulting profile should be usable like an ordinary model through a supported client or API:

{
  "model": "fusion/my-pair",
  "input": "Develop a solution, obtain a second-model review, and return the final result."
}

Equivalent controls in the dashboard should populate both model selectors from the OpenCodex catalog and show each selected route, effort, trigger, fallback state, secondary tool policy, and whether the connected client supports that policy.

Alternatives or workarounds

• Ask the main model to spawn a configured sub-agent. This is useful today, but it is prompt- and harness-dependent, the main model may choose not to delegate, and it does not create one portable named pairing.
• Use an existing combo/* route. Combos provide resilience or distribution, not simultaneous role-based collaboration and synthesis.
• Call OpenRouter Fusion directly. It demonstrates that a server-side compound model can be exposed as one model slug or tool, but it is limited to routes available through that service and its documented panel-and-analyst deliberation contract.
• Run two harness sessions through an external wrapper. This can approximate the workflow but loses integrated context, lifecycle, cancellation, usage attribution, and a single user-facing session.

Additional context

Several current products expose variations of the same two-slot pattern under different names:

• Amp calls the primary model the Main Agent and the secondary model the Oracle. Its Oracle announcement describes the secondary agent being used for planning, debugging, and review. More importantly for this request, The Dial provides a direct configuration precedent: Tune Modes lets someone independently pin the model and reasoning effort for the Main Agent, Oracle, and Subagents from the models available through connected providers. The analogous OpenCodex control would populate both Fusion model choices from OpenCodex's own exposed catalog.
• Cognition calls the primary model the lead and the secondary model the sidekick. Its Local Fusion announcement describes two parallel agents with independent persistent contexts and tools. The Devin CLI documentation presents them as a configurable pair behind one user-facing agent.
• OpenRouter's Fusion announcement demonstrates a server-side multi-model pipeline callable like one model. Its Fusion Router documentation exposes both a model slug and a server tool, allows participating models to be configured, and keeps an outer model responsible for the final answer.

In this proposal, Amp's Main Agent corresponds to Devin's lead, while Amp's Oracle corresponds to Devin's sidekick. These are synonymous names for the primary and secondary positions. Product-specific tool permissions and task allocation may differ, but those differences should be expressed as configuration rather than modeled as additional roles.

Amp's Dial additionally shows why both model slots should be user-tunable from the available catalog instead of hard-coded. OpenCodex already has the relevant provider routing and sub-agent surface; a Fusion profile would combine those pieces into a custom, provider-neutral pairing reusable across its supported clients. This is deliberately distinct from combos, which should retain their existing failover and load-balancing semantics.

Searches for fusion, oracle, sidekick, lead model, and multi-model deliberation found no matching feature request. Related issues cover sub-agent transport, fallback, or approval-review routing rather than a provider-neutral compound two-model profile.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.