{"slug": "claude-fable-5-1-gpt-6-astra-two-coding-agents-one-workflow", "title": "Claude Fable 5.1 + GPT-6 Astra: Two Coding Agents, One Workflow", "summary": "A developer built OMP Tandem, an open-source bridge that connects a host coding agent such as Claude Code to an independent peer model through the Oh My Pi (OMP) process over MCP and the omp_rpc client. The tool enforces a staged review workflow in which the peer first assesses requirements and captured source material without seeing the author's proposal or rationale, with an optional comparison stage revealing author material only after the independent assessment completes. The developer notes the recorded development case used Claude via the sonnet alias with openai-codex/gpt-6-astra as the peer, not the headline Fable 5.1 pairing.", "body_md": "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.\n\nSo I built **OMP Tandem**: an open-source bridge that gives your coding agent an independent AI peer through [Oh My Pi](https://github.com/can1357/oh-my-pi).\n\nOne 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.\n\nThe 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.\n\n**Explore OMP Tandem on GitHub →**\n\nTandem 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.\n\n*An example configuration, not a fixed model pairing. Host and peer use their own model access.*\n\nThe 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.\n\nFor 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](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/docs/guide.md#install-omp-and-configure-a-provider) explains the separation.\n\n**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.\n\nReview is one entry point, but it is not the whole project.\n\nA 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.\n\nThe two participants do not need to perform identical work. A useful assignment might be:\n\nIndependently 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.\n\nFor implementation, the task can carry constraints, acceptance criteria, and explicit file ownership. Ownership helps coordinate edits; it is not a filesystem security boundary.\n\nCoordinator and peer are roles in a workflow—not a declaration that one model is always smarter.\n\nThe design decision I care about most is **when the peer sees the author's explanation**.\n\nGiving 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.\n\nIn 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.\n\nOnce 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.\n\nThis is implemented in the [review controller](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/src/omp_tandem/review_runs.py), not just requested in a prompt.\n\nIt 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.\n\nAnd disagreement is allowed. The result can be a chosen approach, a concrete experiment, or a clearly stated unresolved question. Agreement alone is not verification.\n\nA review is only useful if you know which code it concerns.\n\nTandem 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.\n\nFor 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.\n\nThat 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.\n\nThe 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.\n\nVersion 3.3.0 adds `tandem_review_run`, a higher-level scenario for this process.\n\nThe 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.\n\nThe 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.\n\nThe scenario is read-only. It does not execute supplied test commands, edit files, or apply its own findings.\n\nThe 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.\n\nSee the [workflow skill](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/skills/tandem/SKILL.md) for the exact behavior.\n\nYou 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.\n\nOn a Homebrew-based setup:\n\n```\nbrew install uv\nbrew install can1357/tap/omp\nomp setup\n```\n\nConfigure 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.\n\nFor **Claude Code**, install the plugin:\n\n```\nclaude plugin marketplace add Flyozzzz/omp-tandem-public\nclaude plugin install omp-tandem@omp-tandem\n```\n\nStart 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.\n\nStage the changes you intend to review, then use `/omp-tandem:tandem` or ask:\n\n```\nUse OMP Tandem to review my prepared commit, using staged changes only.\n\nFirst confirm the project with tandem_scope.\nUse this task's requirements and acceptance criteria; ask if they are missing.\nInclude explicitly needed unchanged callers and tests in the snapshot.\nKeep the author's proposal separate from the independent assessment.\nDo not edit files or run test commands.\n\nShow the findings, supporting evidence, missing context,\nand whether the review still applies to the current staged material.\n```\n\nFor **Codex CLI**, the repository provides its own plugin installation path:\n\n```\ncodex plugin marketplace add Flyozzzz/omp-tandem-public\ncodex plugin add omp-tandem@omp-tandem --json\n```\n\nStart a fresh project session and ask Codex to use Tandem, checking `tandem_scope` before delegation. Other clients can use the [standard local MCP configuration](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/docs/guide.md#other-mcp-clients).\n\nKeep the owning client session open until the task finishes. Persistent history is not the same thing as a detached background service.\n\nThe repository includes a [real development case with machine-readable evidence](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/docs/case-study.md). It contains three recorded review episodes from the development of the new review scenario.\n\nThey are not three clean victories.\n\nThe 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.\n\nThe 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.\n\nThe 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.\n\nBut that expanded review itself timed out. Its available answers were retained; its status was not rewritten as a success because those answers were useful.\n\nAfter 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.\n\nAcross 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.\n\nThis 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.\n\nA useful model answer and a reliable integration are different things to verify.\n\nThe 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.\n\nThat 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.\n\nThe [3.3.0 CI run](https://github.com/Flyozzzz/omp-tandem-public/actions/runs/34459580567) passed on Linux and macOS, including this real-binary check. The [compatibility report](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/docs/compatibility.md) specifies the tested combination and its limits. It does not certify every provider or future OMP version.\n\nThere is also a [four-arm benchmark protocol](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/docs/benchmark.md): 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.\n\nTandem 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.\n\nProject 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.\n\nThere are also limits I do not want to obscure:\n\n`work` is not an OS sandbox.\nThe [security policy](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/SECURITY.md) and [guide](https://github.com/Flyozzzz/omp-tandem-public/blob/v3.3.0/docs/guide.md) describe these boundaries in more detail.\n\nNot 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.\n\nClaude 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.\n\n**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.**\n\nTry 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.\n\n*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](https://www.anthropic.com/claude-fable-and-mythos-5-1) and [OpenAI model guidance](https://developers.openai.com/api/docs/guides/latest-model) provide provider-side context. Diagrams are explanatory illustrations, not product screenshots.*", "url": "https://wpnews.pro/news/claude-fable-5-1-gpt-6-astra-two-coding-agents-one-workflow", "canonical_source": "https://dev.to/denisbabkevich/claude-fable-51-gpt-6-astra-two-coding-agents-one-workflow-1g75", "published_at": "2026-09-10 10:15:46+00:00", "updated_at": "2026-09-10 10:28:21.071191+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "large-language-models", "ai-products"], "entities": ["OMP Tandem", "Oh My Pi", "Claude Code", "Claude Fable 5.1", "GPT-6 Astra", "Codex CLI", "MCP", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/claude-fable-5-1-gpt-6-astra-two-coding-agents-one-workflow", "markdown": "https://wpnews.pro/news/claude-fable-5-1-gpt-6-astra-two-coding-agents-one-workflow.md", "text": "https://wpnews.pro/news/claude-fable-5-1-gpt-6-astra-two-coding-agents-one-workflow.txt", "jsonld": "https://wpnews.pro/news/claude-fable-5-1-gpt-6-astra-two-coding-agents-one-workflow.jsonld"}}