How It Works

CurdX Bridge is built around one principle: keep one accountable primary agent while still using specialist models in parallel.

Split-Pane Architecture

Each provider runs in its own terminal pane. Claude is the operator-facing pane, while the other panes are specialist workers that can be observed directly.

• Claude owns the conversation, plans the next move, and integrates replies.
• Codex is usually the reviewer or execution peer.
• Gemini is usually the inspiration source.
• OpenCode adds another implementation perspective when needed.

Unlike a hidden background integration, this layout makes the system legible. You can see whether a provider is thinking, stuck, or responding off-target.

Communication Flow

When you say "let Codex review this", the flow is:

1. Claude interprets your intent and selects the appropriate provider.
2. Claude sends a structured request through the async ask path.
3. The provider works in its own pane without blocking your main conversation.
4. Claude later retrieves the reply through the pending-reply path and integrates it.
5. You continue talking to Claude, not to the transport layer.

Why The Async Model Matters

• Providers do not block one another.
• Claude can keep the high-level thread coherent while side work continues.
• You can issue sequential or overlapping requests without losing observability.
• Each provider retains its own conversational context over time.

This is the difference between "I asked another model for help" and "I am running a visible multi-agent session."

Role System

CurdX Bridge is easier to operate when you treat providers as roles, not interchangeable models.

Role	Default provider	Responsibility
Designer	Claude	Interprets the user request, creates plans, owns decisions
Reviewer	Codex	Runs scored review gates and surfaces concrete defects
Inspiration	Gemini	Produces alternatives, naming, and architecture options
Collaborator	OpenCode	Adds an extra implementation or reasoning perspective
Executor	Claude or Codex	Performs concrete file or testing actions in AutoFlow

Role Assignment In CLAUDE.md

Roles are typically declared in your project-level CLAUDE.md:

| Role | Provider | Description |
|------|----------|-------------|
| designer | claude | Primary planner and orchestrator |
| inspiration | gemini | Brainstorming and alternatives |
| reviewer | codex | Scored review gate |
| executor | codex | File operations and test execution |

Changing the provider in that table changes how the orchestration behaves. The role name is the contract; the provider is the implementation choice.

Review Framework

CurdX Bridge uses explicit rubrics so "looks good" is not the only gate.

Rubric A: Plan Review

Dimension	Weight	What it measures
Clarity	20%	Another developer can follow the plan without back-and-forth
Completeness	25%	Requirements, edge cases, and deliverables are covered
Feasibility	25%	The plan can be executed in the current repo and tooling
Risk Assessment	15%	Risks are named with concrete mitigation ideas
Requirement Alignment	15%	The plan maps back to the user request

Rubric B: Code Review

Dimension	Weight	What it measures
Correctness	25%	Behavior matches the approved plan
Security	15%	Validation, secrets, and unsafe patterns are handled well
Maintainability	20%	Naming, structure, and conventions remain healthy
Performance	10%	No obvious avoidable regressions
Test Coverage	15%	Changed paths are verified by tests where needed
Plan Adherence	15%	Implementation still matches the agreed design

Pass Criteria

• Weighted score must be at least 7.0
• No single dimension may be 3 or lower
• Failed reviews can be revised and resubmitted, up to the configured limit

Session Management

Every session keeps project-local state in .curdx/, including things like current execution state and resumable context.

Typical lifecycle:

• curdx [providers...] starts a fresh split-pane session
• curdx -r resumes the last session
• curdx kill stops all panes
• curdx kill codex -f force-restarts only the noisy or stuck provider

Practical Operating Advice

• Keep Claude responsible for the final recommendation even when another provider produced the best raw answer.
• Use review requests with constraints. "Check for migration safety and rollback risk" gives better results than "review this".
• Reassign roles only when you have a reason. Random provider swaps usually reduce consistency.
• Watch the side panes. The best debugging signal is often seeing where a provider got confused.