After using Codex to implement a change, I once decided not to reread the entire result myself. Instead, I handed the repository to another AI and asked it to review the work independently.
The idea was simple: do not trust the implementation context that Codex had accumulated. Let Antigravity read the repository as if it were coming in cold, reconstruct the architecture, and challenge the result from a different perspective.
I expected this to become a comparison of which tool was better. What I found more useful was something else.
I wanted the two systems to do different jobs.
Codex was already carrying the change history, test results, recent failures, and the bounded scope of the implementation. It naturally behaved like a Builder. Antigravity was more useful when it stepped away from that continuity, read across the repository, rebuilt relationships between files, and asked whether the Builder’s assumptions were actually supported by evidence.
Why should one model perform every job in a coding mission from beginning to end?
This is not a Codex-versus-Antigravity benchmark. It is a practical pattern for decomposing one implementation mission into different forms of cognitive work, then assigning enough model capability — and enough reasoning budget — to each role.
Codex as Builder, Antigravity as Auditor
In my workflow, Codex fit naturally into work where the contract was already bounded.
It could verify the current branch and SHA, read the existing implementation, make an incremental change, run tests, and repair a failure without losing the context that led to the change. The value was not one brilliant answer. It was continuity while converging an agreed architecture into code and tests.
I initially gave Antigravity a different job. Instead of inheriting the same implementation narrative, it was asked to explore an unfamiliar snapshot, reconstruct architecture across files, collect evidence, and audit the result independently.
- Codex: Builder — context continuity, bounded implementation, test/repair loops
- Antigravity: Investigator / Auditor — cold-start exploration, architecture reconstruction, independent review
But the first audit exposed an important flaw. Using a different AI does not automatically create an independent review.
The audit was read-only, but the evidence was contaminated
The first audit had explicit constraints: read only, fixed baseline SHA, no branch switching, and no mutation. Even so, some parallel investigation paths appeared to read the current worktree. Later implementation details were reported as if they already existed in the historical baseline.
Model independence is not the same as evidence independence.
A different model family is still not an independent verifier if both systems can see the same contaminated evidence universe.
So the next audit did not rely on a longer prompt. I reduced the evidence universe itself.
frozen SHA → git archive → isolated snapshot → remove .git → filesystem read-only → audit
At that point, the auditor could no longer accidentally inspect the current branch. Before splitting roles between models, I need to define which evidence each role is allowed to see.
One Coding Task Is Not One Job
A request such as “implement this execution boundary in the FastAPI runtime” looks like one coding task. In practice, finishing it requires several different forms of work.
Someone has to understand the repository, recover the current architecture, identify the canonical contract, plan the change, implement it, investigate failing tests, repair the implementation, audit for structural regressions, judge the severity of findings, and decide whether the result is acceptable.
| Role | Main work | Useful property | Example placement |
|---|---|---|---|
| Investigator | repository exploration, architecture reconstruction | broad context, high-volume reading | cost-efficient Antigravity tier |
| Planner | contract boundary, change scope, root-cause hypothesis | deeper reasoning when ambiguity is high | stronger model only when needed |
| Builder | bounded implementation, tests, repair loops | context continuity, execution discipline | Codex |
| Auditor | independent review, assumption challenge | a different context and evidence perspective | Antigravity |
| Verifier | severity, disputed findings, acceptance | high reasoning value on selected high-risk cases | stronger or different-family model |
The product names are not the main point. The important observation is that one coding task is often a bundle of different intelligence workloads.
Reading a large repository is not the same job as judging a risky state transition. Continuing a repair loop with accumulated implementation context is not the same job as challenging the assumptions of the person — or agent — that built it.
Cost Optimization Started With Role Separation, Not With a Cheaper Model
Multi-model cost optimization is often framed as sending the same request to a cheaper model. In my workflow, the more interesting opportunity was different.
Reduce the percentage of work that needs expensive reasoning at all.
Repository-wide exploration can consume a lot of tokens, but it does not always need the most expensive reasoning model. A tiny code change, on the other hand, may deserve stronger reasoning or independent verification if it affects idempotency, replay, backward compatibility, or an external mutation boundary.
That makes a simple rule such as easy → cheap, hard → expensive too weak.
- What job is being performed?
- What state and policy does the application already know?
- What is the cost of being wrong?
- Is stronger reasoning likely to produce meaningful marginal value?
- Does the result need an independent perspective?
This connects naturally with routing and cascade research. RouteLLM treats the choice between stronger and weaker LLMs as a learned routing problem using preference data. The useful lesson for me is not a specific benchmark number; it is that the router itself becomes a system that must be evaluated and calibrated.
FrugalGPT explores a different pattern: start with cheaper options and escalate through an LLM cascade when necessary. Its reported numbers belong to the models and conditions of that study, but the architectural idea remains useful — not every request needs the most expensive model from the start.
In a coding workflow, I find that idea even more natural when applied to roles, not just to prompts.
Who Should Assign the Roles?
Once multiple models are available, another temptation appears. Why not put one more LLM in front of everything and ask it, “Should this go to Codex or Antigravity?”
Microsoft Foundry Model Router, for example, analyzes the full request, including system messages, tools, and conversation history, and chooses a model according to routing modes such as Balanced, Cost, or Quality. Microsoft’s own guidance also notes that managed routing does not eliminate the need to evaluate it against a meaningful workload baseline.
AWS Bedrock Intelligent Prompt Routing similarly routes within a model family by predicting response quality and balancing quality with cost.
That kind of generic router is attractive when requests are open-ended and the application knows little in advance. My coding workflow is different because much of the routing signal already exists as application state.
job.type = implementation, stage = audit, mutation = none, independent_verification = required, or retry_count = 1 are not facts that need semantic inference. They are deterministic state.
Asking another LLM to rediscover those facts from a prompt does not necessarily make the system smarter. It can make the control plane less transparent.
First consume everything the application already knows. Use AI only for the narrow semantic ambiguity that remains.
JEV as a Coding Job Classifier
This is where my earlier work with JEV became relevant again. In the previous article, the interesting result was that JEV and a general LLM could reach the same bounded classification while requiring different engineering surfaces. The part I reuse here is not the 17-case benchmark. It is the bounded decision harness abstraction.
- Does this task require repository-wide exploration? YES / NO
- Is the implementation already bounded by an existing contract? YES / NO
- Is independent verification required? YES / NO
- Is the cost of a wrong judgment high? YES / NO
- Is stronger reasoning likely to add material value? YES / NO
The goal is not to let JEV directly invoke Codex or Antigravity.
A decision model can produce a typed signal such as BOUNDED_IMPLEMENTATION, REPOSITORY_INVESTIGATION, INDEPENDENT_AUDIT, or HIGH_RISK_VERIFICATION. The deterministic runtime then decides which worker, model tier, permissions, snapshot, timeout, and mutation policy to use.
Task Facts → Deterministic Rules → Bounded Semantic Decision → Job Class → Deterministic Dispatch
- bounded implementation → Codex Builder
- repository-wide investigation → Antigravity Investigator
- independent audit → a different context or model family
- disputed high-risk finding → stronger verifier
Routing signal is not routing authority.
A model may judge that a task looks like repository-wide investigation. It should not automatically own which snapshot is readable, which runtime is called, which model tier is permitted, whether mutation is allowed, or how retries and timeouts behave.
Two Models Do Not Automatically Make the Result Safer
A multi-model design can easily turn into a comforting but weak claim: “If two AIs check each other, it must be safer.” My experience did not support that shortcut.
Antigravity was useful at architecture reconstruction and cross-file evidence collection, but that did not make every severity judgment canonical. A model can overstate a finding, and two different models can still agree for the wrong reason if their evidence is wrong.
So the acceptance chain I trust is closer to:
Agent Finding → Evidence → Git / Tests / DB / Runtime State → Verifier if needed → Human Acceptance
not: AI A agrees with AI B → TRUE
This is what makes a multi-model harness a responsibility design rather than simply a larger collection of agents.
Look for a Sufficient Model, Not a Universal Best Model
Using Codex and Antigravity together changed the way I think about model selection.
I used to start with the question: which model is strongest for this coding task? Now I start with a different one:
What capability does this stage actually require, and how much is enough?
An Investigator may benefit from broad and inexpensive reading. A Builder may benefit more from preserving implementation context and staying disciplined inside a bounded contract. An Auditor needs a perspective that is not trapped by the Builder’s assumptions. A Verifier may justify expensive reasoning only for a small subset of disputed, high-risk decisions.
The specific models can change while the roles survive. Codex or Antigravity may eventually be replaced by other tools, but the workload contracts — Builder, Investigator, Auditor, Verifier — remain useful.
That looks like a more durable asset than a hard-coded model-selection table.
Reduce the Moments That Need Expensive Intelligence
I started using Antigravity because I wanted a second, more objective look at work produced through Codex. The more useful lesson was not that one tool was better than the other.
It was that there was no reason to ask both tools to do the same job.
One implementation mission can be decomposed into repository exploration, planning, implementation, repair, audit, and verification. Deterministic state and policy can resolve what is already known. A bounded decision harness can classify the narrow semantic cases that remain. Stronger reasoning can be reserved for the moments where it is likely to change the outcome.
Multi-model coding is about deciding which jobs exist inside the mission and how much intelligence is sufficient for each one.
In practice, the most effective way to save on frontier capability may not be to make the strongest model slightly cheaper. It may be to reduce the number of moments when the strongest model is needed at all.