The Sum Is Greater Than the Parts: Inside Traycer’s Multi‑Model Architecture
Written by
Tanveer Gill
Nov 26, 2025
In our first post, we talked about building with intent and shipping with confidence, treating software like infrastructure instead of “vibe coding” with whatever your AI agent spits out. This post is about what makes that possible under the hood.
Traycer doesn’t rely on a single, all‑purpose model. Instead, we treat models like specialists in a team. Different stages of the workflow—planning, task decomposition, context gathering, and verification—have very different needs. No single model is the best at all of them.
So Traycer runs an ensemble of LLMs, each chosen for a specific job:
Sonnet‑4.5 is the backbone of planning & task decomposition
GPT‑5.1 is the backbone for verification, code critique, and debugging
Grok‑4.1‑fast from xAI acts as parallel “scouts” for fast context gathering
GPT-5.1-mini for summarizing large context and tool call outputs
parallel.ai for low‑latency, high‑accuracy web lookups
The result: the sum is genuinely greater than the parts. Instead of one giant model trying to do everything, Traycer is the outer‑loop Agent that coordinates a team of specialists and your inner‑loop code generation agents.
Outer loop vs. inner loop
Most AI dev tools live directly in the inner loop: generate code from a prompt, patch a file, and run tests.
Traycer sits in the outer loop:
Planning complex changes
Decomposing them into sensible phases and tasks
Gathering context from large codebases and the web
Verifying and reviewing the changes produced by code‑gen agents
Traycer is the system that decides:
What should actually be done?
What files and services does this touch?
Did this change respect the constraints and avoid regressions?
That’s a very different problem than “write the next 30 lines of code,” and it turns out it benefits hugely from a multi‑model approach.
Why an ensemble instead of a single model?
Strength in diversity: We use different models for planning vs verifying the plan against the generated code. Sonnet-4.5 is more efficient in terms of both accuracy and planning speed. On the other hand, GPT-5.1 performs better at code analysis, review, and debugging. Thus, Traycer pairs Sonnet-4.5’s planning with GPT-5.1’s verification of code changes against the plan.
Latency vs. intelligence tradeoffs: It is too expensive to burn Sonnet‑4.5 or GPT‑5.1 tokens to figure out which files might be relevant. Lightweight models can do that far more quickly and cheaply. And they can cover a lot of ground quickly with fast, cheap parallel agents.
Separation of concerns: We want the “thinking” to live in our strongest models, and the “gathering” and “plumbing” to be done by smaller, parallel agents that never inject their own opinions. This ensures that the strong model’s context window is not choked by the back-and-forth of highly verbose operations, such as the hit-and-trial of gathering context in a large codebase.
This ensemble design lets us leverage the unique advantages of different models in a single product experience.
A typical Traycer run
Let’s walk through a simplified example.
Task: “Introduce rate limiting for our public API and add the necessary monitoring so we don’t break existing customers.”
Here’s what happens:
Groundwork: A main-agent powered by Sonnet-4.5 would gather requirements and build the understanding needed to develop a detailed plan to achieve this task. It will orchestrate the following:
Grok‑4.1‑fast sub-agents that fan out to find a ranked list of relevant files and services:
Existing rate limiters (if any)
API gateway/router code
Monitoring & alerting configs
parallel.ai sub-agents to fetch external context
Library documentation
Example patterns
Clarify intent: Takes your input on the design decisions that are missing in your original query.
Building the plan: Using your intent + the relevant code, and web searches, Sonnet‑4.5:
Decomposes the work into implementation phases
Creates a detailed implementation spec for each phase as they are worked through
Your code‑gen agents implement: Traycer hands structured tasks (with relevant file lists and constraints) to your existing code generation agents. They write and update the code.
GPT‑5.1 verifies and reviews once changes are made
Reviews diffs against the phase’s plan and acceptance criteria, leveraging the same context-gathering and web-search sub-agents used during planning.
Checks for regressions and unintended side‑effects
Suggests fixes, improvements, and follow‑up tasks
You stay in the loop: At every stage, you can intervene, adjust, or override. Traycer’s ensemble is there to augment and rationalize each decision alongside the developer.
Design principles behind the ensemble
A few principles guide Traycer’s ensemble:
Use the right model for the right job: Planning, critique, context gathering, and search are different disciplines. We pick models that shine at each.
Keep “thinking” and “gathering” separate: Fast models gather raw material; smarter models think deeply about it. Scouts don’t get to editorialize.
Exploit parallelism everywhere: Fan out tasks (like repo scanning or search) where possible to reduce latency.
Support any implementation agent: By structuring Traycer as an outer‑loop Agent, you can mix and match the implementation agents for each phase based on your preferences and requirements.
Where we’re heading
Over time, we expect Traycer to evolve along two axes: smarter ensembles under the hood and richer planning workflows for whole teams.
On the model/infra side
New specialized models to slot into the ensemble as they emerge.
Better routing and scheduling logic to decide when to call which model, with tighter latency and cost controls.
More powerful verification flows that combine tests, static analysis, and LLM critique into a single, unified review.
On the product/workflow side
Higher‑level planning across collections of specs: Not just one spec at a time, but collections of related specs tied to an initiative, epic, or roadmap. Traycer becomes the focal point for planning, architecture, and tactical work tracking during feature sprints.
Team‑wide collaboration on live specs: Specs as living documents, not static exports. Multiple people in the same Traycer spec at once, leaving comments, suggestions, and edits in real time so that teams can move together while leveraging AI.
