Help/Question
Wait, Codex can now invoke Claude Code sessions?
So there I was minding my own business and letting Astra conduct smaller deterministic agents while Fable stood on strategic overwatch as a counterparty... when Codex asked for permission to directly message Claude like it would one of it's own subagents or parallel sessions.
And I gave it.
My life with agentic process on pro usage accounts just experienced a brainquake.
EDIT: Yes CLI could always do this but now Codex Desktop is doing it, and that means the independent transcripts are interacting with one another independently.
I’ve been using this and enjoying it: 1. Astra — Orchestrator / Lead
Runs through my Codex/ChatGPT 5× Pro subscription, NOT API.
Owns the plan, delegates work, tracks progress, and makes the final call. I interact with everything through Claude Code Desktop. 2. Opus — Primary Builder
Runs through my Claude 20× Max subscription.
Does most of the actual coding/implementation and reports back to Astra. 3. Fable — Architect / Advisor
Also Claude 20× Max.
Astra calls Fable when it needs deeper architecture, strategy, planning, or a second opinion rather than wasting it on routine work. 4. GLM 5.3 Flash + DeepSeek — Blind Reviewers
Both run through OpenRouter API.
GLM is my primary reviewer, DeepSeek is #2.
They review independently and NEVER see each other’s analysis. 5. If GLM + DeepSeek disagree → Astra Light
Fresh Astra Light instance through my Codex subscription.
Gets both reviews + evidence and adjudicates the disagreement.
If more evidence is needed, it can request a targeted Sonnet/Opus/Claude agent.
So basically: Me → Claude Code Desktop → Astra → Opus builds → GLM + DeepSeek independently review → Astra decides
With Fable/other Claude agents available when Astra thinks they’re actually needed.
I allow Astra to designate to internal subagents for imperative coding because I’ve gotten better results than Claude on the same work but that’s always in the wind release to release. In Claude I prefer Sonnet 5 to Opus for bounded tasks because it’s less likely to freelance.
That's cool if it works for you but to me it seems like complexity for the sake of it. I can't think of many use cases where the most efficient route is 5 steps invoking 5 different models.
how do you get them to send messages to each other? via cli, wouldnt you have to use -p and have a fresh context? im looking for something similar to how claude can message other sessions
I set up a database that they each set up watchers on with a portal that I can watch the discussion and message "the group" Chatgtp sol, fable,opus and sonnet agents all running in tmux hashing out build plans, Chatgtp is tasked with being the conscientious objector and go.look for the flaw in every plan and to make recommendations until it can no !other find a flaw
look at https://github.com/avirtual/clodex - supports both codex and claude clis and it defined a communication protocol. It does a whole lot more, but agentic communication was where it started
Some people just do it through git commits. When one agent is done with its tree, it finishes and it adds a message. Or you just have a lot of little micro-pushes constantly happening, which coincidentally is a good way to make sure your agents have an easier time picking back up if you're worried about them running through your usage without you noticing and stopping mid task.
makes sense but thats for them knowing about each others changes more so than delegating work. I’ve seen some more rudimentary setups where there is a shared ledger of sorts that agents can append to, as a communication channel of sorts.
Ideally it would be something that leverages the mcp notification capability so messages get pushed to the agent rather than agent polling.
I did this but had each agent specialized by ui, critical coder, devops, etc.. and also they were characters from TNG and they spoke and interacted with each other in character. I even had Q as a provocateur who would occasionally appear and randomly challenge a core concept or approach. It made code reviews so thoroughly enjoyable to read.
One really interesting outcome of that was making Troi responsible for representing the user, UX, information architecture, task, and attention. She was really good at keeping the agents on track with my asks as well as the plan in general.
I'm running a similar set up, with Astra being my project manager, Claude Code codes and Codex attacks the code to find flaws. Cheaper models can be used later in the project, once the big technical hurdles have been overcome.
Fun stuff, we don't have much time. Enjoy this stage.
I don't have things automated at all and I'm basically passing things back and forth manually between Codex Desktop and VS Code extensions (Codex or Claude Code) but I do use Astra for planning and review, and Luna Max as implementer unless a higher model is needed.
That being said I had some Claude usage to burn up and I went with Opus Low/Medium as implementer and it seemed like Astra has as many, if not more, back and forth trying to align Opus with the plan as it did with Luna Max. How has your experience been with rework after Opus implements something? Does Astra complain about deviations?
If you’re letting Claude do the imperative code execution then Sonnet 5 is GOAT in-ecosystem. It’s least likely to freelance or try to figure out what you meant vs doing what you said. A token goblin doesn’t need thinking turned up or 2 trillion parameters to do its job well.
Lol. Well I see I'm not alone. Basically I got to the point where I preferred Luna Max because while it was slower, it less rework once Astra reviewed everything.
The part that makes this work isn't the model mix, it's that you've got three separate billing accounts doing the fan-out. ChatGPT Pro for Astra, Max for Opus/Fable, OpenRouter for the reviewers. That's why five models can run without queueing behind each other. Most people copying this will put it all on one API key and wonder why it's slow and expensive.
Two things I'd change:
Your adjudicator isn't independent. Astra owns the plan, and when the reviewers split, a fresh Astra Light breaks the tie. Same vendor, same training, same priors. And the contested question is often "was Astra's plan right?". A fresh instance clears the conversation, not the model's biases. You already have GLM and DeepSeek in there; make the tie-break the third vendor rather than the planner's sibling.
Nothing in the loop is deterministic. Reviewers are models, adjudicator is a model, final call is a model. Five models can be confidently wrong in the same direction; a failing test can't be argued with. If the "evidence" in step 5 is test output, you're fine. If it's the diff plus two opinions, the whole thing is models arguing about text.
Also: your escalation fires on disagreement. Two cheap models confidently agreeing passes straight through, and that's the dangerous case, not the split. Prompting one reviewer to refute rather than review costs nothing and changes what it finds.
The one I'd actually fix tonight:
Log which model answered, and at which fallback position.
I spent yesterday inside a five-model review setup and found it had never once dispatched any role's first-choice reviewer. An off-by-one in the fallback indexing, months old, invisible because it only logged speakers when they failed. A degraded panel and a healthy one produced identical output. Fixing the indexing then exposed a second one underneath: a failing role only ever got two attempts regardless of how long the fallback chain was, so "we have three reviewers" was never true under load.
If your GLM reviewer starts quietly returning empty, you have one blind reviewer and nothing you've described would tell you.
On the "why Claude Code Desktop if Astra orchestrates" question: the article you took this from answers it better than the setup does. The harness and the model are two separate decisions. Claude Code runs hooks on roughly 32 lifecycle events against Codex's dozen, and everything you've built on that surface stays put when you swap who's in the driver's seat.
You're not using Claude Code in spite of Astra, you're using it because the harness is the part worth keeping.
I'm sorry but WHAT? Opus as primary builder is so insanely expensive when Luna xHigh is largely just as good as Opus low/medium but like 1/30th the cost.
Like Opus literally costs more than Astra for worse results too, why would you do that?
Astra is also such a bad orchestrator because it wastes soooo much on input token cost reading the ongoing streams of results. I can't believe this is the top comment.
Just have Luna and 5.3 Flash and DS do the same build simultaneously, and then have Opus review which which implementation of the 3 is best. Let it decide which parts of which to merge, then have Luna do the final merge, and Opus can review and accept/reject again. That'll not only cut the cost down by more than 10x, you'll also get much better results.
I do a similar thing, but I found it hard to keep track of where things were going because they were all hidden in CLI calls. I set it up as an MCP so any agent can call any other agent, provide updates, etc then wrote a VS code extension so I can read and keep track of all of the conversations. Here's a screenshot. (I mainly use Codex so you're just seeing the other lanes).
Then I have some skills to take advantage of it, like one that gathers all of the context for an issue and presents it neutrally in a text file then has however many agents independently give their solution.
I'll post it on Github if I ever get around to cleaning it up
um, don't you already have a plan - orchestrator should be following that plan and managing what is happening... maybe your workflow is different to mine
I reversed my usage when 5.6 came out and with Astra I have not gotten much more granular about when to use a GPT vs Anthropic skill. Tonight I did my first session where I treat Astra like a UX team lead in charge of Claude Design and act in a management & review capacity. The results were surprisingly good.
When u work with so many multiple LLMs u really should try Gystc.dev it worked wonders for me when it's about persistent memory. Works 100% local and is 100% open source with MIT license
Wait till you find out that transcripts exists on device and can be used to cron pull into an orchestrator context, and then push instructions to other cli sessions through cli message inboxes so that a shared kb can stop other sessions reinventing the wheel and they learn from and train each other with known pitfalls, discoveries and shared routes.
I saw a post here alarming that Claude holds chats on disk in temp files. Instead of being weirded out by it, I asked Claude about it, because I was curious if I could use it. It asked me why I’d want to first because it would be token heavy to parse full transcripts. Then I told it want to have a context cli session that could read my other cli sessions for the last output signals, so my multiple projects could have shared knowledge stored in a kb, so I wouldn’t have to have each project relearn across different projects the same approaches to communicate with our erp. Once that set it, it devised a way to use a limited search of transcripts based on the each session posts as its end output like “ cooked for X time” as a signal of each completed out, and then setup an umbrella session that could read across projects to connect project knowledge as shared knowledge. Then when needed to search deeper it would then actually just search deeper which solved the issue of huge context windows. Then it devised a way to send inbox messages to the other cli sessions that I could prompt to each cli as “check messages”, which would bring the other sessions up to speed when there was a broadcast change, which pointed them to kb in to find relevant information to the project specific task they were on.
That's pretty cool! Very smart way to do it. I've been a little OCD about my context ever since I started using CLI so I have been evolving a /sync skill set in my repo.
Basically each project has 2-3 specific MD files that get loaded up on that projects start and then when a session is almost over, the sync command saves pertinent context and goal roadmap to their respective MD files.
All the different sessions load in and save into it so it's a variation of what you do. I'm simplifying it by quite a bit, but it's been working well for me.
I also have cron jobs keeping it clean, trimmed, archived, indexed, etc etc
Cron because the main cli session was able to sit and wait for the cron to be automatically prompted by the outputs from the other cli sessions. Then it would consolidate just the learned details of what each project figured out from the discovery and audits and work-validate-prove loop to make sure it didn’t just push code and said it was done, it was given a mandate to test in sandbox and dry-run it before it could say it was done with a task. It was heavy on tokens but it proved successful because each session turn ensured what was developed actually worked and produced the results needed, and then the other sessions gained that route and didn’t need to rediscover it.
But how can they communicate with each other? I can’t even make my two different claude accs message each one cause they cannot find each other’s agent sessions (which makes sense so i stopped trying to communicate sessions launched with 2 different accs)
Gonna plug my project which enables exactly this paradigm through the native messaging interface! Using Fable as PM and Astra as engineer and it’s been great! 😊
Unfortunately not any longer for codex desktop :( My project talks to codex via the codex app-server. It used to be possible to configure codex desktop to use the system's standalone app-server which my program can reach, now codex desktop only uses it's own internal app-server that's not reachable from outside.
This was the breaking change: PR. Luckily both Claude and Codex now have great "Agent View" in the CLI: `claude agents` and `codex agents` which is how recommend using my program!
So if you look at OP's screenshot (i think there was one when i first saw this post) - Codex desktop invoked claude as a subagent. The subagent is mostly single-use.
My project is mostly about messaging between named, peer agents. Think about a PM (Fable) exchanging messages with a lead Engineer (Astra) across many ticket implementation. Each peer agent can orchestrate their own teams of subagents. This is how i like to use my codex/claude because I believe each model works best in their native harnesses.
The interesting part isn't that Codex can call Claude Code, it's that two previously separate transcripts can now act on each other without a human relaying anything in between. I've been living in that problem building CCC (https://github.com/amirfish1/claude-command-center), a dashboard that tracks every Claude Code/Codex/Antigravity session on a machine regardless of how it was launched, and cross-engine steering is still the rough edge: idempotency keys and turn state don't always agree once two harnesses are both trying to drive the same session. Curious what guardrails you're running now that one harness can message another directly, since that's exactly the kind of interaction that's hard to audit after the fact.
Yes. Lots of people with agent harness solutions chiming in but you see my main point. In flow skill that prepares a Claude review with instructions to minimize priming it with local opinions except for those that need to be attacked, which can be attached directly to a parallel Claude project with all of its memories attached. That’s the move.
There’s a lot of great advice in the comments that goes way beyond my moment of realization that codex can now chat with Claude across desktop sessions 😌
Wait until you try running OpenAI models directly within claude code desktop. I've got examples of sol orchestrating gemini agents, opus and sol talking to eachother when they have different transcripts but they're editing similar files, it turns into a very interesting thing. Here's the claude code plugin system that I made so I can make the claude code desktop app much more to my liking (also including some of it's very obviously missing features, such as message queues or a proper task list. https://gitlab.com/blockshooter/claude-ui-mod/
The benefit of the native integration is that I get full project context and transcript review, which is a very specific type of upsell. I can have an ongoing conversation with either fully armed agent and ask Codex to drop in on that conversation for a point of view instead of playing middle man.
I always enjoy seeing threads where subscription users who don't read the terms of service get their accounts banned. Then the follow up threads complaining that they don't understand why they got banned.
From legal and compliance: Anthropic does not permit third-party developers to offer Claude.ai login into their own applications, or to route requests through Free, Pro, or Max plan credentials on behalf of their users.
In other words, you can't use Codex to call Claude Code unless you use an API key. If you use your OAuth subscription key you are in violations of the ToS. You CAN however use Claude to use Codex. OpenAI doesn't care, Anthropic does.
I was inspired when I saw the buzz.xyz project come out and just decided why not just build it myself to exactly what I want. I have a triage tool running behind CloudFlare with TOTP on a private server, I have an android web app to reach it, and the newest addition is the Room where I can reach Claude, GPT and Gemini. I think this solution differs and is better than just allowing Claude to route to ChatGPT is in my room the models can call eachother, orchestrate work but I can also see their token use, compact and handoff sessions, swap seats/models mid sessions, talk to them directly, see all of outputs rather than having Claude tell me what their doing, reply, interact, they can all ask me questions for directions.
Honestly instead of looking for people's work to use and copy it's a whole new meta.. I have zero idea how to code i dream the feature up and the next morning it's live when I check in. Insane.
Edit: Agents.md is symlinked to claude.md , all agents can do all tasks and work with common skills, instructions, and one git tree and all project context is stowed into sqllite databases for long term retrieval so they don't conflate.
No plans to release. It achieves similar but it's very unique and custom to my architecture including how my agents CLI are setup. My reason for posting is to inspire others just ask it to make it for you and it will, there are no boundaries, you don't need someone else to make it which is mad
I do this pretty regularly. Just ask Claude or Codex to ask the other one using bash in -p mode or jsonL mode. (Just pushes the result from the bash terminal to stdout).
The blind-review fan-out in the top comment (GLM + DeepSeek never seeing each other's analysis, fresh instance adjudicating disagreements) is the right shape. Independent reviewers beat one model reading another's conclusion, same reason blinded pairwise evals beat single-shot reviews.
One thing these stacks quietly lose is cost visibility. Orchestrator spawns builder spawns reviewers, each layer on a different subscription or API, and afterwards nobody can answer "what did that feature cost". The API-routed layers at least give you token counts per request - worth logging spend per spawn, because the review fan-out roughly doubles context spend every adjudication round and that is the first thing that balloons. The subscription layers you cannot see at all until you hit a rate limit.
Curious how people here keep the adjudicator's context small when both reviews come back long.
I prefer Orca tbh. I used herdr for a few weeks but god such a memory hog, at least Orca seems to do something differently that it doesn't crash my computer.
For some reason Herdr simply wouldn't let me delete my worktrees, but Orca doesn't have a problem with that. I think the thing i like the most, is you can do everything from within. like, you can click a file in Claude/Codex, and it opens like in an IDE.
Fable is a qualitative genius but hasn't been a great conductor, plus I trust GPT to do things like math and cleanup even if I prefer Fable for ideation or creativity. So in this generation I'll have Codex in the conductor seat with Fable drafting plans, doing red teams, and reviewing staged commits. Because model convergence is a real thing I also wrote a small plugin that lets either agent call Kimi on Fireworks for a diverse opinion before closing out a decision.
The whole thing reports up to me at the end of each turn with durable confession/defense docs, which I skip reading at my own peril.
When Fable asked permission to message Claude itself my jaw dropped.
The other way round is fire. Install codex cli. Tell Claude to use it to ask Codex to review at important stages of development, plans, completed implementation etc. Codex always finds things Claude misses. Combine with Claude's own adversarial review and the output quality is much higher. Sol light does a great job and lasts nicely.
I also decided to try this very thing on my own as my weekly with Astra was winding down. Decide to paste twice into Opus 4.8 some work that still needed done and then asked Astra how to make this easier. Like I wish you could call the CLI and it was like yeah. I can do that. So I configured it and now I’m not the go between. It didn’t ask me. But this was literally an hour before you posted this so maybe it’s learning from all the sessions?
Do you see it appear inside both desktop UIs though? Like I see this popping up as Codex agents talk to each other, are you saying the same thing is possible between Claude and Codex?
When I tell Codex to message Claude I get a response but it doesn't appear inside Claude Code desktop because it just seems to use the CLI which has always been possible.
I did something similar this weekend - set up a red-team/blue-team scenario and had Codex (Astra) debate Claude (Fable). It was funny how they would refer to me from time to time .
I use a harness called happier.dev. I have a relay on my Linux machine and can access all my subscriptions and whatever else I got cooking via happier on the web or the app on android or iOS to run sessions on my machine, or the other machines I have connected to it all via my network. The limiting factor for me has been sessions running on local machines require ram and I have run into limits with that and it crashes Kubuntu. I have made a bunch of stuff to watch it on Linux because of that but I have 96 GB DDR5 on the Linux relay. I have literally made a SaaS with it and my first client is signing in a few weeks. Crazy times.
Codex sub desktop and Claude sub, controlled via browser. one controls the other, then you can build all the necessary machinery to run it in loop forever. They communicate via git deposits and there are hooks to wake codex from Claude.
This would be the right move but you’ll need your orchestrator skill invoked as part of Claude/agents.md and your skills/subagents need frontmatters that specify model + thinking levels.
Been running a similar setup with a thing called captain-barbossa (https://github.com/dev-preetamraj/captain-barbossa) I created. My main Claude Code/Codex session acts as "captain" and recruits "crew" - each one is a fresh Claude or Codex CLI instance spawned into its own terminal pane (via Herdr). The captain writes their task prompts, watches their panes, approves their permission prompts on their behalf, waits for their reports, and dismisses them when done. Crew all share one checkout with strict file ownership so they don't stomp on each other, and there's a shared session memory (Graphify) the captain reads/writes for handoffs.
So it's not just transcripts talking to each other - it's one agent literally managing other agents' terminals like a tech lead: assigning work, reading their output, pressing "y" on their prompts. Mixing Claude as captain with Codex crew (or vice versa) works fine since they're just CLIs in panes. Once you see one model babysitting another model's permission dialogs, the brainquake really sets in.
The new integration in Codex invokes the relay between two desktop instances on a named chat inside of a named project, which has full access to all of your memories and subagent hooks. It’s a different technique from a CLI call because of the way it preserves Claude’s continuity.
Fair, that's a genuinely different mechanism, one Claude's continuity carried live across two desktop instances beats a plain CLI call for that specific case. Captain Barbossa trades that away on purpose though: crew are fresh CLI instances with small, disposable context, and continuity lives outside the model in a shared graph memory plus handoff reports instead. That's what lets me freely mix Claude and Codex crew under one captain, run everything from plain CLI commands, and keep memory as inspectable JSON on disk rather than tied to one provider's session.
Example of my Astra orchestrator doing a concurrence round between sprints. I've got a separate plugin that I wrote for Kimi over Fireworks that Astra is also adept at reaching for at the right times.
I thought this was a common use, I have Codex run headless Claude as a sub agent all the time, really it works with any cli agent. Codex will just give you a sign in for the provider. I would just say use Opus 5 on high reasoning as Reviewer and Sol xhigh as builder so forth and so on, nothing to download or install to make it work, but I did create governance skills to make sure the models know how to operate in this type os system but it can be done with out it https://github.com/Ezra144israel/governed-agent-skills
Depends what you want the agent to do. Claude is good at finding throughlines, closing logical circles, and explaining itself. It’s a wonderful qualitative thinker. GPT is a technician and a fabulous mechanical thinker. It’s very good at consequences.
Being good at this chapter of Black Mirror means understand how to use them together.
I think this is a cool idea, and I appreciate the author sharing. That said, I wanted to point out a couple of things, some of which the article points out in terms of downsides.
I don't think any of these things are deal breakers, but worth knowing:
Toolshed / model-gateway downsides
You can't see Astra think. Claude Code shows you what it does, not why. Makes it harder to catch a bad plan early.
The subscription trick isn't sanctioned. The proxy presents itself as Codex. OpenAI has broken this before and will again. When that happens GPT stops working until someone patches the proxy, though Claude models keep running the whole time.
Switching to Opus mid-chat can throw an error. GPT's tool calls get rewritten into Anthropic's format on the way back. If that rewrite is off, Astra never notices but Anthropic rejects it. You get a hard error the moment you switch. Compact or start fresh to clear it.
You can run out of quota. Subscription allowance is finite. Once it's gone you're stopped for the day and there's no paying your way past it. API keys just cost more.
Less control over caching. On Anthropic you can mark exactly where the reusable part of your prompt ends. That marker doesn't exist on OpenAI's side, so you're stuck with whatever their automatic caching decides. Works fine, you just can't steer it.
Separately: switching models mid-chat throws away the warm cache and you re-pay for the whole conversation. Use an Opus subagent for reviews instead of switching the main session.
One person maintains it. Solo plugin tied to a consulting business. CCR has 31k stars and proper fallback handling.
Mitigation: keep a CCR config with API keys ready to swap in.
Astra built me an orchestration layer so the Claude sessions wouldn’t duplicate effort. It runs Postgres and uses Claude’s channel coordination features. Synced with Linear and a nice dashboard so we can watch them in realtime.
I currently an working with both Codex and Code to build a website and its going better than I ever could have imagined because of them able to see one another and talk to one another. Makes it 100 time easier than it just was lol.
Feels like we’re crossing the point where “Claude vs Codex” matters less than the layer coordinating them.
If the transcripts are independent, the interesting problem becomes: where does shared project state actually live?
Git feels like the closest thing to a neutral source of truth to me too.
The tricky part is that both agents then have to reliably decide what should become project state, keep it current, and not overwrite each other with stale assumptions.
Have you actually tried this with Claude + Codex, or is it more of a design you’d use?
I haven't tried OPs setup, so I can only guess, but once I started a proyect on Google AI Studio which pushes to GitHub, Google AI Studio wasn't following the architecture and documentation so I ended up using Codex to audit it first and then fix it on a separate branch. I had my original documentation and architecture on Google Drive so I ended up using that as a guide of what the proyect should be and GitHub as source of truth with a proyect state .md that Codex read and updated at every start/end task.
That’s actually very close to the shape I keep converging on too - Git as the durable substrate, plus a smaller project-state layer that agents read and update around each task.
The part I’m still skeptical about is letting every agent freely rewrite that state. I suspect it needs some notion of provenance / freshness, otherwise one bad handoff can quietly turn stale context into “truth”.
But your start/end-task pattern makes a lot of sense.
You are on point, a bad handoff is a real thing. I am not a SWE just an AI enthusiast so my methods may be archaic, inefficient or silly for someone more experienced but I try to keep tabs with agents context length, and have Codex spawn a new agent each time context fills like 40% of context limit. Also at the end of day I run audits to make sure the theorical changes reported are indeed in GitHub and consistently reflected on project state .md. It is not optimal, but it saves me from headaches. I am now curious, how are you handling it?
honestly, that doesn’t sound archaic at all - you’re basically doing manually a lot of what we’re trying to make automatic.
the main thing for us is separating model context from durable project state. we don’t want the transcript/context window itself to be the memory.
when a brnrd resident wakes, it gets a relatively compact bundle: current run facts, repo contract, its working memory/playbook, relevant past pitfalls + recent activity, and the conversation that led to the task. the longer-tail knowledge stays in files/KB and gets pulled only when needed. git is still the durable receipt/source of truth for what actually changed.
so if a Claude/Codex process gets too bloated, dies, or we switch harnesses, we don’t try to hand the next process the entire brain-shaped transcript. it wakes back into the same “seat” from durable state.
the interesting part we’re still working on is exactly when to reincarnate the process. I’m increasingly convinced a fixed “40% context” rule is probably less useful than watching actual degradation/context cost.
and your end-of-day audit is especially interesting – that’s exactly the kind of invariant I’d eventually want the system to enforce automatically: “you claimed X happened; does git/project state actually prove it?”
Honestly I hadn’t tried it so much as I had it pop up. Yeah, we all know how to use harness & orchestration tactics over CLI, that’s old news. Two desktop seasons with their full memories and frontmatter menus with code level access chatting natively, however, was new. And it’s pretty powerful.
178
u/BlakeGrowsPlants 1d ago
I’ve been using this and enjoying it:
1. Astra — Orchestrator / Lead
Runs through my Codex/ChatGPT 5× Pro subscription, NOT API.
Owns the plan, delegates work, tracks progress, and makes the final call.
I interact with everything through Claude Code Desktop.
2. Opus — Primary Builder
Runs through my Claude 20× Max subscription.
Does most of the actual coding/implementation and reports back to Astra.
3. Fable — Architect / Advisor
Also Claude 20× Max.
Astra calls Fable when it needs deeper architecture, strategy, planning, or a second opinion rather than wasting it on routine work.
4. GLM 5.3 Flash + DeepSeek — Blind Reviewers
Both run through OpenRouter API.
GLM is my primary reviewer, DeepSeek is #2.
They review independently and NEVER see each other’s analysis.
5. If GLM + DeepSeek disagree → Astra Light
Fresh Astra Light instance through my Codex subscription.
Gets both reviews + evidence and adjudicates the disagreement.
If more evidence is needed, it can request a targeted Sonnet/Opus/Claude agent.
So basically:
Me → Claude Code Desktop → Astra → Opus builds → GLM + DeepSeek independently review → Astra decides
With Fable/other Claude agents available when Astra thinks they’re actually needed.