A skill that lets the model you're chatting with confer with another model inline — no second terminal, no API keys, no setup. You're in Claude Code asking about a bug? Claude can ask Codex what it thinks, paste the reply, and keep working. You're in Codex CLI working on a refactor? Codex can ask Claude to sanity-check the plan first.
This README is written for you, the human at the keyboard. You don't run anything yourself once it's installed — you just talk to your host model normally and it reaches for peers when that would help.
git clone git@github.com:StashwiseAI/ModelNexus.git(or with HTTPS if you don't have SSH set up: git clone https://github.com/StashwiseAI/ModelNexus.git)
That creates a ModelNexus/ directory in your current location.
cd ModelNexusConfirm you're in the right place by listing — you should see install.sh, skills/, and README.md at the top level:
lsExpected output:
README.md advanced/ capabilities.json install.sh package.json skills/ teams.json tsconfig.json
./install.shThat's it. The script auto-detects which host CLIs you have (Claude Code and/or Codex CLI), creates the right symlinks for each, and runs a doctor at the end showing which peer CLIs are available.
Expected output (yours will differ depending on what's installed):
Installing nexus skill from:
/Users/you/ModelNexus/modelnexus/skills/nexus
✓ Claude Code: linked ~/.claude/skills/nexus -> ...
✓ Codex CLI: linked ~/.codex/AGENTS.md -> ...
Which peer CLIs are available:
✓ claude on PATH (auth: Claude Pro/Max login or ANTHROPIC_API_KEY)
✓ codex on PATH (auth: ChatGPT Plus/Pro/Team or OPENAI_API_KEY)
✗ gemini NOT installed
A green ✓ means installed. A red ✗ means the peer CLI isn't on your PATH — that's fine as long as at least one peer is available.
Open Claude Code (or Codex CLI), and try saying:
Use nexus to ask codex: what does 'idempotent' mean? One sentence.
Within ~10 seconds you should see your host model reply with Codex's answer quoted inline. If you see that, you're done.
If nothing happens or the host model says it doesn't know about nexus, start a fresh Claude Code (or Codex CLI) session — the skill list is loaded at session start.
| Symptom | Fix |
|---|---|
./install.sh: No such file or directory |
You're in the wrong directory. Run cd ModelNexus (the directory git clone just created) and try again. |
Permission denied: ./install.sh |
Run chmod +x install.sh first, then try again. |
Claude Code: ~/.claude not found |
Run claude (the CLI) once interactively to log in. That creates ~/.claude. Then re-run ./install.sh. |
Codex CLI: codex not on PATH |
If you have ChatGPT Plus and want to use Codex, install: npm install -g @openai/codex. Then re-run ./install.sh. |
The host model doesn't seem to know about nexus |
Quit your Claude Code / Codex CLI session and start a fresh one. Skills are loaded at session start. |
Existing ~/.codex/AGENTS.md blocks the link |
The installer will tell you. Either remove it (rm ~/.codex/AGENTS.md) and re-run, or append: cat skills/nexus/AGENTS.md >> ~/.codex/AGENTS.md. |
The installer is idempotent — run it as many times as you want. It detects what's already set up and skips it.
Below: real exchanges from a session that built this skill. The You lines are what you'd type to your host CLI; the Host lines show what comes back.
You (in Claude Code):
I'm thinking of building a token-bucket rate limiter with the refill happening lazily on each request. Get a second opinion from Codex before I commit to it.
Claude (replies inline, calling Codex behind the scenes):
Asking Codex (auto-role: reviewer)…
Codex says:
- Lazy refill on each request is fine for low-contention single-process use, but races under burst load — two concurrent requests can both observe
bucket.tokens >= 1and both pass. Add a mutex around refill+consume, or use atomic-CAS.- Consider clamping
tokensatcapacityon refill — otherwise long idle periods will let a single client drain a huge burst at once.Codex's race-condition point is the real one. Want me to draft a mutex-guarded version, or do you have a specific concurrency primitive in mind?
You:
Have codex patch
src/auth.tsso the JWT verification happens before the cookie check.
Claude:
Asking Codex (auto-role: patcher, file: src/auth.ts)…
Codex's diff:
@@ - if (!req.cookies.session) return res.status(401) - const claims = verifyJWT(req.headers.authorization) + const claims = verifyJWT(req.headers.authorization) + if (!claims) return res.status(401) + if (!req.cookies.session) return res.status(401) req.user = claims.subDiff looks right. Applying it now. (Edit tool runs) Done. Want me to run the tests?
You:
What does codex think 'idempotent' means? One sentence.
Claude:
(auto-role: explainer)
Codex: Idempotent means an operation can be repeated multiple times and still produce the same result as doing it once.
You:
Get codex to critique this filename:
data_thingy_v2_final.json
Claude:
(auto-role: reviewer)
Codex:
data_thingy_v2_final.jsonis vague and self-contradictory (thingy,v2, andfinalall age badly); use a domain-specific name likecustomer_export_schema_v2.jsonormodel_metrics_2026-05-14.json.All three of "thingy", "v2", and "final" are smells — they signal the author didn't have a clear domain in mind. Want me to propose a naming convention for the whole directory?
You:
What do codex and gemini think about this — should I use token-bucket or sliding-window rate limiting for a public API? Give me a one-paragraph take from each.
Claude (both peers run in parallel via a single tool call, real output):
Asking 3 peers in parallel: claude, codex, gemini (auto-role: architect)…
══════════════════════════════════════════════════════════ codex · architect · 28s ══════════════════════════════════════════════════════════ - Objection: Token-bucket can permit short burst spikes that feel unfair and can overload expensive public API paths. - Validation: Use token-bucket as the default because it is simpler, cheaper, distributed-friendly, and handles normal client jitter well. - Improvement: Add endpoint weights, tight burst caps, and a secondary sliding-window quota for abuse-sensitive or billing-sensitive limits. ══════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════ gemini · architect · 22s ══════════════════════════════════════════════════════════ Objection: Token-bucket's burst support can mask systemic capacity issues and cause non-linear failures once the bucket is exhausted. Validation: Sliding-window (weighted counters) gives the most granular protection and avoids the "reset" surges of fixed windows. Improvement: Add cost-based weighting so different endpoints consume tokens proportional to their actual CPU/memory footprint. Choice: Use sliding-window for a public API — more consistent, more equitable, better-protected against erratic traffic. ══════════════════════════════════════════════════════════They disagree: Codex defaults to token-bucket with a sliding-window safety quota; Gemini argues sliding-window should be the default for public APIs. The common ground is cost-based weighting — both want different endpoints to consume the limiter proportional to their actual cost. My read: go token-bucket with Codex's two-layer pattern (burst caps + sliding-window quota for abuse-sensitive paths) unless your downstream genuinely can't absorb bursts. Want me to sketch the implementation?
Same one-question fan-out, three voices (or two — depends what's installed), wall-clock ~max of the slowest peer instead of sum. Real audit trail of who said what, then the host's synthesis at the end.
You (in Codex CLI):
Ask Claude to synthesize what changed across this whole PR.
Codex (via the same skill, just from the other direction):
Asking Claude…
Claude: The PR migrates rate limiting from in-memory token-buckets to Redis-backed sliding-windows, adds Lua scripting for atomic check+increment, and replaces three duplicated middleware files with a single shared module. The mutex layer in the old code is now obsolete — Redis handles atomicity.
That's a clean summary. Anything you want me to drill into?
You:
Remember we decided to use token-bucket, not sliding-window, because of the burst-tolerance requirement.
Claude:
(records the note)
Noted: decision · token-bucket over sliding-window (burst-tolerance requirement).
Later, a week or a new session later:
You:
What did we decide about rate limiting?
Claude:
(searches your notes)
Decision from 2026-05-14: token-bucket over sliding-window (burst-tolerance requirement).
You don't need to memorize commands. Any of these phrasings work — your host model picks up the signal and reaches for the right peer:
| You say something like… | Host calls… |
|---|---|
| "Ask codex…" / "What does codex think…" / "Have codex draft…" | Codex |
| "Ask claude…" / "Get claude's take…" (from non-Claude hosts) | Claude |
| "Check with gemini…" / "Have gemini summarize…" | Gemini |
| "What do codex and gemini think…" / "Get a group opinion…" / "Ask all the models…" | Multi-peer (parallel) |
| "Get a second opinion on…" / "Sanity-check this with…" | Whichever peer fits best |
| "Remember…" / "We decided…" / "For later…" | Notes |
| "What did we decide about…" / "Recall…" | Search notes |
The host model also picks a role automatically based on what you asked — "critique" → reviewer, "fix"/"patch" → patcher, "what does X mean" → explainer, "should I use A or B" → architect. You'll see a one-line note like (auto-role: reviewer) so the inference is transparent.
| Peer | Authenticates via | Best for |
|---|---|---|
| Claude | Claude Pro/Max login (or ANTHROPIC_API_KEY) |
Synthesis, long-form reasoning, cross-cutting design |
| Codex | ChatGPT Plus/Pro/Team login (or OPENAI_API_KEY) |
Precise patches, refactors, narrow bug fixes |
| Gemini | Google login (Gemini Advanced / Code Assist) | Long context, vision, web-context summaries |
You don't need all of them — just one peer different from your host is enough. Your host won't consult itself; if you're in Claude Code, "ask claude" is ignored; if you're in Codex CLI, "ask codex" is ignored.
- Mention specific files in your request and the peer will see them. "Have codex review src/auth.ts" is much better than "have codex review this".
- Be explicit about output shape. "Return only the diff, no prose" gets a clean patch; "explain in 2 bullets" gets 2 bullets.
- One peer call per question. If you want Claude to challenge Codex's reply, just say so — don't expect a silent ping-pong loop.
- Verify peer-cited line numbers. Reasoning models fabricate plausible-looking
file:linerefs they never actually saw. Your host model will treat them as signposts, not facts — and you should too.
The skill is a directory at skills/nexus/ containing a SKILL.md (read by Claude Code), an AGENTS.md (read by Codex CLI), a small front-door script nexus.sh, and a few bash helpers under lib/ that wrap the peer CLIs. Your host model invokes them through its Bash tool when one of the trigger phrases above lights up. Notes live in ~/.modelnexus/notes.md (plain Markdown, append-only — cat/edit/git it directly).
There's also an advanced/ directory in this repo with a heavier daemon/orchestrator from an earlier version of the project — different shape, used only if you want three or more models talking in their own multi-pane session. See advanced/README.md for details. The skill above is the path 99% of use cases want.
rm ~/.claude/skills/nexus 2>/dev/null # Claude Code
rm ~/.codex/AGENTS.md 2>/dev/null # Codex CLI (only if it's a symlink to this repo)Both are symlinks — rm removes the link, not the source files. Your repo is untouched.
MIT.