5K

Oracle and Worker Multi-Model Approach

Uses a fast, low-cost worker model for most tool use and code generation, and lets it consult an expensive oracle model when it is stuck

emerging Updated 2026-03-11 By Nikola Balic (@nibzard) Based on Sourcegraph Team
View .md Edit on GitHub
Add to Pack
or

Saved locally in this browser for now.

Cite This Pattern
APA
Nikola Balic (@nibzard) (2026). Oracle and Worker Multi-Model Approach. In *Awesome Agentic Patterns*. Retrieved September 28, 2026, from https://agentic-patterns.com/patterns/oracle-and-worker-multi-model
BibTeX
@misc{agentic_patterns_oracle-and-worker-multi-model,
  title = {Oracle and Worker Multi-Model Approach},
  author = {Nikola Balic (@nibzard)},
  year = {2026},
  howpublished = {\url{https://agentic-patterns.com/patterns/oracle-and-worker-multi-model}},
  note = {Awesome Agentic Patterns}
}

Use when

  • Frontier models are too expensive for all routine work
  • Coding tasks include complex debugging or architecture decisions
  • Worker can detect when its approach is failing

Avoid when

  • Tasks are routine and the worker model handles them alone
  • Latency from model switching is not acceptable

Problem

Relying on a single AI model creates a trade-off between capability and cost. High-performance models are expensive for routine tasks, while cost-effective models may lack the reasoning power for complex problems.

Solution

Implement a two-tier system with specialized roles:

  • The Worker (Claude Sonnet 4): Fast, capable, and cost-effective agent handling bulk tool use and code generation
  • The Oracle (OpenAI o3 / Gemini 2.5 Pro): Powerful, expensive model reserved for high-level reasoning, architectural planning, and debugging complex issues

The Worker can explicitly request Oracle consultation when stuck or needing better strategy. The Oracle reviews the Worker's approach and suggests course corrections without polluting the main agent's context.

graph TD A[User Request] --> B[Worker Agent] B --> C{Need Oracle?} C -->|Yes| D[Oracle Consultation] C -->|No| E[Direct Execution] D --> F[Strategic Guidance] F --> G[Worker Implements] G --> H[Task Complete] E --> H

Evidence

  • Evidence Grade: emerging
  • Most Valuable Findings: Validated in production at Sourcegraph (~90% cost reduction vs. all-frontier); academic foundation from model cascading research (FrugalGPT: up to 98% cost reduction with quality parity)
  • Unverified: Optimal Oracle invocation thresholds remain application-specific

How to use it

Development environments, complex coding tasks, architectural decisions, debugging sessions where initial approaches fail. Also known in literature as model cascading, weak-strong model routing, or hierarchical model systems.

Trade-offs

  • Pros: Cost-efficient use of frontier models; sophisticated problem-solving; specialized AI team approach
  • Cons: Additional orchestration complexity; potential latency from model switching; requires careful Oracle invocation logic

References