phistory: an hourly archive of what agent CLIs send as a system prompt

Captures happen without the model provider ever being called

The mechanism is the part that makes this safe to run hourly against fifteen CLIs. For each supported release, Phistory installs the exact CLI package and runs each configured snapshot through a capture tool, and that tool intercepts the prompt-bearing HTTP request instead of letting it reach the real provider. So a capture costs nothing, needs no API key, and cannot vary with model output. What lands in the archive is the request the CLI would have sent, which is the artifact people actually want when a prompt changes. The stored shape is a directory per agent, version and variant holding three files: `prompt.md`, `trace.jsonl` and `meta.json`. The rendered prompt is generated from the archived trace rather than captured separately, and the point of that is completeness. Every block of the request survives into it, including each system block with its cache boundary, the reminder blocks, and system messages that are interleaved with the conversation rather than sitting at the top. A tool that rendered only the leading system block would quietly lose the parts that differ most between vendors.

Only three agents have more snapshots than versions

The capture table carries more information than the version numbers do, if you compare the two right-hand columns. Claude Code has 431 versions and 742 snapshots. Codex CLI has 100 versions and 158 snapshots. DeepSeek Harness has 14 versions and 75 snapshots. Every other agent in the table has exactly one snapshot per version: 57 for Antigravity, 139 for Grok Build, 39 for MiniMax Code, 79 for Kimi Code, 15 for MiMo Code, 78 for OpenClaw, 34 for Hermes, 23 for Kimi CLI, 118 for opencode, 52 for Pi, 122 for Oh My Pi. The ratio is what tells you where variants exist. A snapshot count above the version count means an agent was captured more than once per release, which happens when a CLI exposes several models or several surfaces worth recording separately. The documented example is Codex, whose variants include the default surface plus named model variants. So the archive is deeper for the three agents that offer a choice, and a single track for the rest.

The default variant runs the CLI the way its users do

A capture can be faked by calling an internal function, and the value of this archive depends on not doing that. The default snapshot runs each CLI the way its users run it, through a real terminal when the CLI ships one. Selected models or alternative surfaces are stored as additional variants, which is the mechanism that produces the higher snapshot counts. The agent list also shows how much variety there is to support, and one entry breaks the pattern. Most of the tracked agents are npm packages, with names like `@anthropic-ai/claude-code`, `@openai/codex`, `@deepseek-ai/dsh`, `@xai-official/grok`, `@moonshot-ai/kimi-code`, `@mimo-ai/cli`, `@earendil-works/pi-coding-agent` and `@oh-my-pi/pi-coding-agent`. MiniMax Code is a desktop application obtained from an official download instead, which is why the real-terminal rule and the variant rule both have to flex for it. There is also a Claude Tag entry in the capture table that does not appear in the supported-agent list, so the table carries at least one target the list does not describe.

A scheduled workflow commits new snapshots every hour

Freshness is handled by automation rather than by a maintainer. GitHub Actions checks the automatically tracked CLI releases every hour and commits new snapshots when they appear, and the readme repeats the schedule as a check for new releases hourly alongside an archive timestamp. That design has an obvious consequence for anyone citing the archive: the contents change under you, and a diff you publish today may describe a snapshot that no longer exists tomorrow. It also means the project itself has no release cycle of its own. There are no GitHub releases for the repository, and the manifest carries a placeholder version, so what version a consumer is running has to come from the commit rather than from a tag. What is versioned here is the CLIs, not Phistory. Reading that distinction correctly matters if you automate anything against it, since a tool that assumes stable tags will find none.

The single runtime dependency tracks another repository's main branch

Phistory has one dependency, and the way it is pinned is worth reading twice:

[project]
name = "phistory"
version = "0.1.0"
description = "Automatically archived system prompt snapshots and diffs for agent CLIs."
readme = "README.md"
requires-python = ">=3.11"
license = "MIT"
authors = [{ name = "WEIFENG2333" }]
dependencies = [
    "claude-tap @ git+https://github.com/WEIFENG2333/claude-tap.git@main",
]

That single entry is a git reference to the main branch of another repository by the same author, and the build configuration has to explicitly allow direct references for it to install at all. The practical effect is that `uv sync` does not install a fixed release, it installs whatever that branch points at on the day you run it, so two people syncing a week apart can end up with different capture behaviour. The lock file is what makes it reproducible, which is why the local setup command is the one that syncs all groups from the lock rather than resolving fresh. The distribution is narrow in a way that matches the design. The wheel ships only the `phistory` package, and the source distribution includes the package, the tests, both readmes, the manifest and the lock file. The archive itself is not in either, which is right, since the archive is already published as the repository.

The viewer is a static site served from the repository

The hosting arrangement explains why the project is catalogued as HTML rather than Python. At the root there is a `CNAME` file for the custom domain, a `robots.txt`, a `sitemap.xml`, a `.nojekyll` file that tells GitHub Pages to serve the tree as-is instead of running it through Jekyll, and a `llms.txt` for agents. The captures live in the repository under `captures/`, which is what makes a static viewer possible with no server to keep running. The hosted viewer at phistory.cc is the product, and the local commands are described as being for local development, capture reproduction, historical backfills and regenerating generated files. One deliberate feature of the viewer is that Chinese translations are available for runtime prompt diffs and for trace fields, with unchanged paragraphs reusing shared translations across versions and the original evidence preserved underneath. Two documentation files cover that: one on translation setup and storage, one on translation evaluation.

Capture and backfill are separate commands on purpose

The command surface is small and the separation matters for cost and time. A capture grabs the latest release and every configured snapshot for a set of agents, and the agent list is passed explicitly rather than discovered:

# Capture the latest release and every configured snapshot for each CLI.
uv run phistory capture --latest --agents claude-code,codex,dsh,antigravity,grok,minimax-code,kimi-code,mimo,openclaw,hermes,kimi,opencode,pi,omp

That single command is the expensive one, since it installs fifteen CLIs and records each of them. Narrowing it to one agent and a list of variants is how you add a model variant without recapturing everything else, which is exactly what the Codex example shows. Backfilling is a third command with its own range syntax, taking one agent and a from and to bound, so the 431 archived versions of Claude Code were produced by many small runs rather than one long one. The project also names the tool the commands sit on, a uv-based Python setup, and the manifest requires Python 3.11 or newer. Development dependencies are deliberately minimal, just a test runner and a linter, with the linter configured for a 120 character line length and the line-length rule itself switched off, which is the usual way to keep long URLs readable.

Editorial conclusion

Phistory is useful in two specific ways: as a record you can cite when a prompt change explains a behaviour change, and as a diff surface for seeing how competing agent vendors structure the same problems. Three cautions. The archive is generated output, so treat a snapshot as evidence of one capture rather than as the vendor's specification, and read the trace file rather than the rendered prompt when precision matters. Its one runtime dependency is pinned to the main branch of another repository, so a fresh sync can change behaviour under you, which is the same reason a CLI changing hourly will occasionally surprise you. And translations exist alongside the original text; the original is preserved, so use the translation for reading and the trace for evidence.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository