Skip to content

Releases: shaneconner/fold

pi-fold 4.2.8

Choose a tag to compare

@shaneconner shaneconner released this 09 Oct 14:24

pi-fold 4.2.8

Patch release.

  • Peek omits assistant thinking blocks and their opaque signatures before serialization and pagination, after verifying the original source. Visible text, tool calls and tool results remain unchanged. Pi's saved transcript and exact expand/recovery remain intact.
  • Peek results identify the history view and report how many thinking blocks were omitted. Tool guidance and documentation describe the behavior and Anthropic compatibility limits.

Thanks to @kvyb for the detailed report in #10. This removes a confirmed source of thinking replay as ordinary tool-result text. The reported Claude Opus 5.5 refusal through 9router has not been reproduced against a provider; #10 remains open for confirmation on the affected route.

Validation: lint, 82 runtime gates with 9,794 assertions, 118 experiment gates, and six disposable offline SDK scenarios on Pi 1.0.0 and 1.0.4 covering simulated refusals, retries, durable reads and reload. No private live sessions or paid provider calls. Genuine benchmark re-extraction preserves every finding and all 102 evidence rows.

pi-fold 4.2.7

Choose a tag to compare

@shaneconner shaneconner released this 07 Oct 20:44

pi-fold 4.2.7

Patch release.

  • Forked sessions retain inherited folds, pending marks and dependent state, with child-owned checkpoints and historical parent measurement receipts. Thanks to @ShangHong-CAI for PR #9.
  • Restore detects a provider receipt ahead of the ledger, retains existing folds and raw history, and rebuilds eligible folds on the next context pass. Missing ledger changes are reported rather than invented.
  • Recovery and explicit /fold can size their fill when provider usage is unavailable. Ordinary automatic folding still requires a valid provider measurement; estimates never veto a request.
  • Rollback notices describe the pending attempt. Failed recovery receipts accurately report transmission, and a failed retry queue is reported as not reissued.
  • With auto-compaction off, the session tree stays intact and /fold supports explicit lossless salvage before retrying.

Validation: 81 runtime gates (9,767 assertions), lint, 118 experiment gates, on-disk SDK fork and reload, and offline SDK overflow recovery. The benchmark findings and all 102 carriage rows remain unchanged after genuine re-extraction.

The original long-session data-loss incident in #3 has not been reproduced end to end and remains open for investigation. This release fixes the demonstrated recovery and reporting gaps.

pi-fold 4.2.6

Choose a tag to compare

@shaneconner shaneconner released this 05 Oct 17:30

pi-fold 4.2.6

Patch release.

  • Pi's system messages stay out of the window before the first context event. Pi never shows extensions its system-prompt messages, but /fold and /fold-editor run right after a restart used a view that included them, so folds crossing a system-prompt change looked broken and a commit could drop most of a session's folds. That view now leaves them out, and a fold that already contains one still holds.
  • A compaction check before the first context event no longer stops folding. After failed retries Pi estimates the whole raw transcript and may try to compact before pi-fold has seen any context; pi-fold used to suspend folding and let native compaction run, which could exhaust memory on a large session. That compaction is now blocked and folding stays on.

No new options, and no change to what folds or when.

pi-fold 4.2.5

Choose a tag to compare

@shaneconner shaneconner released this 05 Oct 13:17

pi-fold 4.2.5

Patch release.

  • Folds find their entries by Pi's own entry ids. A folded entry used to be located only while its content hash matched the one recorded when it was folded, so one message whose saved bytes differed from the live copy could unseat a whole fold tree after a restart, and the next commit then dropped every fold beneath it. A resumed session could send its full raw transcript and be rejected as too long. A fold now stands over the entry Pi holds, and a changed entry is logged once as a context.drift event.

No new options, and no change to what folds or when.

pi-fold 4.2.4

Choose a tag to compare

@shaneconner shaneconner released this 05 Oct 01:33

pi-fold 4.2.4

Patch release.

  • The chat mirrors the model's window. Each fold the model holds collapsed is one row in Pi's chat, and its messages return in place when the model expands it. Pi only clears its chat on native compaction, which pi-fold replaces, so a long folded session no longer keeps every message on screen.
  • The fold bar reads Pi's context usage on the same key Pi's footer uses, instead of re-reading it on every frame. One reading rebuilds the whole session projection, about 29 ms on a 16,000-entry session.

No new options, and no change to what folds or when.

pi-fold 4.2.3

Choose a tag to compare

@shaneconner shaneconner released this 03 Oct 12:54

pi-fold 4.2.3

Floor the fold bar's usage label to match pi-cc's footer. Use Pi's original getContextUsage() percentage directly, avoiding floating-point round-trip drift at values such as 29%, 57% and 58%.

Apply the same formatting to live, stale, stopped and widget-less usage labels. Preserve unrounded bar fill, nearest commit-point labels and all folding thresholds and trigger timing.

Extend gate 177 for fractional and integer-edge percentages, unchanged fill and all display variants. Update the README and genuinely re-extract the sealed evidence with unchanged research findings.

Validation: lint, all 72 runtime gates, all 118 experiment gates, README/DOI checks and the exact 24-file package allowlist.

pi-fold 4.2.2

Choose a tag to compare

@shaneconner shaneconner released this 03 Oct 11:49

pi-fold 4.2.2

Use Pi's getContextUsage() directly for the live fold-bar reading, refreshed on every render. Aim and commit markers use the same full-window scale; serving-budget trigger timing is unchanged.

Unknown Pi usage stays unmeasured, including after native compaction. The widget-less status fallback uses the same source, and detailed status/editor views explicitly label their separate serving headroom as Budget.

Document the default folding allowance without claiming it is a measured provider output reservation. Correct the README's token diagram and refresh the renderer-backed bar illustrations. No new options, provider ceilings, saved formats or research findings.

Validation: clean install, lint, 72 runtime gates (9,307 assertions), 118 experiment gates, authentic sealed-corpus re-extraction with unchanged findings, README/DOI checks and the exact 24-file package allowlist. New gate 177 pins direct host usage, render-time refresh, unknown states, coordinate conversion and unchanged trigger behavior.

pi-fold 4.2.1

Choose a tag to compare

@shaneconner shaneconner released this 03 Oct 10:33

pi-fold 4.2.1

Pi 1.0 compatibility patch; folding behavior and saved formats are unchanged.

  • Declare Pi-supplied runtime packages as wildcard peers, including the pi-tui fix from PR #6, and update the development lock to Pi 1.0.0.
  • Test actual folding, exact retrieval, provider projection and session reload through a real offline Pi 1.0 SDK session.
  • Update the experiment's compaction source check for Pi 1.0 and prove it fails if the post-run compaction call is removed.
  • Reproduce the hidden-mass evidence from the checksum-verified archival supplement. All findings are unchanged; only the runtime binding and extract digest are refreshed.
  • Document Pi 1.0's Node 22.19 requirement while retaining support for older Pi hosts.

Validation: clean install, lint, 71 runtime gates, 118 experiment gates, README link and DOI review, and complete npm package contents review.

pi-fold 4.2.0

Choose a tag to compare

@shaneconner shaneconner released this 20 Sep 16:09

pi-fold 4.2.0

A session load no longer costs more the longer the session runs.

A load replayed every delta since the session's only checkpoint and rebuilt the whole state at each one, so the cost was the delta count times the state size: quadratic in session length. One real 2,207-delta session spent 129.6s inside the restore, against 0.6s for pi to parse the same 93MB of entries; another spent 56.1s on 1,147 deltas. Doubling a session's entries quadrupled the time. The load is not paid once either: session_start, session_tree, session_compact and a branch switch each pay it, so with doubleEscapeAction: "tree" it sat behind a keypress.

Two changes bound it. The reader restarts the replay at the NEWEST checkpoint rather than refusing a second one, and persist closes the run with a fresh checkpoint every 50 deltas, so a load walks at most 50 deltas however long the session runs. And each fold is proven once per replay instead of once per delta: recomputing 375 content addresses and rehashing 375 fold subtrees at every one of 2,207 deltas could not reach a verdict the durable record had not already settled. A fold arriving for the first time still meets the full check.

Steady-state loads on those two sessions: 4.62s and 2.75s, reaching a state identical by digest, revision and forest to what the full replay produced. Right after a checkpoint, 0.34s and 0.20s. A session already past the bound heals itself on its next durable write. A checkpoint costs bytes where a delta does not, about 11% of a session file at this cadence.

A failed restore no longer writes the checkpoint that used to latch a session dead. persistedWireVersion read 0 both for a session that never had durable state and for one this build could not read, so a restore that threw appended a second checkpoint to a branch that already had one, the reader refused exactly that, and every reload made it worse: one session reached five checkpoints and grew from 859 entries to 4,393. The write is now refused where the restore error is known.

Compatibility: reading is backward compatible and every existing session still loads. A 4.1.6 reader refuses a ledger this version writes, so downgrading suspends folding on any session that has taken a second checkpoint.

Gates 174 and 175 cover the bound and the proof; gate 173 covers the refusal. Runtime suite 70 gates.

pi-fold 4.1.6

Choose a tag to compare

@shaneconner shaneconner released this 06 Sep 17:35

pi-fold 4.1.6

The fold bar's colours are now a choice. A seventh option, palette { map, start, end }, reads the six category shades off a colour map (Batlow by default, or viridis, plasma, magma, cividis) between two positions on it, so a slice of a map or a reversed one is a keypress away. Three /fold-settings rows expose it and the bar repaints on each step. Every shade is moved away from the background, hue held, until it clears 4.5:1 on dark and light terminals.

The bar's categories are ordered by distance from compression: consolidated, span and tool folds first, then marked, raw and pinned content, with the pin at the map's far end.

The band guides are dotted marks in the band's edge cells, drawn in a deeper tone of the fill's own hue over a solid track, so the fill continues behind them and a mark cannot read as a fold edge.

The status row names only the kinds with something to count.

Gate 171 covers the palette; gate 165 covers the order, the guides, the track and the inventory. Runtime suite 66 gates, experiment suite 118.