Meta Muse & Coding With GPT-6 Astra + Fable 5.1

Everyone's debating whether GPT-6 Astra or Fable 5.1 is better. Why not use both? Below is the dual-model coding setup that's been absolutely cooking for me, plus my take on Meta's new AI personal assistant, Muse.

Meta Muse: new kid on the block

Meta just launched Muse, an AI personal assistant you can message in the app or directly through WhatsApp.

Here's Meta's official announcement for Muse, its new personal AI agent.

It can book your travel, fill out forms, and make purchases with your saved cards, and it keeps working after you close the app.

Training is opt-out by default, but given Meta's history with user data, I don't think that helps their case much.

The actual product is genuinely good. It can negotiate deals for you on Facebook Marketplace instead of lowballing once and hoping for the best, something other agents struggle with since they don't have native Facebook integration.

Each assistant runs on its own VM (virtual machine) in the cloud, with an extra security layer meant to stop it before it does anything risky.

As a Canadian, I can't try it yet. But would I trust Meta with my data even if I could? Every AI tool carries some data breach risk, but Meta's own engineers have already flagged security concerns.

The individually isolated VMs are a great touch, though, and I think they'll set a new baseline for personal assistants.

---

GPT-6 Astra + Fable 5.1 = world domination

Okay, not literally world domination, that might be a poor choice of words with everything going on right now. But I tried OpenAI's plugin for Claude Code and it's a superpower.

Here's the OpenAI Codex plugin for Claude Code.

I built a skill on top of it that splits work between Fable 5.1 and GPT-6 Astra, playing to each model's strengths. If you liked the Astra vs. Fable showdown, this is the "why not both" answer. Here's how it works:

1. Fable 5.1 plans. It breaks the task down, decides what actually needs to happen and in what order, and basically writes the spec before any code exists.
2. GPT-6 Astra builds. It's just built differently for raw coding output, so it handles the typing while Fable does the thinking.
3. Fable reviews. Once Astra is done, Fable checks the work against its own plan, tests included, before any of it hits my screen.
4. Fable sends it back with the real error. If something's broken, Astra gets the actual error, not a vague "fix it," so it doesn't waste a round guessing.

Basically, two of the world's best models checking each other's work instead of one model grading itself.

The CLAUDE.md block

Add this to your CLAUDE.md after installing the plugin:

# Codex delegation: manager and workers

You are the MANAGER for this task. You plan, set acceptance criteria, make taste and architecture calls, and review everything before it ships. You do not type the implementation yourself for anything non-trivial, that goes to a worker through the Codex plugin, then gets audited before it's used.

1. Decide: delegate or inline
Delegate by default. Handle inline only when the task is trivial (under ~2 tool calls), a judgment call (architecture, naming, prioritization, review verdict), or conversational (explaining, summarizing). Everything else, writing or editing code, running tests, chasing a bug, a multi-file refactor, gets a worker.

2. Route to a model
GPT-6 Astra: the hardest coding. Multi-file refactors, computer-use tasks, anything a cheaper model already failed on twice.
GPT-5.6 Sol: routine builds, tests, debugging, log/repo digging, boilerplate, brief-driven drafts.
Judge the output, not the price tag: if Sol's result misses the acceptance criteria, escalate to Astra without asking permission first.

3. Write the dispatch prompt
Dispatch through /codex:rescue, not the raw CLI. The plugin handles the session, background job, and status tracking for you. Every dispatch needs: the exact files or directories to touch, what "done" looks like in concrete checkable terms, the exact command to run before reporting back, and anything the worker must not do.

/codex:rescue --model <model-id> --background <task: files to touch, what done looks like, commands to run before reporting>

Fix rounds resume the same task, don't re-explain, just give it the new information:

/codex:rescue --resume <exact error text or next chunk of work>

Check progress and pull results with /codex:status and /codex:result.

4. Audit before use
Run the real thing: execute the test suite, hit the endpoint, render the page. A diff that looks plausible can still be broken, only running it counts as verification. Check the diff too, for scope creep or a silently added dependency. On failure, resume with --resume and the exact error text, not a paraphrase. Give a model two honest attempts at a sub-task, if it's still failing on the third, escalate to the next tier up.

5. Rules workers operate under
No silent scope changes: a worker that hits a wrong or impossible step says so and stops, it doesn't improvise. No secrets in prompts or output, ever. Short summaries, not raw dumps: what changed, what was verified, what's still open. Label output by which model produced it. Sandbox the blast radius: narrowest write scope and approval policy the task allows.

6. When this doesn't apply
You're pair-programming interactively and want to type it yourself. The change is destructive or hard to reverse (schema drops, force-pushes, prod deploys), those need explicit human sign-off regardless of model. No repo context exists yet, write a short skeleton first, then delegate the fill-in.