#2174·openclaude

Establish reproducible long-session performance benchmarks

Author: chioarubCreated Aug 25, 2026Updated Aug 25, 2026

Problem

OpenClaude has focused startup and long-session safeguards, but it does not have a reproducible developer benchmark for session discovery, transcript restoration, branch reconstruction, compaction replay, snipping, or large persisted tool results. That makes it difficult to distinguish a meaningful regression from cache state, fixture differences, or renderer noise.

A local proof of concept generated deterministic synthetic transcripts with production session writers and schemas. It covered 100 to 50,000 records, a nearly 100 MB compacted transcript, dead branches, repeated compaction boundaries, realistic snipping, and 100 persisted tool-result rounds. It did not read user sessions or contact a provider.

The results suggest the storage methodology is stable enough to turn into focused developer tooling. The terminal, memory, and shutdown probes still need tighter measurement contracts and should not be part of the first change.

Proposed first scope

  • Add a deterministic seeded fixture generator that uses production session schemas and writer helpers.
  • Isolate every run under temporary config, cache, and temporary roots.
  • Cover session discovery, progressive enrichment, transcript scanning, active parent-chain reconstruction, compaction replay, snipping replay, persisted tool-result indirection, and exact resume.
  • Include a valid active-session case near the current resume payload bound and an expected bounded-rejection case above it.
  • Build once before timing and exclude fixture creation and module import.
  • Report median, P25, P75, IQR, MAD, min, max, and P95 when the sample count supports P95.
  • Record commit, package and runtime versions, OS, architecture, CPU, bundle size, seed, cache-state label, and relevant flags.
  • Emit machine-readable JSON and a concise human summary.
  • Prove fixture determinism and remove all temporary data in finally.
  • Make no provider request and enforce no CI performance threshold.

Explicit exclusions

  • No production optimization.
  • No session format change, database, or index.
  • No PTY dependency.
  • No cross-platform terminal threshold.
  • No production telemetry.
  • No user transcript ingestion.
  • No provider-backed compaction request.
  • No bundled profiler dependency.
  • No root or web dependency change.

Acceptance criteria

  • Repeating fixture generation with the same seed produces identical bytes, record counts, and hashes.
  • Every fixture is accepted by current production readers or is rejected by an explicitly asserted production safety bound.
  • Current behavior has focused correctness assertions for branches, compaction, snipping, tool-result indirection, and cleanup.
  • Benchmark output distinguishes same-process samples from fresh-process observations and labels ordinary filesystem cache state.
  • P95 is omitted when the repetition count is too small.
  • The suite leaves no fixture root, listener, timer, or child process behind.
  • Documentation explains how to reproduce results and why results from different machines are not directly comparable.

Maintainer direction requested

Would maintainers approve this narrow storage and restore benchmark as developer tooling before implementation begins? If so, should it live under scripts/ with focused tests under the existing session-storage test area, and should it remain opt-in rather than run in default CI?