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
Add to Pack
Saved locally in this browser for now.
Cite This Pattern
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
@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.
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
- Sourcegraph Team presentation on multi-model AI systems
- FrugalGPT (Stanford, 2023): https://arxiv.org/abs/2305.05176
- RouteLLM (ICLR 2024): https://arxiv.org/abs/2406.18665
- LiteLLM Router: https://github.com/BerriAI/litellm
- Primary source: https://youtu.be/hAEmt-FMyHA?si=6iKcGnTavdQlQKUZ