Claude Fable 5.1 + GPT-6 Astra: Two Coding Agents, One Workflow

A coding agent can write a patch, explain why it is correct, and then review its own work. What I wanted was a second agent that could investigate the same problem before seeing the first agent's explanation—and then challenge it with evidence.

So I built OMP Tandem: an open-source bridge that gives your coding agent an independent AI peer through Oh My Pi.

One example pairing is Claude Fable 5.1 in Claude Code, with GPT-6 Astra as the OMP peer. You keep the coding environment you already use, configure the second model separately, and bring both into the same workflow.

The point is not to make two models agree. It is to make their collaboration useful: clearer decisions before implementation, independent checks afterward, and a record of what was actually reviewed.

Explore OMP Tandem on GitHub →

Two agents, without two disconnected workflows

Tandem connects a host coding agent to a real Oh My Pi process over MCP and the official omp_rpc client. It is not a direct model-API wrapper pretending to be a coding agent.

An example configuration, not a fixed model pairing. Host and peer use their own model access.

The host can be Claude Code, Codex CLI, or another supported local MCP client. The peer uses a tool-capable model configured in OMP. The host model and the peer model are separate choices.

For the Fable 5.1 + Astra example, select Fable in Claude Code and configure Astra in OMP. Availability depends on your accounts, provider access, and installed client support; Tandem does not bundle model access or bypass provider policies. The setup guide explains the separation.

A detail worth making explicit: the recorded development case later in this post used Claude through the sonnet alias, with openai-codex/gpt-6-astra as the peer—not Fable 5.1. The headline pairing is a configuration example, not the model combination measured in that case.

Collaboration starts before the patch

Review is one entry point, but it is not the whole project.

A peer can challenge an architectural assumption before implementation, investigate a suspicious code path while the coordinator checks another, or implement a separately authorized slice of an agreed plan. Conversations persist, so a follow-up can replace the current objective without throwing away the native OMP history.

The two participants do not need to perform identical work. A useful assignment might be:

Independently examine the retry and cancellation design. I will inspect the API contract. Identify failure modes, cite the relevant code, and tell me what evidence would distinguish competing explanations.

For implementation, the task can carry constraints, acceptance criteria, and explicit file ownership. Ownership helps coordinate edits; it is not a filesystem security boundary.

Coordinator and peer are roles in a workflow—not a declaration that one model is always smarter.

Independent first. Comparison second.

The design decision I care about most is when the peer sees the author's explanation.

Giving a reviewer the proposed solution and all its supporting arguments upfront is a different task from asking it to form its own assessment. Tandem makes that distinction explicit.

In the saved-snapshot review workflow, the peer first receives the requirements, criteria, and captured source material. The author's proposal and rationale are stored separately and are not exposed during that independent stage.

Once the independent assessment has completed successfully, an optional comparison stage reveals the author material for the same snapshot. No author material means no comparison stage. Blocked or partial independent work does not automatically advance.

This is implemented in the review controller, not just requested in a prompt.

It is not absolute blindness: code, tests, and requirements can reveal intent. The narrower guarantee is about the order in which the explicit author material becomes available.

And disagreement is allowed. The result can be a chosen approach, a concrete experiment, or a clearly stated unresolved question. Agreement alone is not verification.

Review the version you are actually shipping

A review is only useful if you know which code it concerns.

Tandem supports two sources: worktree for working changes, and staged for the prepared commit. It saves the selected material and associates the review with that snapshot rather than silently following the live files.

For a staged review, unstaged edits do not get mixed into the assessment. Changes to the captured index material can make the saved review stale. Files outside the captured scope are not implicitly covered.

That last part matters. An unchanged caller or test may be essential to understanding a change. You can include those files explicitly as context. When the reviewer identifies missing source, the next step is a fresh, expanded capture, not adding live files to an old review and pretending it was always complete.

The output tells you what was reviewed and whether it still applies. It does not turn a review of selected files into a claim about the entire repository.

One review scenario, not a protocol to memorize

Version 3.3.0 adds tandem_review_run, a higher-level scenario for this process.

The runtime handles capture, the independent stage, the optional single comparison, and full-answer assembly. The host still reads the result and handles clarification, but it no longer has to reconstruct every low-level transition itself.

The default 600-second total budget covers capture, startup, both stages, and questions. It is not a fresh ten-minute allowance per stage, and it is not a promise that every review will finish within that time.

The scenario is read-only. It does not execute supplied test commands, edit files, or apply its own findings.

The broader development workflow also keeps planning proportional to uncertainty. A known local fix needs a brief independent risk check and a small plan—not a new audit of the entire project. An ambiguous architectural change deserves a deeper comparison. The normal discussion limit is one independent assessment and one comparison, rather than continuing until the agents agree.

See the workflow skill for the exact behavior.

Try it on your next prepared commit

You need macOS or Linux, or WSL with Linux-installed tools, plus a configured host coding agent. Tandem requires Python 3.12 or newer; uv prepares the Python environment.

On a Homebrew-based setup:

brew install uv
brew install can1357/tap/omp
omp setup

Configure your OMP provider and select a tool-capable model. Its authentication is separate from the host agent's authentication. A harmless request directly in OMP is a useful way to confirm that the provider connection actually works.

For Claude Code, install the plugin:

claude plugin marketplace add Flyozzzz/omp-tandem-public
claude plugin install omp-tandem@omp-tandem

Start a new session from your project directory. Run /omp-tandem:setup and ask for local diagnosis only. That checks configuration without making a model request; live provider diagnosis is a separate, explicitly approved step.

Stage the changes you intend to review, then use /omp-tandem:tandem or ask:

Use OMP Tandem to review my prepared commit, using staged changes only.

First confirm the project with tandem_scope.
Use this task's requirements and acceptance criteria; ask if they are missing.
Include explicitly needed unchanged callers and tests in the snapshot.
Keep the author's proposal separate from the independent assessment.
Do not edit files or run test commands.

Show the findings, supporting evidence, missing context,
and whether the review still applies to the current staged material.

For Codex CLI, the repository provides its own plugin installation path:

codex plugin marketplace add Flyozzzz/omp-tandem-public
codex plugin add omp-tandem@omp-tandem --json

Start a fresh project session and ask Codex to use Tandem, checking tandem_scope before delegation. Other clients can use the standard local MCP configuration.

Keep the owning client session open until the task finishes. Persistent history is not the same thing as a detached background service.

I used Tandem to review Tandem

The repository includes a real development case with machine-readable evidence. It contains three recorded review episodes from the development of the new review scenario.

They are not three clean victories.

The first review lacked source context. The peer asked for the missing files, and the coordinator cancelled rather than inventing an answer or silently expanding the old snapshot.

The expanded review found a concrete defect: synchronous snapshot capture held a controller-wide guard without being governed by the total deadline or cancellation control. A slow capture could delay another run's cancellation, and a late empty capture could return no_changes after the budget had expired.

The coordinator then reproduced the original defect locally. In a deliberately short internal regression test, a one-second budget returned no_changes after 2.745 seconds. The report had become something testable.

But that expanded review itself timed out. Its available answers were retained; its status was not rewritten as a success because those answers were useful.

After the first fix, a focused independent recheck completed and identified a different risk: SQLite publication locking could still interfere with cancellation. That episode provided a static finding, not a timing reproduction. A separate runtime follow-up subsequently reproduced the interaction, fixed it, and passed the retained regressions.

Across the three recorded episodes, the measured wall time was 598.408 seconds. The known cost subtotal was $5.6829274, counting the recorded coordinator and peer usage. The complete cost is unknown because part of the peer accounting was missing. These are reported estimates, not invoices; development, repairs, local checks, and human preparation were outside that recording.

This case does not establish that Tandem beats a single agent. It shows the actual integration producing a missing-context question, useful findings, a reproducible defect, and a follow-up challenge to a fix—with failures preserved in the record.

Test the runtime separately from the models

A useful model answer and a reliable integration are different things to verify.

The repository now includes a compatibility check using the actual pinned OMP 18.1.13 binary and official RPC SDK, with deterministic model replies served from localhost. The OMP process, tool dispatch, session continuation, and cancellation are real; only the model responses are scripted.

That makes it possible to check important boundaries without a paid model account: whether read-only modes reject mutation tools, whether work mode can exercise the expected native tools in a temporary project, whether a structured result reaches the host, and whether cancellation works while a response is pending.

The 3.3.0 CI run passed on Linux and macOS, including this real-binary check. The compatibility report specifies the tested combination and its limits. It does not certify every provider or future OMP version.

There is also a four-arm benchmark protocol: one agent, self-review, a conventional peer handoff, and Tandem's independent-first process. Comparative results have not been published. A protocol is not a leaderboard.

The boundaries are part of the design

Tandem separates consultation (think), read-oriented investigation (analyze), and explicitly authorized implementation (work). Saved-snapshot reviews use their own snapshot-bound reader rather than live project tools.

Project histories and artifacts are scoped using trusted client workspace information, not a project path invented in a model's task arguments. Cross-project knowledge transfer is explicit.

There are also limits I do not want to obscure:

• work is not an OS sandbox. An external OMP process does not automatically inherit the host agent's shell sandbox restrictions.
• Local storage is not offline inference. Your configured providers receive the task context, and model usage is separate from the MIT-licensed software.
• A finished report is not proof of correct code. Important findings and fixes still need evidence and verification.

The security policy and guide describe these boundaries in more detail.

What I want this to make easier

Not every edit needs a second agent. The workflow is aimed at moments when another independent assessment could change the decision: an ambiguous design, a difficult bug, a risky refactor, or a prepared commit you want challenged before merging.

Claude Fable 5.1 + GPT-6 Astra is one way to configure it. The lasting idea is the workflow around the models: independent assessment, explicit comparison, version-bound evidence, and a human who can see what remains uncertain.

I am not trying to build a room full of agents that agree. I am building a way for one coding agent to get a second opinion worth reading.

Try OMP Tandem →

Try it on a change you know well and share what the independent peer caught—or what it missed—in the repository. That feedback is more useful than an impressive-looking agent transcript.

---

This post describes OMP Tandem 3.3.0 at commit 5f1136b. The repository is MIT-licensed. Model availability and client behavior can change; the official Fable 5.1 announcement and OpenAI model guidance provide provider-side context. Diagrams are explanatory illustrations, not product screenshots.

Comments

[Baptiste Le Bouquin]

The independent-peer-before-review design is the strongest part — having the second model investigate the problem before seeing the first agent's explanation gives you an honest cross-check instead of a rubber stamp. The ordering matters more than which two models are paired; once the peer has seen the patch's reasoning, its review degrades toward agreement.

What I'd want to know as a user: how do you surface disagreement that neither model can resolve? With two independent agents you get a genuine conflict signal, and the real question is when that escalates to a human rather than letting the host pick a side. Do you have an explicit heuristic for when the peer's counter-evidence becomes a hard stop, or is it always left to the operator?