TL;DR

SoL-Pi (NVlabs/SoL-Pi) is an MIT-licensed extension for the Pi coding agent that packages four token-efficiency mechanisms. NVIDIA did not design the mechanisms by hand: a fleet of agents proposed 152 harness changes, ran each through an auto-research loop across 535 executable environments, and only four survived a held-out validation gate. Those four are what you install.

The paper’s headline claim (arXiv 2609.20519, 2026-09-17) is that SoL-Pi keeps roughly 94% of Pi’s average score on EdgeBench while cutting token traffic by 44.7-49.0% and API cost by about one third. Against native Codex and Claude Code harnesses it uses 35-64% fewer tokens at 50-54% lower list-price cost, which NVIDIA translates to $4.36-$5.71 per hour saved versus Pi and $8.75-$13.50 per hour versus Codex/Claude Code.

Key facts:

  • License / language: MIT, TypeScript. 3,087 stars and 242 forks as of 2026-09-26, pushed the same morning
  • What it is: an extension installed with pi install git:github.com/NVlabs/SoL-Pi on top of an unmodified Pi release
  • Four mechanisms: Action Fusion (edit + validation in one tool call), ObservationPack (large tool results become paged handles), Evidence-Preserving Reducer (a cheaper model reads long logs and its quotes are verified against the archive), Online Context Compact (compaction triggered at subtask boundaries when the cache math pays off)
  • Everything is opt-in. With no sol-pi.json, SoL-Pi does nothing
  • Pinned dependency: requires @earendil-works/pi-coding-agent 0.85.1 and Node 22.19+. Pi’s current npm release is 0.87.1, so you are running one to two minor versions behind
  • Community: 322 upvotes and 44 comments on r/LocalLLaMA, split between “Action Fusion alone is worth it” and “recipe for cache misses on local models”

Verdict: the most interesting Pi extension of the year. Start with the two-mechanism conservative config NVIDIA recommends; enable the other two only for multi-hour trajectories on a paid API.

Quick reference

Repogithub.com/NVlabs/SoL-Pi
Stars / forks3,087 / 242 (2026-09-26)
LicenseMIT
LanguageTypeScript; extensions under src/sol-pi/extensions/
RequiresNode.js 22.19+, @earendil-works/[email protected]
Installpi install git:github.com/NVlabs/SoL-Pi
Config.pi/sol-pi.json (project, trusted only) or ~/.pi/agent/sol-pi.json
Paper / blogarXiv 2609.20519 · nvlabs.github.io/SoL-Pi
MaintainerNVIDIA Research (NVlabs)

What SoL-Pi is

Pi is the minimal terminal coding agent from Mario Zechner and Armin Ronacher: four tools, an extension API, few opinions. That minimalism is why NVIDIA picked it as a research substrate: a harness small enough that a change is the only variable.

SoL-Pi is the output of that research, packaged as a Pi extension that is explicitly “not an official distribution of Pi.” It ships four extensions that hook into Pi’s public tool registration, tool_result, context projection, and compaction APIs, under four rules: no Pi patches (public APIs only, nothing vendored), explicit opt-in (missing config means nothing runs), preserve evidence (originals stay on disk; a reducer failure leaves the tool result unchanged), and use Pi’s runtime choices (auth, provider URLs, main model, and shell stay with Pi; SoL-Pi reads no environment variables at all).

The repo and project blog went public around 2026-09-10, the r/LocalLLaMA thread hit 322 upvotes that evening, and the arXiv paper followed on 2026-09-17.

The deeper reason is that token spend on long agent runs has become the cost line people actually watch. The blog asks whether, over an unsupervised run of hours or days, “every token carries the work forward, or does redundancy grow with trajectory length.” NVIDIA’s answer: it grows from four predictable places: an edit followed by a predictable test command, a large tool result replayed on every request, a completed subtask still sitting in context, and a frontier model spending a whole request reading a log where only three lines mattered.

The paper treats harness search as a recursive self-improvement problem: agents build environments, other agents watch trajectories, and auto-research loops turn observations into harness changes. Only about 1 in 40 starting ideas survived validation against a held-out benchmark.

The four mechanisms

Action Fusion (tools)

Base Pi rollouts kept showing the same pair: the agent edits a file, then issues a command to build, test, or run it. The model’s decision in that middle turn is almost always “run the obvious command,” and it costs a full round trip.

Action Fusion registers replacement edit and write tools that accept an optional follow-up command. The harness applies the edit, runs the command locally, and returns one combined observation. This was the mechanism nearly everyone on Reddit agreed on: “Edit-then-validate burns a whole round trip every time it repeats. Fusing them into one tool call should be the biggest win of the four.”

ObservationPack (observations)

In base Pi, a large file read or long tool result reappears in every later request until compaction, occupying both context and prompt cache. ObservationPack archives the payload to disk under the session directory, leaves a stable handle plus a short excerpt in context, and registers an obs_recall tool for exact paged recall. The model can always get the original bytes back; it just stops paying for them on every turn.

Evidence-Preserving Reducer (delegation)

In build and test trajectories, only a few lines of a long log usually change the next decision. The reducer delegates the first read to a cheaper model, which returns a compact “receipt.” SoL-Pi then binds the receipt to the archived log and verifies that every quoted line actually appears in the source. A receipt with a fabricated quote is rejected and the frontier model sees the original log. Delegation, as the blog puts it, “no longer requires trust in a fluent summary.”

The reducer route is set with evidencePreservingReducerProvider and evidencePreservingReducerModel, resolved through Pi’s model registry with Pi-managed auth. This is the one mechanism that sends data to a second model, which is why SECURITY.md tells you not to enable it for logs that must stay local.

Online Context Compact (context)

Prompt-cache economics normally push compaction late, because a rewrite invalidates the cached prefix. Online Context Compact registers an update_plan tool, treats each completed plan step as a candidate compaction point, and only fires when expected future savings can repay the rewrite. The single knob is cacheWriteReadRatio (default 12.5): how much more a cache write costs than a cache read on your provider.

After a successful compaction it sends one hidden message with triggerTurn: true, so Pi starts a fresh turn and rebuilds its plan without you typing “continue.”

Getting started

Install the tested Pi release first. SoL-Pi’s development dependencies are pinned to 0.85.1, and the runtime Pi packages are peer dependencies, so Pi owns its own upgrades:

npm install --global @earendil-works/[email protected]
pi install git:github.com/NVlabs/SoL-Pi

Add --local --approve to the second command for a project-local install. Now create a config. NVIDIA’s own recommended starting point enables only the two local mechanisms that make no extra model calls and never interrupt a running turn:

{
  "version": 1,
  "actionFusion": true,
  "observationPack": true,
  "evidencePreservingReducer": false,
  "onlineContextCompact": false,
  "cacheWriteReadRatio": 12.5
}

Save it as ~/.pi/agent/sol-pi.json for a personal default, or .pi/sol-pi.json in a trusted project. The two files are not merged; a project file replaces the global one entirely.

To go all-in, flip the other two flags to true and add evidencePreservingReducerProvider and evidencePreservingReducerModel strings for the reducer route. Validation is strict: unknown keys, an unsupported version, malformed JSON, non-boolean flags, or a negative ratio stop the extension from loading with a direct error. A preflight script exists for automated setups:

node scripts/check-sol-pi-config.mjs \
  --config ~/.pi/agent/sol-pi.json \
  --require-all-enabled

On disk, ObservationPack and the reducer archive source material under <session-directory>/sol-pi/<session-id>/. Those archives are not deleted when the session ends.

What the numbers actually say

The paper evaluates on EdgeBench, a 51-task suite where trajectories run two to twelve hours. NVIDIA is upfront about why: on shorter benchmarks like SWE-bench or Terminal-Bench, “context replay, large tool outputs, cache writes, and extra model turns have little time to accumulate.” All comparisons ran at xhigh reasoning effort on GPT-5.6 Sol and Opus 5.

The capability floor is the part worth reading twice. Each mechanism had to keep every capability metric within a predeclared tolerance and improve at least one efficiency metric. The gate applies per mechanism, so small permitted losses stack once you combine all four: the assembled harness keeps about 94% of Pi’s score. That 6% is real. A Reddit commenter summarized the results chart as “significantly reduce cost at expense of slightly reduced performance vs original Pi,” which is exactly what the paper says.

There is one swarm result. On Anthropic’s original performance take-home (a kernel-optimization task scored in simulated cycles), one GPT-5.6 Sol coordinator directed 20 GPT-5.6 Luna workers for two hours:

ConfigurationCycles (lower is better)Model cost
Sol + 20 SoL-Pi workers1,127$60.11
Single Sol agent1,333$39.20
Sol + 20 Pi workers1,366$82.12

The SoL-Pi swarm beat the Pi swarm by 17.5% on cycles at 26.8% lower cost. The single agent was still cheapest and finished worse. Three trials is a small sample.

One independent data point exists: a r/LocalLLaMA user ran base Pi against SoL-Pi on a few DeepSWE tasks and posted a chart pointing the same direction, with smaller magnitude on short tasks.

Community reaction

The r/LocalLLaMA thread (322 points, 44 comments, 2026-09-10) is the best read on sentiment.

The top comment (79 upvotes) was relief that “there are some good developers at NVIDIA using the Pi harness and truly care about efficiency,” and that the release is MIT. The reply beneath it was the standard caution that a research team releasing open code is not corporate strategy.

The sharpest critique came from local-model users: “Seems like recipe for massive cache miss. No no for my local coding setup.” Another agreed that Online Context Compact is “micro compaction” that “Anthropic used in Claude Code, but you need some very careful implementation and provider specific to not kill caching.” Fair. The cacheWriteReadRatio default of 12.5 is tuned for frontier API caches, not a llama.cpp server.

A third thread questioned Action Fusion on training grounds: “if the tool call fails, the model has to output the entire tool call again perhaps only fixing one small typo.”

Several people were disappointed that the release is the harness the pipeline produced, not the pipeline: “rather than the actual auto-research agent-swarm pipeline itself? if so, bummer.” Correct. And the recurring question, “Can this be ported to other harnesses without major surgery, like opencode?”, has a soft answer: the mechanisms are described clearly, but the code targets Pi’s ExtensionContext and compaction API specifically.

Honest limitations

  • Version pin. SoL-Pi targets Pi 0.85.1; Pi is at 0.87.1 on npm as of 2026-09-22. Running SoL-Pi means holding Pi back or testing compatibility yourself with scripts/check-pi-compat.mjs.
  • Measured on frontier APIs only. Every headline number is GPT-5.6 Sol or Opus 5 at xhigh. No evaluation on open-weight models or local inference.
  • The 6% capability cost is real. If your bottleneck is task success rather than spend, SoL-Pi is the wrong trade.
  • The reducer sends logs to a second model. Enabling evidencePreservingReducer means diagnostic output leaves your machine. Read SECURITY.md first.
  • Local archives accumulate and are never auto-deleted.
  • Project config requires trust. A .pi/sol-pi.json in an untrusted directory is silently ignored, which is correct but confusing on first run.
  • 66 open issues at a two-week-old repo. Active, not yet stable.
  • No pipeline. You get the four survivors, not the search that found them.

Who should use SoL-Pi

Use it if you already run Pi for multi-hour unattended tasks on a paid API. The conservative two-mechanism config is close to zero-risk.

Try the full config if you run agent swarms or overnight research loops where a 30% cost cut compounds across dozens of workers, and you can tolerate a few points of lost task quality.

Skip it if you run local models through llama.cpp, Ollama, or LM Studio, since the compaction economics assume frontier-API cache pricing. Also skip it if you are on Claude Code, Codex, or Cursor and not moving to Pi, because there is no port.

Comparison with alternatives

SoL-PiPi (base)Claude Code / Codex native
Token reduction (paper)45-49% vs PibaselineSoL-Pi uses 35-64% fewer
Capability retained~94% of Pi100%SoL-Pi comparable or better on GPT-5.6 Sol
Mechanism originauto-research, held-out validatedhand-designedproprietary compaction
Opt-in per featureyes, four flagsn/ano
Local model supportuntestedyesno
LicenseMITMITclosed

The closest conceptual comparison is Claude Code’s built-in micro-compaction; SoL-Pi’s difference is that it exposes the economic decision as one configurable ratio and publishes the evaluation.

FAQ

Does SoL-Pi work with the latest Pi? Not officially. It is tested against @earendil-works/[email protected]. Newer releases may work, and node scripts/check-pi-compat.mjs will tell you, but the README instructs you to install 0.85.1.

Does SoL-Pi change my model, provider, or API keys? No. It reads no environment variables and never handles credentials. The only model-related config is the optional reducer provider and model id, which Pi resolves through its own registry and auth.

Is it safe to enable all four mechanisms? Action Fusion and ObservationPack are local and make no extra model calls. Evidence-Preserving Reducer sends log content to a second model, and Online Context Compact triggers compaction and starts a new turn on its own. NVIDIA recommends enabling those two only after reading the configuration and security docs.

How much does it actually save? On EdgeBench with GPT-5.6 Sol and Opus 5 at xhigh: 44.7-49.0% fewer recorded tokens and roughly one third lower API cost versus Pi, at about 94% of Pi’s score. NVIDIA estimates $4.36-$5.71 per hour saved versus Pi and $8.75-$13.50 per hour versus native Codex and Claude Code. Short tasks will show far less.

Can I use SoL-Pi with a local model? It will load, but there is no published evaluation on local inference, and the compaction economics assume prompt-cache pricing. If you try it, start with Action Fusion only.

Where is the auto-research pipeline? Not in this repo. The paper describes the 152-idea search, 535 training environments, and held-out EdgeBench gate, but the release is the resulting harness, not the search infrastructure.

Bottom line

SoL-Pi is a new kind of release: harness improvements found by agents, validated on a held-out benchmark, shipped as an opt-in MIT extension with the paper attached. The conservative config is worth enabling today for anyone running Pi on a paid API. The full config is a bet that a third off your token bill is worth a few points of task quality, which for overnight and swarm workloads it probably is. The main thing holding it back is the 0.85.1 pin; if NVIDIA tracks Pi releases, this becomes a default install.

Sources