SoL-Pi writes archives to the temp directory and keeps them after the session ends

The readme title and the paper title do not match

The page header and the paper link say different things.

The header calls the project a scaling of auto-research loops for efficient agent harnesses, plural. The paper it links to is titled with a recursive qualifier added in front, and with the noun in the singular. So the same artefact has a title with a word added, a word added again, and a noun changed, between the top of the readme and the citation one screen down.

That is a small thing, but in a project whose whole subject is careful measurement it is the kind of small thing that suggests the header was written for the repository and the paper title was set separately.

The rest of the citation apparatus is more disciplined. There is a blog at a project documentation address, described as the place for technical detail, design rationale and the core insights, including how auto-research led to the four mechanisms and how they work. There is the paper. There is a licence link and a configuration document link in the header navigation.

So the project publishes three levels of detail: this page for scope and installation, a blog for reasoning, and a paper. That is a reasonable structure and worth knowing before you decide which one to read.

Four mechanisms, and the safe configuration turns on two

The extension's entire value proposition is four mechanisms, and the readme is careful about which ones are safe to start with.

The first acts on tools: an edit or a write can run its follow-up validation command in the same tool call, which removes a whole model turn from the loop. The second acts on observations: a large text result that gets used more than once becomes a stable handle with exact paged recall, so it is not replayed in full.

The third acts on delegation: long diagnostic logs become compact receipts, and the condition attached is the important part. The reduction happens only when every retained quotation matches the archived source. The fourth acts on context: completed plan steps become candidate points for the host's own compaction, subject to economic and window-pressure checks, and after a successful compaction the host continues the task in a new turn.

Then there is a suggested configuration, and it is conservative. It enables the first two and leaves the third and fourth off, with the stated reason that it enables only the two local mechanisms that make no additional model calls and do not stop an active run.

That is the most useful thing in the readme: it tells you which mechanisms cost money and which ones change control flow, and it defaults you to the free ones.

Archives are written to the temp directory and kept after the session ends

There is a storage section, and it is the most careful writing in the document.

The two mechanisms that archive material store session-specific copies under the session directory, in one subdirectory per mechanism. The readme then says the archived copies remain local and are not automatically deleted when the session ends.

Then the harder case. If the host is run with no session directory, either through a flag or through an in-memory session manager, the extension creates a private directory under the operating system's temporary location instead, named with the session identifier and a random suffix, and shares it between the two mechanisms for the lifetime of the loaded extension.

The disclosure about that path is unusually complete. Those modes disable the host's own session-log persistence. The extension still writes archive files so that exact recall works. The temporary archives are also retained after the session or the worker exits, so that a caller can still read evidence it was told about. Their eventual cleanup follows the host's temporary-file policy or the caller's cleanup, and they are not guaranteed to survive system cleanup or to support session recovery.

So the honest summary is: enabling the free mechanisms means keeping copies of tool output on disk, in a place the operating system may delete and nothing in this extension will.

One mechanism can send your diagnostic logs to a model

Three of the four mechanisms are local. The third one is not, and the readme isolates it.

The reducer may send eligible diagnostic-log content to its configured reducer model, using the host's managed authentication rather than credentials of its own. The guidance is two sentences and both are warnings: read the security document before enabling it, and do not enable remote reduction for logs that must remain local.

What makes this acceptable rather than alarming is the condition already noted. The reduction only happens when every retained quotation matches the archived source, so the mechanism has a correctness test rather than a trust boundary crossed first. What makes it worth flagging anyway is that a percentage of a diagnostic log leaving the machine is a different kind of decision from turning on a cache.

The configuration keeps it separable. Feature flags, the provider and model route for the reducer, and the compaction ratio are all set in one configuration file, there are no dedicated environment variables, and a template file in the repository root lists every key with a separate document carrying the full schema.

The fourth mechanism has its own disclosure, of a different kind. It stores its state in the host's session log, and after a successful compaction it starts a new turn and continues the active task automatically. Cancelling the run or exiting does not trigger continuation.

The entry point is TypeScript source and there is no build step

The package manifest is worth reading as a design decision rather than as a list.

There is no build script. There are three: run the tests, typecheck without emitting, and a combined check that does both of those and then packs the package in dry-run mode. So the third one verifies that what would be published matches the allowlist, which is a self-check on packaging that most projects skip.

And the extension entry point declared in the manifest is a path to a TypeScript source file inside the source directory. Not a compiled bundle. The package ships source and lets the host load it.

That is coherent with the rest of the design. This extension is meant to sit on top of an unmodified host release that is itself installed from a package feed at a specific version, so there is no compiled artefact to keep in step with anything.

The published file list is an explicit allowlist of eleven entries: the extension source directory, an assets directory, two documents, one checking script, and six text files at the root. Everything else in the repository is development-only.

The manifest also marks the package private, which is consistent with a project distributed through the host's own install command rather than through a registry.

Peer dependencies are wildcards, development dependencies are exact

The dependency block tells you what this project assumes about the future and what it assumes about today.

Five packages are declared as peer dependencies, and every one of them is a wildcard. They are the host's agent core, its AI layer, its coding agent, its terminal interface, and a schema library.

The same five packages appear as development dependencies, and every one of those is pinned to an exact version. Four are at the same release as the host the readme tells you to install, and one is a schema library at its own exact version. Node types and the compiler are pinned too.

So the project declares that it will work with any future version of its host, and develops against exactly one. That is a defensible split, and it is the shape you would expect from an extension that has to survive a host releasing often.

The risk it carries is the ordinary one: a wildcard peer dependency means an incompatible host release can install cleanly and fail at load time. What mitigates it is on the readme rather than in the manifest. The requirements section names a host package at an exact version and calls it the tested release, the install command pins that same version, and there is a compatibility document in the published files.

There are also three transitive packages pinned by override, which is the usual way to carry security fixes for dependencies you do not control.

Project configuration replaces user configuration rather than merging

The install path is three commands, and the version is pinned in two of them:

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

A project-local install uses the same install command with a scope flag and an approval flag, and only the global one is a bare command.

Configuration is one file, and the resolution rule has a consequence that is easy to miss.

The extension looks for a file with a fixed name in two places, in order: in the current project, if the project is trusted and the file exists; otherwise in the agent configuration directory under the home directory. If neither exists, built-in defaults apply.

The consequence: the project-level file takes precedence over the user-level file, and the two are not merged.

That means a user who sets flags once in their home directory and then clones a project containing its own configuration file silently loses their settings for that project. There is no error, no warning and no merge, and the readme states the non-merge in a single clause in the middle of a paragraph.

The trusted-project condition is the other detail. The project-level file is only read if the project is trusted, which means an untrusted project cannot inject configuration into your agent. That is a sensible default and it is the reason the non-merge is tolerable: the file that overrides yours had to pass a trust check to get read at all.

Everything else about configuration is well signposted. A version field in the schema, an example template in the repository root, a full schema document, and a separate document described as the canonical installation and configuration protocol for coding agents and automated environments, with an all-enabled configuration checked by a script named for exactly that.

Editorial conclusion

This suits someone running long coding-agent sessions who is losing money to repeated validation commands and to models re-reading logs, and who is willing to read the configuration schema before switching anything on. It does not suit someone who wants the gains by default, because every mechanism is off when configuration is absent, and it does not suit a team whose logs must stay on the machine without reading the security document first. Before you enable anything, check three things: which of the two local mechanisms you want, since they need no extra model calls; what the compaction mechanism does to session continuity, since it starts a new turn and continues automatically; and where your archive files will land, particularly if you run without a session directory, because they then go to a temporary location and are not removed when the session ends.

Frequently asked questions

Official sources

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