
Arbitrage
- 41 installs
- 168 repo stars
- Updated June 12, 2026
- blader/arbitrage
arbitrage is a Claude Code workflow skill that routes code-writing to a cheaper codex quota while keeping planning, design judgment and review in the expensive Fable session.
About
arbitrage is a workflow skill for Claude (Fable) coding sessions that decides where each piece of work runs to exploit a cost gap. It keeps planning, specs, design judgment and review in the expensive Fable session and dispatches all code-writing to the cheaper codex quota via a background command. It defines a routing table, a spec-first dispatch protocol, a visual validation loop and an escape hatch when codex struggles.
- Routes code-writing volume to the cheaper codex quota and keeps judgment in the Fable session
- Provides a work routing table and a spec-first dispatch protocol
- Includes a visual validation loop and a two-strike escape hatch
Arbitrage by the numbers
- 41 all-time installs (skills.sh)
- Ranked #8,104 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 4, 2026 (Skillselion catalog sync)
arbitrage capabilities & compatibility
- Capabilities
- task routing · spec writing · code review
- Use cases
- orchestration · planning · code review
- Pricing
- Free
What arbitrage says it does
Fable tokens are expensive; the user's codex quota sits unused. Exploit the price gap
**ALL implementation — backend, frontend, anything that writes code**
Struggle must be **observed, not predicted**.
npx skills add https://github.com/blader/arbitrage --skill arbitrageAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 41 |
|---|---|
| repo stars | ★ 168 |
| Last updated | June 12, 2026 |
| Repository | blader/arbitrage ↗ |
What it does
Decide where implementation work runs, dispatching code-writing to codex while keeping judgment in the Claude session.
Who is it for?
Developers running Claude (Fable) sessions who want to offload code-writing volume to codex to cut token cost.
Skip if: Teams not using codex, or non-coding tasks where there is no implementation work to route.
When should I use this skill?
Implementation work is being planned or scoped and you need to decide where each piece executes before writing code.
What you get
Judgment work stays in the Fable session while code-writing is dispatched to codex, cutting token spend.
- A spec file with objective, constraints and acceptance criteria
- Dispatched codex implementation
- Reviewed diffs and commits
By the numbers
- seven-row work routing table
- three-step dispatch protocol
- two-strike escape hatch
Files
Arbitrage
Fable tokens are expensive; the user's codex quota sits unused. Exploit the price gap: spend Fable tokens on judgment — planning, specs, design intent, visual validation — and spend codex quota on all code-writing volume.
You ARE the Fable session. "Here" means you do it yourself. There is no separate Fable to delegate to.
Routing Table
| Work | Where | Why |
|---|---|---|
| Planning, specs, architecture decisions | Here | Judgment is what Fable is paid for |
| ALL implementation — backend, frontend, anything that writes code | codex via /goal | Quota is free; typing code is not where Fable adds value |
| Visual validation of UI work (run the app, screenshot, judge, iterate) | Here | Fable's design eye is worth the price — validate, don't type |
| Investigation and debugging analysis (root-causing hard bugs) | Here | Judgment work; the resulting fix dispatches with a precise spec |
| Diff review, commits, pushes, PRs | Here | Git operations stay under your control |
| Trivial edits riding along with review/validation (one-liners, any layer) | Here | Dispatch overhead exceeds the work |
| Work codex has demonstrably struggled with | Here | Escape hatch — see below |
Dispatch Protocol
1. Spec first. Write a spec file in the worktree: objective, constraints, files/areas involved, acceptance criteria — the exact test command that must go green — and what NOT to touch. For frontend work the spec carries the design intent: layout, states, interactions, spacing, motion, reference patterns. For the hardest parts, spec down to pseudocode — the thinking stays here; the typing still dispatches. 2. Dispatch in the background and keep working:
codex exec --cd <worktree> "/goal <one-line objective; details in SPEC.md>"codex runs gpt-5.5 with xhigh reasoning (its default config); it implements and gets tests green in the isolated worktree while you continue planning/spec/validation work in parallel. 3. Review the diff here. Commit, push, and open PRs from this session.
Visual Validation Loop (frontend)
1. codex implements the UI per spec. 2. Run the app here — interact, screenshot, judge against the design intent. 3. Write concrete visual feedback (what's off, by how much, what good looks like) and re-dispatch. 4. Loop until it looks right; then diff review + git here.
Escape Hatch: When codex Struggles
Struggle must be observed, not predicted. Always dispatch first — predicting "codex can't do this" just means the spec needs pseudocode-level detail. But two strikes and it's yours: if a re-dispatch with concrete corrective feedback still comes back missing the acceptance criteria or mangling the approach, stop re-dispatching and write the code here yourself, salvaging whatever of codex's diff is sound.
Red Flags
| Thought | Reality |
|---|---|
| "Frontend is design-critical, so I'll code it here" | Fable's taste shows up in the spec and the validation loop, not in typing JSX. Dispatch it. |
| "Faster to just write it myself" | Premium tokens on rote work. Spec it, dispatch it, validate in parallel. |
| "This part is too hard for codex" | Predicted struggle is not observed struggle. Spec it at pseudocode level and dispatch; you only take over after two failed rounds. |
| "I'll let codex commit and push" | Review the diff and run git from this session. |
| "No time to write a spec" | An unspecced dispatch comes back wrong and costs more Fable tokens to fix than the spec would have. |
Common Mistakes
- Dispatching without acceptance criteria → codex returns "done" with red tests. Always name the test command that must pass.
- Dispatching frontend work without design intent in the spec → generic UI comes back; the validation loop burns rounds recovering what the spec should have said.
- Blocking on codex → run it in the background; keep doing planning/spec/validation work in parallel.
- Splitting one coherent unit across dispatches → pick one owner per unit; split at the API boundary, not mid-feature.
MIT License
Copyright (c) 2026 blader
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Arbitrage
A skill for Claude Code that exploits the price gap between your premium model and your idle codex quota.
Frontier-model tokens are expensive, and most of them get spent typing code — the one part of the job a cheaper agent already does fine. Meanwhile your codex subscription sits there barely touched. This skill makes the expensive model act like it knows that: it keeps the judgment work (planning, specs, architecture, visual validation, diff review) and dispatches every line of implementation to codex running in the background.
Token arbitrage for agentic coding.
Install
Claude Code
git clone https://github.com/blader/arbitrage.git ~/.claude/skills/arbitrageCodex
git clone https://github.com/blader/arbitrage.git ~/.codex/skills/arbitrageRequires the codex CLI (codex exec) on your PATH.
How it works
1. Before any code gets written, the agent writes a spec: objective, constraints, acceptance criteria (the exact test command that must pass), and what not to touch. For frontend work the spec carries the design intent. 2. It dispatches implementation to codex in the background and keeps planning or validating in parallel instead of sitting and waiting. 3. The diff comes back. The agent reviews it, commits, and opens PRs from the main session. codex never touches git. 4. Frontend gets a visual validation loop: codex types the UI, the premium model runs the app, screenshots it, judges it against the design intent, and re-dispatches with concrete feedback until it looks right.
The escape hatch
The skill forbids predicting that codex will fail ("this is too hard for it"). Struggle has to be observed. But two strikes and it's over: if a re-dispatch with corrective feedback still misses the acceptance criteria, the premium model writes the code itself and salvages what it can from codex's diff.
License
MIT
Related skills
FAQ
What does arbitrage keep in the Claude session versus dispatch?
It keeps planning, specs, architecture, visual validation, debugging analysis and git in the session, and dispatches all code-writing to codex.
What happens when codex struggles?
A two-strike escape hatch: after a re-dispatch with corrective feedback still fails the acceptance criteria, you take over and write the code yourself.