Model Resolution Pipeline

Relevant source files

The following files were used as context for generating this wiki page:

• src/shared/AGENTS.md
• src/agents/oracle.ts
• src/agents/momus.ts
• src/agents/librarian.ts
• src/agents/sisyphus/default.ts

The Model Resolution Pipeline is a multi-stage orchestration system within the OhMyOpenCode environment designed to select the most appropriate Large Language Model (LLM) for a specific agent or task. It ensures that specialized subagents—such as Oracle, Momus, and Librarian—are paired with models that match their required reasoning effort, cost profile, and technical capabilities.

The pipeline manages a transition from high-level user or system intent to concrete model IDs (e.g., GPT-5.4 variants or specialized thinking models). It incorporates fallback chains and fuzzy matching to maintain system stability even when preferred models are unavailable or restricted by configuration.

Sources: src/shared/AGENTS.md:27-33, src/agents/oracle.ts:184-210

Pipeline Architecture and Flow

The resolution process follows a deterministic hierarchy to determine which model an agent should use. This hierarchy prioritizes explicit user preferences before falling back to pre-configured system defaults and provider chains.

Resolution Tiers

Tier	Component	Description
1	UI Override	Primary agents allow users to manually select a model through the interface, which bypasses all automated logic.
2	Category Default	Models are assigned based on the agent's functional category (e.g., advisor, exploration, worker).
3	Provider Fallback	Uses AGENT_MODEL_REQUIREMENTS to find the next best available model in a pre-defined chain if the primary choice is unavailable.
4	System Default	The ultimate fallback model used when no other resolution criteria are met.

Sources: src/shared/AGENTS.md:28-32, src/agents/oracle.ts:11-30

Agent-Specific Model Configuration

Different agents within the pipeline are configured with metadata that influences how the resolution pipeline treats them. This includes cost profiles, reasoning efforts, and tool restrictions.

High-Reasoning Agents (Oracle & Momus)

Agents like Oracle and Momus are categorized as advisor agents with an EXPENSIVE cost profile. For GPT-based models, the pipeline specifically sets reasoningEffort: "medium" to ensure deep analysis for architectural or review tasks.

Capability-Based Resolution

The pipeline also adjusts configurations based on the underlying model provider. For non-GPT models (such as Claude), the pipeline may enable extended "thinking" modes with specific token budgets.

• GPT Models: Optimized for textVerbosity and specific reasoning effort levels.
• Non-GPT Models: Configured with thinking: { type: "enabled", budgetTokens: 32000 }.

Sources: src/agents/oracle.ts:196-208, src/agents/momus.ts:223-231

Key Implementation Components

The pipeline is orchestrated through several specialized TypeScript files within the src/shared/ directory:

• model-resolver.ts: The primary entry point for model selection logic.
• model-resolution-pipeline.ts: Handles the orchestration of the various resolution tiers.
• model-requirements.ts: Defines the fallback chains used when a primary model is not available.
• model-availability.ts: Performs fuzzy matching and status checks on available models to ensure the resolved ID is valid.

Sources: src/shared/AGENTS.md:33

Model Requirements and Tooling

The resolution pipeline also interacts with AGENT_TOOL_RESTRICTIONS to ensure that the resolved model has the appropriate permissions for the agent's mode. For instance, subagents are typically restricted from high-level orchestration tools like task or apply_patch unless specifically permitted.

// Example of tool restriction application during agent creation
const restrictions = createAgentToolRestrictions([
  "write",
  "edit",
  "apply_patch",
  "task",
]);

// This configuration is merged into the resolved agent setup
return {
  ...base,
  ...restrictions,
  prompt: ORACLE_DEFAULT_PROMPT,
};

Sources: src/agents/oracle.ts:185-194, src/agents/librarian.ts:21-27

Conclusion

The Model Resolution Pipeline provides a robust abstraction layer between agent logic and LLM providers. By utilizing a hierarchical resolution strategy and specialized requirements chains, the system ensures that high-stakes tasks—like architectural reviews performed by the Oracle or plan validations by Momus—always receive the necessary computational reasoning power while falling back gracefully to simpler models for trivial tasks.