SpineCodex

Why SpineCodex

SpineCodex is an enhanced, independently maintained version of the OpenAI Codex CLI for complex, long-running software engineering tasks. It inherits your existing Codex configuration and works out of the box. Compared with Codex, it resolves 89% more tasks at 27% lower total cost on SWE-Milestone and extends the effective working context by up to 10×. It also improves the average score by 10.8 points on ProgramBench and the mean score by 9.2 points on FrontierSWE.

Get started

Just install and run—SpineCodex automatically inherits your existing Codex configuration and works out of the box.

npm install -g @spinejit/spine-codex@latest
spine-codex

SpineJIT transparently manages context with no user intervention; after sending your first task, run /spine-tree to confirm it is working. Experimental Spine Spawn (spine_spawn) and Memory Projection (spinetree_memory_projection) can be enabled via /experimental.

Codex Desktop

To use SpineCodex with the official Codex Desktop app, first quit Codex Desktop, then download the launcher for your platform:

• Windows: Keep start-spinecodex-desktop.cmd and start-spinecodex-desktop.ps1 in the same folder, then run the .cmd file.
• macOS: Run start-spinecodex-desktop.command. If needed, make it executable with chmod +x start-spinecodex-desktop.command.

The launchers use the native SpineCodex backend installed by npm and enable the Spine tree UI automatically.

Experimental features

Run /experimental to enable Spine Spawn or Memory Projection, then save and start a new conversation.

Long-horizon performance

Across three long-horizon coding benchmarks, SpineCodex delivers stronger outcomes: 1.89× resolved tasks at 27% lower total cost on SWE-Milestone, +10.80pp average score on ProgramBench, and +9.2pp mean score on FrontierSWE.

SWE-Milestone (ICML 2026)

Long-horizon software development · 80 milestones · GPT-5.6 · sol high

1.89× resolved tasks at 27% lower total cost.

ProgramBench

Whole-repo program reconstruction · Random sample: 50 of 200 tasks · GPT-5.6 · Sol high · conservative cost estimate

+10.80pp average score and 3.5× high-scoring tasks.

FrontierSWE

Ultra-long-horizon coding · 9-task evaluation · GPT-5.6 · high · estimated API cost per trial

+9.2pp mean score and +8.9pp best score.

How SpineJIT works

Agent Morphogenesis: Each task shapes its own context and execution through just-in-time context-tree compilation and recursive subagent scaling.

TL;DR: SpineJIT replaces the live suffix of a context with shorter memory, while keeping the prefix unchanged so it can continue to hit the prompt cache.

To control this suffix replacement precisely, SpineJIT is implemented as a just-in-time compilation and context-mapping pipeline:

$$ \text{context messages} \rightarrow \text{Spine tokens} \rightarrow \text{SpineTree (ParseStack)} \rightarrow \text{new context} $$

The pipeline has two main stages.

1. JIT-compile context into a SpineTree

SpineJIT treats a context $C$---a message list, or simply a sentence whose characters are messages---as a stream to compile.

At each sampling boundary, it turns newly appended messages and control events into Spine tokens and updates a live LR(0) ParseStack:

SpineJIT uses four token kinds:

$$ \Sigma_{\mathrm{Spine}} = {\mathrm{Message},\ \mathrm{Open},\ \mathrm{Close},\ \mathrm{SpineSpawnNode}} $$

Message represents a raw context item. Open, Close, and SpineSpawnNode are special tokens emitted by SpineJIT at the corresponding sampling boundaries.

$$ \begin{aligned} \mathrm{SpineTree} &\to \mathrm{Nodes}\ \mathrm{End} \ \mathrm{Nodes} &\to \mathrm{Node} \mid \mathrm{Nodes}\ \mathrm{Node} \ \mathrm{Node} &\to \mathrm{Message} \mid \mathrm{SpineTreeNode} \ \mathrm{SpineTreeNode} &\to \mathrm{Open}\ \mathrm{Nodes}\ \mathrm{Close} \mid \mathrm{SpineSpawnNode} \end{aligned} $$

End is only the logical end of a session; a live session never emits it. Therefore, the ParseStack is the live SpineTree, and the reduction Open Nodes Close -> SpineTreeNode turns a closed subtree into one node.

In short, SpineJIT uses LR(0) JIT compilation to map context $C$ to a Spine Tree $PS$:

$$ PS = \mathrm{compile}(C) $$

2. Map the SpineTree into a new context

The structured SpineTree can now be mapped into a shorter context while preserving its stable prefix. For ParseStack $PS$, define:

$$ C' = f(PS) = \prod_{i=0}^{n} h(PS[i]) $$

$$ h(X) = \begin{cases} \prod_{x \in X} h(x), & X = \mathrm{Nodes} \ \mathrm{raw}(X), & X = \mathrm{Message} \ \mathrm{memory}(X), & X = \mathrm{SpineTreeNode} \ \mathrm{spine\_node\_desc}(X), & X = \mathrm{Open} \end{cases} $$

Here, $\prod$ means ordered concatenation.

The mapping is deliberately small:

• Message keeps its original content through $\mathrm{raw}(X)$.
• A closed SpineTreeNode is replaced by its shorter $\mathrm{memory}(X)$.
• An unmatched Open is represented by a concise $\mathrm{spine\_node\_desc}(X)$, helping the LLM delimit the currently live Spine node.

As parsing progresses, completed work in the context suffix is reduced into a SpineTreeNode and then projected as memory. Earlier context remains unchanged:

$$ \mathrm{prefix} \cdot \mathrm{suffix} \longrightarrow \mathrm{prefix} \cdot \mathrm{memory} $$

This is th