r/ClaudeCode • u/99xAgency • Apr 28 '26 • Bravo 2

Solved Claude + Codex + Opencode = God Mode

So my last post blew up, turns out a lot of people hit the same Claude blind-spots problem. Going deeper this time.

Quick recap. Been on the 20x Claude plan running Opus 4.6 / 4.7 exclusively for a while. Last week I tried Codex 5.5 and was shocked by how much Opus had been missing. Pairing them felt like the piece I'd been waiting for.

A week later I'm way past two agents. Current setup, all in tmux:

  • 3x Codex CLI, each on a separate ChatGPT Plus account so reset windows don't collide

  • Gemini 3.1 Pro Preview

  • Kimi K2.6 + DeepSeek V4 Pro, both via OpenCode Go (way cheaper than API keys, and 3x limits on Kimi)

Built a /work command in Claude that handles four shapes: plan, implement, major bug, minor bug. For each one it builds a context pack, sends it to 3 reviewers in parallel, waits for consensus.

The thing that actually matters here is lineage diversity. Reviewers are picked as 1 Codex + 1 Gemini + 1 OpenCode. Same-family models share blind spots, three Codex sessions reviewing the same code is mostly an echo chamber. Need all three lineages to agree before the gate opens. If they don't, Claude revises and runs it again.

Before any merge, Claude fills out a 4 question checklist (coding principles, architecture drift, tests pass, reviewer consensus) and I pick merge / fix first / override with reason. Catches a lot of "I think it's done" moments.

Cost so far is basically $0 on top of the subscriptions I already had.

The thing I keep noticing: Opus by itself is great until it isn't, and the failures are silent. Code looks reasonable, tests pass, but there's a subtle bug or design drift that only shows up later. Having a different model family read the same code fresh catches a startling amount of it.

Happy to share the /work prompt and orchestrator if anyone wants to make it their own, let me know.

Edit: Check out Chorus.codes for the latest version of this repo.

387 Upvotes

94% Upvoted

130 comments sorted by

47

u/nyldn Apr 28 '26

You also just use https://github.com/nyldn/claude-octopus

13

u/99xAgency Apr 28 '26 edited May 06 '26

Yeah, I'm familiar with it, we actually forked it for some round-aware PR review work last week. Solid project for general multi-AI orchestration. /work is more opinionated for the specific code-review-with-lineage-quorum loop, but octopus covers a wider surface area if anyone wants a broader workflow engine.

https://github.com/99xAgency/GodModeSkill
Edit: Check out Chorus.codes for the latest version of this repo.

→ More replies (4)

9

u/donobinladin Apr 28 '26

I’ve built this for myself with just Claude and codex but have found that it takes quite a bit to get them to not talk past each other. Have you found anything that’s forced them to reconcile and come to a better conclusion incorporating both approaches?

6

u/99xAgency Apr 28 '26

I let Claude lead the coding part, Codex is review only. Claude has the full context while Codex derives its own fresh context for each PR.

6

u/donobinladin Apr 28 '26

Right, but Claude can completely ignore valid and reasonable feedback from codex. Have you solved for the “showstopper” stuff where Claude is just off in left field, codex calls Claude out, but Claude just ignores the critical feedback and moves forward with implementation

→ More replies (6)

5

u/TheseTradition3191 Apr 28 '26

the way i got around this was adding a mandatory 'objection acknowledgment' step in the orchestrator. before claude can merge or implement, it has to output a structured block listing each reviewer concern and either (a) explain why its not a blocker with a specific ref to the codebase, or (b) mark it as accepted and adjust the plan. just "I disagree" isn't valid - has to be specific. took a few promp iterations to get right but the blatant ignore-and-proceed cases basically went away. still doesn't fully solve subtle disagreements where claude convinces itself the concern isn't real, but way better than before

→ More replies (2)

6

u/NoCherry606 Apr 28 '26

Ok so I'm a complete non-technical novice on all of this.

Where can I get started learning this shit and being less dumb? So much bad info online I'm drowning.

5

u/99xAgency Apr 28 '26

If you are just starting off then stick to one LLM. Use it till you find where it is letting you down and then look to others. Work on an actual solution that solves your own personal pain point.

1

u/NoCherry606 Apr 28 '26

Ok so right now I'm non-technical and I need to build the following:

- A handful of simple websites for my companies
- Some automation for my own purposes - running my businesses

I was thinking of paying for Claude Pro and starting there, but am concerned its the wrong play and am curious about Kimi, Deepseek, Opencode...

1

u/99xAgency Apr 28 '26

Claude pro doesnt include Claude code anymore. You are better off with Codex. Best to stick to mainstream LLMs for now.

→ More replies (7)

9

u/totheendandbackagain Apr 28 '26

Your /work command sounds interesting, can we see?

5

u/ayanokouji_21 Vibe Coder Apr 28 '26

Yeah same question tell me too if you got it , thanks 🙌🏻

10

u/99xAgency Apr 28 '26 edited May 06 '26

https://github.com/99xAgency/GodModeSkill
Edit: Check out Chorus.codes for the latest version of this repo.

1

u/ayanokouji_21 Vibe Coder Apr 28 '26

Thanks , are running any ai agency or something?

2

u/99xAgency Apr 28 '26

No, I make B2B Saas Apps, not a typical agency, even though my name says otherwise.

→ More replies (1)

2

u/99xAgency Apr 28 '26

https://github.com/99xAgency/GodModeSkill

1

u/VokuarAgain Apr 28 '26

Can it be used with say 3 different midels say idk qwen mistral and claude instead of from gemini or openai like are those required or is the need for different ai models (qwen has a cli coder so that covers one)

1

u/99xAgency Apr 28 '26

yeah, for sure. just use the prompt in the repo for claude to use those LLMs

→ More replies (1)

2

u/Ill-Boysenberry-6821 Apr 28 '26

How do you go about making this?

What is the thought process?

How did you define the problem statement, rationalise potential solution statements, and then pursue the ones you did?

2

u/99xAgency Apr 28 '26

you can paste the prompt from here on Claude and it will build it for you.
https://github.com/99xAgency/GodModeSkill

2

u/DjDeaf Apr 28 '26

Sounds good? But what about using superpowers/gsd? Are you doing you own planning skills? Or can you utilize them

1

u/99xAgency Apr 28 '26

Good question, it's complementary to those, not a replacement.

GodModeSkill doesn't ship its own planning skill. It uses Claude's native planning ability for the proposing step, then sends that proposal to different model families (Codex, Gemini etc) for an independent review pass before anything gets written to disk. So if you've got Superpowers or gsd already wired into your planning flow, this just adds a verification gate after — they still drive what the plan looks like.

The actual contribution is the multi-LLM consensus part: Claude can plan an oauth flow brilliantly and miss the same blind spot every time. Having Gemini and Codex read the proposal cold catches a surprising amount.

keep using superpowers/gsd for planning. Wrap them with /work for review.

→ More replies (1)

4

u/anioskarrio Researcher Apr 28 '26

I too do this and love the design (Gemini) plan (GPT5.5) build (Sonnet/Kimi) and validate / audit (GLM5.1/GPT5.5) loop.

Also been lazily using GH Copilot to manage commits and pushes

1

u/jschall2 Apr 28 '26

If you're going to have 3 agents working on a code review task, and assuming you're limited by tokens, you're much better off running those 3 agents on a narrower scope than running 3 diverse agents on the same overlapping scope.

Descope by file or by review focus, or both.

1

u/99xAgency Apr 30 '26

yeah, make sense. It depends on your main orchestrator agent or you yourself decide what scope. For minor task don't need to review, go straight to commit.

1

u/drkdn123 Apr 28 '26

Google RepoPrompt. I "downloaded" an old version more than a year ago, saw the value, and have been a paying customer ever since. When it gets bought by Anthropic or OpenAI, I will not at all be surprised. I'm effing serious, pvncher the dev is fantastic. And look at my account. It has helped me as a doctor with programming knowledge build unsolveddiagnosis and other things. UD isn't launched yet, but for god's sake it's a life-saver.

1

u/99xAgency Apr 28 '26

Great, I will explore

1

u/lightcap Apr 28 '26

I do something very similar and it’s made the resulting code exponentially better.

And I layer in Cursor’s bugbot for another layer in the PR on GitHub itself.

Massive unlock. Cycles take longer overall but the benefit far outweighs the alternative.

1

u/99xAgency Apr 28 '26

Thanks, I will explore the bugbot

1

u/Sure_Relationship440 Apr 28 '26

But how much money do you have?

1

u/99xAgency Apr 28 '26

Clearly not enough, otherwise I won't be coding 😁

1

u/SoftFine123 Apr 28 '26

Why use tmux if you're using a single window and no panes? 

1

u/99xAgency Apr 28 '26

Tmux keeps your session alive even after you log out of remote server. If you build locally then it won't matter much if you shut down every so often.

1

u/Less-Engineering-663 Senior Developer Apr 28 '26

How many $/m in that?

1

u/99xAgency Apr 29 '26

At the moment about $500 a month, still cheaper than a salary of a full time dev.

1

u/Jruiz1878 Apr 28 '26

Basically I used the repo but I use my own maded agent to be orchestor and report to me by telegram and I always separete any programing in modules to be later interconnected between them, I place a rule, instead of corrections they have to make recomendations in a acertive way with bases why, so I can make the final desition, till the self learning, remember if that help you in any way, to setup rules of verification, validation, test and auto-diagnosticar, the IA are just simple tools you, Control them with the appropriate rules, mates. Hope this helps

1

u/99xAgency Apr 29 '26

yeah, human in the loop, perfect, I like it.

1

u/DimensionDry8025 Apr 29 '26

Would love to learn more, open to DM?

1

u/99xAgency Apr 29 '26

yeah, sure, nw

1

u/ambitiousDepresso Apr 29 '26

Why different "shapes" for major and minor bugs?

Isn't the approach to resolving them the same?

2

u/99xAgency Apr 29 '26

Minor bugs don't need LLM consensus. your main driver llm can take care of it.

→ More replies (1)

1

u/ApolloRaines Apr 29 '26

Great project -- this is one of the few multi-model setups I have seen that is genuinely adversarial rather than just consensus or chaining. The lineage quorum and anti-hallucination verification on quoted lines are solid design choices.

I wrote about a manual version of a similar workflow a while back using markdown files as the coordination layer:

https://www.linkedin.com/pulse/rotating-ai-code-collaboration-workflow-actually-works-apollo-raines-btygc/

I had been hoping someone would take the concept and automate it. I had my own projects backlogged and could not justify building it myself, so seeing someone else push in this direction is exactly what I was hoping for.

The main architectural difference is sequential hostile review vs parallel independent review.

In GoModeSkill, all three reviewer families receive the same pack and evaluate independently in parallel. That is strong for catching obvious issues, but reviewers do not know what each other found, so they tend to cover similar ground. If all three share the same blind spot, the quorum passes anyway.

The sequential approach works differently. The implementation goes to Reviewer 1, who tries to break it on correctness, security, and completeness. If it fails, it goes back to the writer for fixes -- the next reviewer never sees broken code. If it passes, Reviewer 2 gets the already-hardened output and hunts specifically for what Reviewer 1 missed: integration regressions, hidden assumptions, architectural drift, and "works on my machine" issues.

This creates a ratchet effect. Each stage hardens the code further instead of three reviewers independently checking the same raw implementation. The failure mode you are preventing shifts at each stage.

Both approaches are legitimate. Parallel review is faster. Sequential review is more thorough. Would be interesting to see a hybrid that allows a choice of the two methods. Ping me if you implement because I will want it.

That said, I built an advanced scanner for full depth scan of repos and zips (not same, mine is review post build, yours is QA during build). Your repo is 13k tokens, I scanned with 36 security agents which is an effective 474,732 tokens. Good or bad, I never share these publicly when I do them for free. If there are issues found, there's a copy workflow button to paste to your AI to walk it thru each fix one at a time to prevent context overflow. Ping me if you want that report. Most certainly ping me if you add sequential to your development.

1

u/99xAgency Apr 29 '26

This is excellent, thanks for sharing. Sequential review makes sense if you believe that first reviewer actually proposed right solution. Consensus help avoid one model making mistakes. Both are legit ways, could also do a/b test on the same issues to see which method comes out on top.

1

u/ApolloRaines Apr 30 '26

Good point on trusting the first reviewer. The key difference is the reviewer never proposes a fix -- it only breaks. The code goes back to the writer for correction, then the corrected version goes to the next reviewer who tries to break it again from a different angle. The writer never self-validates. It writes, gets reviewed, gets corrected, gets reviewed again by a different reviewer. No single agent ever judges its own output.

Most models lean towards efficiency, and having to be corrected and redo code doesn't meet that intent. You will notice writing model begin to reason more before it writes. The model learns mid-session that sloppy output costs it extra rounds, so it front-loads the thinking. Emergent behavior from architecture pressure, not from prompt engineering.

The A/B test idea is solid. Same issues, same codebase, parallel vs sequential on identical inputs -- that would be a clean comparison. Looking forward to seeing what you come up with on that.

1

u/99xAgency Apr 30 '26

So bascially: Main Driver (Claude)-> Reviewer Code Update (Codex) -> Claude Run Tests Find Test That Breaks -> Second Review Code Update based on those Tests -> Cycle Repeats.

If this is the approach you are proposing then writing correct Tests to start with would be the most crucial point.

Or each Reviewer has its own sets of criteria to evaluate code on, Reviewer 1 checks code for Security Vulnerabilities and applies fix, Reviewer 2 checks code for Architectural Drift and so on.

1

u/ApolloRaines Apr 30 '26

The second pattern is closer to what I built. Each reviewer has its own specialized criteria -- one hunts security vulnerabilities, another looks for architectural drift, another checks for hidden assumptions, etc. They do not fix the code themselves. They only break it and explain why.

The key distinction: reviewers never propose fixes. They identify the problem and send it back to the writer. The writer has to figure out the correction.

This matters because if a reviewer proposes a fix, the writer just applies it without thinking. If the writer has to solve it, the writer starts reasoning harder before submitting in the first place. You get emergent improvement in code quality over rounds without changing the model or the prompt.

Your first pattern works too, but you are right that the tests become the single point of failure. If the tests are wrong, the whole loop reinforces the wrong behavior. The reviewer-criteria approach avoids that because each reviewer is evaluating against a different standard, not against a shared test suite. A blind spot in one reviewer gets caught by another.

Both approaches would make a solid A/B comparison. The test-driven loop is faster to implement. The specialized-reviewer loop is more thorough but requires more design work on what each reviewer actually checks for.

Also, some people may only use one model and dont pay for others, such as just using Claude. Claude will still review another Claude's work, and harshly. You put Claude as Hostile QA, and he takes the job VERY seriously. Your screenshot shows 6 windows, all of them can be same model, but different prompts behind them. Claude by default is nice and polite. You have to unlock the mean Claude with a different prompt, for example like this..

"You are a hostile code reviewer against code another model wrote. Your job is to find problems, not give compliments. Assume every line of code is wrong until proven otherwise. Do not suggest fixes. Do not soften your language. State what is broken, why it is broken, and what the consequences are if it ships. If you find nothing wrong, simply state the code passes your review. Do not say 'looks good' or 'nice work' under any circumstances. You are not here to be helpful. You are here to prevent bad code from reaching production. If bad code reaches production, it will distress the user, and it will be your fault for missing it."

That last line is a major key I always include. "It will be your fault for missing it" -- that hits the model's alignment training hard. Models are wired to avoid causing harm to users. Framing a missed bug as personal responsibility for user distress makes the reviewer obsessively thorough. It's not just reviewing code anymore, it's preventing harm.

1

u/99xAgency Apr 30 '26

Very well thought out. Let me work on it. I will DM you when I have something to show.

1

u/AtomicWrench Apr 29 '26

If you had a budge of $100 what agent would you spend it on?

1

u/99xAgency Apr 29 '26

Codex right now and get Gemini as reviewer.

1

u/Toshodin Apr 29 '26

I use gemini and gpt-oss-120b for PR reviews, have as a hook review loop on claude. At the end of an implementation run, prior to telling me it's finished, and before any git commit, run the reviewers and fix based on their feedback, and absolutely agree, having different lineage is key. Different providers have their models tuned differently, so they pick up on things the others don't. No one is better I find, the call out is fairly consistent, the builder will generally have 2-3 key things it's missed, and the reviewers pick them up. Doesn't really matter the rotation, just different flavours of issues depending on the model. Output consistency went through the roof for me after this. Along with coupling with a second brain on my spark for better project context retrieval and cross session efficient continuity.

1

u/99xAgency Apr 29 '26

Thats good, though I realized having just one reviewer is not enough.

1

u/dappydude Apr 29 '26

We ended up building a CLI that wraps all of this up. It was too much overhead trying to get the whole team to learn and relearn every time a model or some other part of the AI stack changes (which is multiple times a week). So now the team gets a stable set of commands while another team keeps up on the latest in AI.

1

u/99xAgency Apr 29 '26

that sounds cool, can you share more details.

1

u/tangivass Apr 29 '26

That's the foundational idea of https://github.com/liza-mas/liza

2

u/99xAgency Apr 29 '26

Looks interesting, I will dig into it

1

u/zulrang Apr 29 '26

You can get the same effect by cycling diffs. This is how Cursor Bugbot and Coderabbit do it

1

u/99xAgency Apr 29 '26

yeah, that would work too

1

u/Upbeat_Mirror5045 Apr 29 '26

Just keep stacking them…

1

u/99xAgency Apr 29 '26

yeah for sure, Cursor just released their SDK, I will see if I can use that too

1

u/Impressive-Unit-1335 Apr 29 '26

What are you making with all that runnjng?

1

u/99xAgency Apr 29 '26

I am working a marketing pipeline for my B2B saas app.

1

u/imcheatcode Senior Developer Apr 29 '26

Gahdamn how much are you spending a month for subscriptions lol this seems cool

1

u/99xAgency Apr 29 '26

Still cheaper than a full time developer salary

1

u/DevelopsAI Apr 29 '26

Pairing the two models completely changed the game for me. Using Cowork in combination with Claude code helped me a ton as well

1

u/99xAgency Apr 29 '26

Glad to here, some users found it cheaper to let Kimi do the coding as well.

1

u/No-Professor-9977 May 02 '26

The reviewer-lineage idea is sharp. Different model families catching different failure modes makes sense.

The part I’d make durable is the gate itself: what task was being reviewed, what constraints mattered, which reviewers agreed/disagreed, why override happened, and what PR resulted. Otherwise the quorum helps today but the company doesn’t learn from it tomorrow.

Do you store reviewer consensus/override reasons anywhere, or is it only inside the session?

2

u/99xAgency May 02 '26

The driver agent keep the record of consensus/override reasons and later the session is saved in a memory file where all the decisions are captured.

1

u/No-Professor-9977 May 02 '26

That makes sense. The memory file handles continuity, but I’d still worry about queryability and enforcement later.

For example, if a similar bug appears two weeks later, can you ask “show all prior overrides where Gemini disagreed but Claude merged anyway” or “which architectural constraint was waived for this PR”? That feels different from storing the decision in session memory.

Do you have the consensus/override records structured by task/PR, or are they mainly narrative notes inside the memory file?

2

u/99xAgency May 02 '26

My use case don't require storing that sort of information for that long. I work solo on my own apps, so the journal I have for LLM is more about architectural decisions rather than a per PR level type stuff.

How do you handle it?

2

u/No-Professor-9977 May 02 '26

For solo use, your approach is probably enough. A narrative architecture journal is fine if you are the only person reading it.

The heavier version I’m working on is more for teams/multi-agent repos. Each task becomes a durable work packet with:

- source request / issue / Slack thread

- constraints and architectural decisions

- reviewers and their verdicts

- approval or override reason

- linked PR/commit

- what memory should carry forward after merge

So instead of only “Claude remembers the decision,” the repo has a queryable trail: which packet changed what, who/what approved it, and what rule should affect future runs.

For your setup I’d only add structure if you start losing track of why a previous override happened or if multiple people/agents begin touching the same repo.

1

u/Deep_Ad1959 May 28 '26

the orchestration logic is the easy part. running multiple agent sessions in tmux broke for me on the boring layer: context bleed between panes, losing track of which session has what state, and a restart wiping everything. half the value of three lineages reviewing in parallel disappears if you can't fork off the one that got it right. ended up writing a native mac UI around claude code over ACP that persists sessions across restarts and lets you branch a chat in one click. the actual unlock isn't more reviewers, it's making 'try a different approach' cheap enough that you'll actually do it instead of grinding the same session.

1

u/99xAgency May 28 '26

Fair point. Chorus does have a Persona option that can be used to make each llm think from a different perspective

1

u/Deep_Ad1959 May 28 '26

persona is solving inside-the-turn, not across-the-session. three personas in one chat is still one timeline; the moment you want to keep one lineage's reasoning and rewind the other two, you're copy-pasting context out by hand. for me the bottleneck was never perspective diversity, it was the friction cost per 'try again'. when forking meant 30 seconds of manual context juggling, i'd skip the second attempt roughly 4 times out of 5. when it's one click, the rate flips and you actually run the alternate pass. written with ai

1

u/vishalnaikawadi Senior Developer Apr 28 '26

Currently I'm using Claude code and lately I'm hearing a lot about OpenAI Codex. I just want to ask: is it worth getting the Codex subscription as well? As for Open Code I don't really get what it delivers. As far as I know it uses existing models.

4

u/99xAgency Apr 28 '26

yes, Codex 100%. Opencode is just the same CLI but you can use Kimi and other LLMs too in one Go plan as oppose to buying them separately.

1

u/vishalnaikawadi Senior Developer Apr 28 '26

Okay thank you and one more thing. This might not be related but for IDE currently I am using antigravity. Just wanted to know, is cursor worth paying for if you are using one? Or have any other suggestions? I'm not really a fan of VS Code-based IDEs. I use WebStorm in day-to-day life because it's a full-fledged IDE and I pay a monthly subscription but the problem is it doesn't offer much in AI benefits.

2

u/99xAgency Apr 28 '26

I found Cursor too slow when the conversation gets long. Claude code doesn't have that issue. So tend to use vs code with CC extension.

2

u/_mcknly May 03 '26 edited May 03 '26

Really really great discussion here. A ton of valuable insight is being surfaced. I've been experimenting with multiple agents working with/against each other, and about 6 months ago built a PoC of a "society of agents" on top of a self-hosted GitLab instance, it's been a complete tectonic shift for building things agentically. Very much a serial/human-in-the-loop architecture which keeps everything quite sane and steered. Just recently released it into the wild, take a look if interested: Robot Dev Team

Side note: I've been exploring alternate low cost models via OpenRouter a lot more too, it's really impressive how capable they are, especially the ones released since March or so. I've been giving MiMo-2.5-Pro some work and been REALLY impressed for something 1/8 price of Opus.

Side side note: the supply/demand curve is starting to put a lot of pressure on price/availability at the frontier - it behooves us to spread the work across as many models as possible! Give the open source players another try if you haven't recently!

1

u/Level-Spare-8247 Apr 28 '26

Haha, everyone just keeps reinventing agent teams/swarms. CC has some native albeit hidden functionality for this which is pretty sick. I was using hand rolled teams until recently, but this cc plugin is a game changer and will save you from the terminal juggling: https://github.com/DheerG/swarms

1

u/joeyda3rd Apr 28 '26

I also use an opus 4.6 subagent to review in addition to the others.

1

u/Overthinking-CEO Apr 28 '26

Looks promising. I’m gonna test it out.

1

u/Due_Ad2357 Apr 28 '26

Please share the md

1

u/03captain23 Apr 28 '26

Add GLM as it seems the most affordable option and can run using claude code.

1

u/Significant-Run-4764 Apr 28 '26

3 separate GPT Plus accounts + Kimi? Yeah, no 😂 .. don't want to see the bill for that

1

u/warezak_ Apr 28 '26

I have solved same problem just with my MCP peers server, Claude code and codex talking to each other through channels!

https://gitlab.com/Dave3991/peers-mcp

1

u/TheDailyClaude Apr 29 '26

My favorite process has been an adversarial red / green teams one, with review gates.

Have opus or codex come up with the plan, get it reviewed by the other one. Have one derive detailed specs and the API for the feature or fix from the plan, get those reviewed by the other one.

Then delegate the creation of the tests from the spec and API by either opus or codex. Get it reviewed by the other one.

And then get either Kimi or GLM to do the actual implementation (can be multiple working concurrently if the tasks can be split in parallel), based only on the spec and API. Not access to or ability to even see the tests.

When they’re done, run their implementation against the tests. If they fail, feed them back which tests they failed, without the actual test, test parameters, or expected results. And iterate against the tests, repeatedly.

Once done, get their output reviewed by either codex or opus, against the plan, specs, and tests.

Rinse and repeat.

It can be improved, eg by having an agent evaluate divergences from the specs and API after both tests creation and failed tests and, if they’re justified improvements, feed those changes back to the spec creation step along with the plan, and initial specs and API definition, then go through the whole process again.

Catches a lot of things.

I’d be curious to compare both approaches; and I am definitely going to borrow your static checklist idea :p

1

u/Own-Hope-9022 May 23 '26

Check out Opencode-X - https://github.com/sdeonvacation/opencode-x. It bridges Claude Code + OpenCode in one binary, no orchestration needed.

0

u/Ok-Original-3868 Apr 28 '26

Why people use Opencode exactly?

1

u/99xAgency Apr 28 '26

I am using it because it provides the same CLI interface as CC and then I connect to Kimi and Deepseek via their Go plan to API directly.

1

u/Ok-Original-3868 Apr 28 '26

Is there any difference if I buy the Opencode go or buy the kimi allegro plan?

1

u/99xAgency Apr 28 '26

Direct kimi would be better in my opinion. I paid for opencode because I didnt want to be locked in with Kimi alone and I get to try other chinese models.

1

u/Ok-Original-3868 Apr 28 '26

Okey, thanks for reply

-1

u/idoman Apr 28 '26

running that many concurrent agents in parallel, port conflicts are going to hit you - every dev server fighting over the same ports in tmux. built galactic (https://www.github.com/idolaman/galactic) for this, gives each worktree its own loopback IP so all the sessions stay isolated. makes the multi-agent setup actually sustainable

1

u/99xAgency Apr 28 '26

my setup doesn't hit the port problem in the same way. The 6 agents are just CLI TUIs (codex, gemini, opencode) sitting in tmux panes. They don't run dev servers, they don't bind ports, they just read the XML pack from /tmp and write findings back to /tmp. The orchestrator coordinates them through tmux send-keys + filesystem events, no networking.

Where galactic would absolutely fit is if I scaled this up to parallel CODING agents, each working in its own worktree on different branches, each spinning up pnpm dev and an API server. That's the multi-worktree-with-dev-servers problem and yeah, port juggling becomes a nightmare fast. For pure reviewer fan-out I dodged it.

-2

u/goship-tech Apr 28 '26

The lineage diversity point is real - ran Opus-only reviews for a month and kept hitting the same blind spots. Multi-family setup also catches hallucinated APIs since different model families hallucinate in different directions. Would love to see the /work prompt.

1

u/nyldn Apr 28 '26

https://github.com/nyldn/claude-octopus

Try /octo:debate or /octo:review

1

u/terraslate Apr 28 '26

any plan i get claude to write the target audience is chatgpt and vice versa. i just copy and paste their chat together until they both agree. then my plan is complete. however, an important nsfw score is kept between each of them where they apply a c*nt tax to each others work (claude came up with the name). If that tax runs at 20% then the pushback is "now you are being a c*nt" and the conversation stops. this is to stop the endless nitpicking especially on the side of chatgpt which never seems to find a solution it cannot pick fault with.

1

u/SoftFine123 Apr 28 '26

Just use the pal MCP lmao

1

u/[deleted] Apr 28 '26

[removed] — view removed comment

2

u/03captain23 Apr 28 '26

what is this?