SoL-Pi: Four Opt-In Efficiency Mechanisms for the Pi Coding Agent

The repeated work SoL-Pi targets in long agent runs

Long-running coding agents accumulate work that nobody asked for twice. The README names four patterns: a file edit is followed by a predictable validation command, large tool results are replayed after their first use, completed subtasks stay in active context, and a frontier model spends a full request reading a log when only a few lines affect the next decision. Each pattern costs tokens or turns without adding information the agent still needs.

SoL-Pi is aimed at people who run Pi for tasks long enough that this overhead matters. It ships as a standalone extension for Pi, not a fork, and the README is explicit that it is not an official distribution of Pi. The framing comes from the project's own research question: before scaling agent loops, can the harness itself be made more efficient? The standalone release contains the four mechanisms that survived that search.

The constraint the project set for itself matters more than the mechanism list. The README describes the search as constrained efficiency: reducing token traffic, inference work and agent turns without stopping early, skipping verification or hiding evidence. That is a narrower goal than general cost reduction, and it explains why every mechanism is opt-in.

Action Fusion, ObservationPack, the reducer and Online Context Compact

The four mechanisms sit at different points in the harness. Action Fusion works at the tool layer: an edit or write can run its follow-up validation command in the same tool call, which removes the extra turn between an edit and its check. ObservationPack works at the observation layer: repeated large text results become stable handles with exact paged recall, so a result is fetched when needed rather than replayed.

Evidence-Preserving Reducer works at the delegation layer. Long diagnostic logs become compact receipts, but only when every retained quotation matches the archived source. That condition is the interesting part. A reducer that paraphrases freely is unusable for debugging, so the mechanism refuses to produce a receipt whose quotes cannot be traced back. The README states that reducer failures leave the original result unchanged.

Online Context Compact works at the context layer. Completed plan steps become candidate points for Pi's native compaction, subject to economic and window-pressure checks, and after a successful compaction Pi continues the task in a new turn. SoL-Pi does not implement its own compaction; it decides when to invoke Pi's.

The mechanisms compose through Pi's public extension APIs, and the project commits to four rules: no Pi patches, explicit opt-in, evidence preservation, and leaving authentication, provider URLs, the main model and shell behavior under Pi's control. The package.json confirms the integration path: it declares a pi.extensions entry pointing at ./src/sol-pi/index.ts and lists the Pi packages as peer dependencies. Because those are peer dependencies rather than bundled code, SoL-Pi expects the Pi release to be present in the environment rather than vendored inside it.

Installing SoL-Pi on Pi 0.85.1 and writing a first config

The README pins a specific Pi release, so install that first. Node.js 22.19 or newer and npm are the stated requirements, and package.json sets the same engine floor at >=22.19.0.

npm install --global @earendil-works/pi-coding-agent@0.85.1

Then install the extension from the repository. The README gives two forms, a global install and a project-local one with an explicit approval flag.

pi install git:github.com/NVlabs/SoL-Pi

pi install git:github.com/NVlabs/SoL-Pi --local --approve

Configuration lives in a single effective sol-pi.json. With the official Pi distribution, SoL-Pi looks first at .pi/sol-pi.json in the current project when the project is trusted and the file exists, and otherwise at ~/.pi/agent/sol-pi.json. If neither exists, built-in defaults apply. The two files are not merged, so a project-level file fully replaces the user-level one rather than extending it.

The README's conservative starting configuration enables only the two local mechanisms, which make no additional model calls and do not stop an active run.

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

There are no dedicated environment variables. Feature flags, the reducer provider and model route, and the compaction ratio all live in sol-pi.json, and sol-pi.example.json is the template listing every key. Automated environments are pointed at agents-install.md, which describes an all-enabled configuration checked with scripts/check-sol-pi-config.mjs --require-all-enabled.

Archives that outlive the session and a reducer that can leave the machine

The storage model is the part most likely to surprise an operator. ObservationPack and Evidence-Preserving Reducer write session-specific archives under <session-directory>/sol-pi/<session-id>/, split into observation-pack/ and evidence-preserving-reducer/ subdirectories. The README states plainly that archived copies remain local and are not automatically deleted when the Pi session ends. There is no documented retention policy, no size cap and no cleanup command in the README. On a busy repository with large tool outputs, that directory grows on its own.

The reducer carries a second concern. It may send eligible diagnostic-log content to its configured reducer model using Pi-managed authentication. The README tells readers to review SECURITY.md before enabling it and warns against enabling remote reduction for logs that must remain local. That is a clear boundary: if your logs contain credentials, customer data or anything under a policy that forbids third-party inference, leave evidencePreservingReducer set to false. Turning it on is a data-egress decision, not a performance tweak.

Online Context Compact has a behavioral edge worth knowing before you rely on it. It stores state in Pi's session log, and after a successful compaction it starts a new turn and continues the active task automatically. Cancelling the run or exiting Pi does not trigger that automatic continuation. So an interrupted run resumes differently from a completed compaction, and anyone building automation around the extension needs to account for that gap.

Where SoL-Pi is the wrong choice, and what it is not replacing

SoL-Pi is the wrong tool if you are not on Pi. It is a Pi extension, not a general agent framework, and its peer dependencies are the Pi packages. If your harness is something else, none of these four mechanisms transfer as-is, and the README does not claim they do.

It is also the wrong choice for short, single-turn tasks. The mechanisms target overhead that accumulates across a long run: repeated validation turns, replayed observations, stale completed steps. On a task that finishes in a handful of turns, there is little to compress and the configuration surface is pure cost. The README's own conservative default reflects this, enabling the two mechanisms that add no model calls and leaving the other two off.

A more useful comparison is against the alternative of doing nothing and tuning Pi directly. Pi already exposes native compaction, and Online Context Compact does not replace it; SoL-Pi decides when to trigger it. If you have already tuned your Pi configuration and are satisfied with token traffic, SoL-Pi adds a second configuration file, a session archive directory and, for the reducer, a new model route to audit. The honest difference between SoL-Pi and hand-tuning Pi is that SoL-Pi packages four specific interventions with evidence-preservation rules attached, rather than leaving you to write the same logic against Pi's APIs yourself. Whether that packaging is worth a dependency depends on how much of your cost is in the four patterns the README names.

Maintenance, upgrade cost and the licence position

The repository is not archived, and the last push was on 2026-09-16. There are no retrieved releases, and package.json still carries version 0.1.0 with private set to true, so the project is consumed from git rather than from a published npm package. That matters for upgrades: pi install git:github.com/NVlabs/SoL-Pi tracks the repository, and there is no documented version pinning for the extension itself, while the Pi side is pinned at 0.85.1 in the install instructions and in devDependencies.

The Pi version pin is the real upgrade constraint. SoL-Pi declares the Pi packages as peer dependencies with a wildcard range, but the README installs and tests against 0.85.1, and docs/compatibility.md exists specifically to document supported Pi APIs. Upgrading Pi ahead of that document is the risk to manage. The repository ships a check script, npm run check runs typecheck, tests and a pack dry-run, and scripts/check-sol-pi-config.mjs validates a configuration; those are the tools the project provides for verifying an environment after a change.

On licensing, the repository is MIT, and THIRD_PARTY_NOTICES.md is present at the top level, which is where bundled dependency notices would live. The extension is distributed as source through git, so anyone redistributing it should read LICENSE and THIRD_PARTY_NOTICES.md rather than assume the MIT label covers every dependency. This is a description of what the repository contains, not legal advice.

Editorial conclusion

Adopt SoL-Pi if you already run Pi 0.85.1 and want to cut repeated validation turns and context replay without patching Pi itself; the conservative configuration enables only the two local mechanisms. Do not enable it if your diagnostic logs must stay local, because Evidence-Preserving Reducer can send eligible log content to a configured reducer model. Before enabling anything beyond Action Fusion and ObservationPack, verify the config search order in docs/configuration.md, confirm which of .pi/sol-pi.json or ~/.pi/agent/sol-pi.json your setup actually reads, and check that scripts/check-sol-pi-config.mjs passes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NVlabs/SoL-Pi on GitHub
4. Project website
5. README