working-activity: a lively Working line for pi CLI and DeepSeek Harness

What working-activity actually replaces

A coding agent's status line is the only part of the interface that is visible while you wait. In pi CLI it says Working and animates. That tells you the process is alive and nothing else. This extension listens to the agent's tool events and rewrites that line with the tool being executed, the file or command involved, and how long it has been running.

The README frames the goal as making the working line "come alive", and lists the ingredients: real tool activity, progress read from structured tool output, playful Chinese phrases, a rare rainbow animation, model self-narration and a context warning. The audience is people who keep a pi session open for long stretches and want to know whether the agent is reading files, running tests or stuck.

It is a community project, not an official one. The author is chimney and the repository states plainly that it is community-produced and unofficial. The licence is MIT. The same idea is implemented twice, once for pi CLI and once for DeepSeek Harness, and the two npm packages are published independently.

How the extension hooks into pi's tool lifecycle

The mechanism is event subscription. According to the README, the pi version listens on `tool_execution_start` and `tool_execution_end` to know which tool is running, and on `tool_execution_update` to read progress. It prefers structured fields from the tool result: a percentage, a stage, a status. For streaming bash output it also recognises common download, build, test and deployment progress patterns. Plain output is deliberately not forwarded to the working line, only structured progress and recognisable stages.

Self-narration works differently. The extension uses the `context` event to inject a convention into the model's prompt: at the start of each step, write a line of at most 20 characters beginning with a marker. The extension then parses the streaming output and displays that sentence next to the tool name. It is a prompt convention, not a protocol, so a model that ignores it simply produces no narration.

Two more event sources matter. `session_compact` is observed so the extension can flash a notification when context is compressed, which closes the loop with the context warning: warn, compress, recover. Model switching is also detected, and the working line shows a short quip tied to the model name for 1.5 seconds.

The code lives in `extensions/index.ts` and there is no build step. The package exposes it through a `pi.extensions` field pointing at `./extensions`, so pi loads the TypeScript directly.

Installing the pi package and running a first session

The README gives a single install command for the pi side. It installs the published npm package `pi-working-activity` into pi's extension directory.

pi install npm:pi-working-activity

After that, start a normal pi session. The extension generates its config file on first run at `~/.pi/agent/working-activity.json`. The README documents the default animation preset as `moon` and the mode as `lively`, which means the full set of phrases and easter eggs is on. If you want to confirm that the extension loaded and that the config directory is writable, the built-in doctor command checks exactly that.

/activity doctor

The doctor verifies that the config JSON parses, that the warning thresholds are ordered correctly, that the current preset and all animation structures are intact, that feature keys are recognised, that the current theme yields an RGB accent, and that the config directory and file are actually readable and writable. It is the fastest way to tell a broken install from a cosmetic problem.

To see the effect without touching config, switch the animation preset directly.

/activity frames claude

The README lists 28 presets, including `claude`, `braille`, `moon`, `comet`, `spark`, `breathe`, `dots`, `circle`, `star2`, `flip`, `aesthetic`, `hamburger` and `random`. Passing `random` makes the extension pick a different preset each turn. The same list is reachable through the interactive picker by running `/activity` with no argument.

Cost accounting reads pi's own usage field, not an estimate

One detail in the README is worth separating from the cosmetic features. At the end of a turn that lasted at least three seconds, the notification includes the turn's cost and token total. The cost comes from pi's own `usage.cost.total`, which the README says includes cache discounts and tiered pricing, so it matches the bill rather than a local calculation. Tokens are input plus output plus cacheRead plus cacheWrite. Cache hit rate is computed as cacheRead divided by input plus cacheRead, and reasoning tokens are shown as a subset of output without double counting.

`/activity stats` breaks this down per turn and per session. That is a genuinely useful thing to have inside the status line, because it removes the need to open a separate dashboard mid-session.

The one number that is not authoritative is the streaming rate. When `showTokPerSec` is enabled, the extension estimates tokens per second from the characters in `text_delta` events. The README states the reason directly: pi's streaming events do not provide per-chunk usage, so the live figure is an estimate, while the summary at the end of the turn uses the model's actual usage. Treat the live number as a rough gauge and the summary as the record.

The DSH package is documented far less than the pi one

The repository holds two implementations. The pi version lives in `extensions/` and is published as `pi-working-activity`, currently at 1.9.0 per `package.json`. The DSH version lives in `packages/activity/working-activity/` and is published as `dsh-working-activity`. The most recent release listed is `dsh-working-activity` 0.4.0, dated 2026-08-30, described as adding support for a DSH host version.

The README's main body is the pi documentation. The DSH install command appears in the platform table:

dsh plugin --profile <profile> add dsh-working-activity

The full DSH documentation is said to live in `docs/dsh-working-activity.md`, which the README describes as the former DSH repository README. There is also a patch file at `patches/webui-working-activity.patch` for the DSH Web UI runtime. The README does not explain what that patch changes or when it is needed, and it does not document a DSH equivalent of the pi settings panel, doctor command or feature toggles. If you are evaluating this for DSH, the README alone is not enough; you need the docs file and the patch.

The version gap is also worth noting. The pi package is at 1.9.0 and the DSH package at 0.4.0, so the two are not feature-matched, and the README does not claim they are.

Where the design gets in the way

The playful phrase pool is the most opinionated part of the project and the easiest reason to walk away. By default the working line rotates through 95 colloquial phrases roughly every 2.6 seconds, and the pool shifts again after 30 seconds, one minute and five minutes of thinking. There is a rare rainbow animation at roughly a 1 in 150 chance per check, staying for 7.5 seconds, and holiday pools for New Year, Spring Festival, Valentine's Day, April Fools, Labour Day, Children's Day, Halloween, Christmas Eve, Christmas and New Year's Eve. If you read the status line for information rather than atmosphere, this is noise, and the correct response is `/activity mode minimal`, which the README describes as keeping only real tools, timing and warnings.

There is a subtler failure mode. Several features depend on conventions rather than guarantees. Self-narration depends on the model obeying an injected instruction, so a model that ignores it produces a working line with no narration and no error. Streaming token rate is an estimate by construction. Progress display depends on the tool returning a percentage or a recognisable stage, and the README says tools without percentage progress simply do not show a remaining-time figure. None of these degrade loudly.

Fast tools are handled by a deliberate delay: anything under 1.5 seconds is queued and replayed one second at a time, with the last entry sticking for three seconds. That is a design choice to make quick work visible, and it means the status line is briefly behind reality. The README does not document a way to turn the replay off.

Finally, the extension injects text into the model context for narration. That is a small, continuous context cost on every step, and the README does not quantify it.

Alternatives and the difference in approach

The obvious comparison is pi's built-in Working indicator, which this extension replaces. The built-in one is a spinner with no event subscription, no config file and no commands. It cannot tell you that a build is at 42 percent, because it does not read tool results. The trade is that it also cannot inject a narration instruction into your prompt, cannot replay fast tools, and cannot warn you at 80 percent context. If you want the status line to stay dumb and predictable, the built-in indicator is the right choice and this extension is the wrong one.

A second comparison is a terminal multiplexer setup, where you watch the agent's own log output in a second pane instead of relying on a status line. That gives you the raw stream with no interpretation and no injected prompt text, at the cost of screen space and the need to read the log yourself. The extension's value is that it does the interpretation for you; its risk is that the interpretation can be wrong or missing without telling you.

Within the project itself, the meaningful alternative is `minimal` mode rather than uninstalling. It keeps real tool names, timing and context warnings and drops the phrase pool and easter eggs. That covers most of the informational value with far less visual churn.

Maintenance, licence and what to verify

The repository is not archived, and the last push was on 2026-08-30. That is recent enough that the project is not abandoned, but the only release listed is the DSH 0.4.0 from the same day, so there is no long release history in the repository to judge cadence by. The pi package version in `package.json` is 1.9.0, which suggests a longer line of iterations on that side.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the extent of what the repository states; nothing here is legal advice, and if you vendor the extension into a product you should read the LICENSE file yourself.

The upgrade cost is low for the pi side because there is no build step: `extensions/index.ts` is the single source, loaded directly. The package declares `@earendil-works/pi-coding-agent` at `>=0.81.0` and `@earendil-works/pi-tui` as peer dependencies, both marked optional. That optional marking means a version mismatch may not fail at install time, so a broken status line after a pi upgrade is a realistic outcome. The repository has a `typecheck` script targeting ES2022 and NodeNext, and a test file at `tests/index.test.ts` run with Node's built-in test runner and `--experimental-strip-types`. Running those two scripts is the cheapest way to confirm the extension still matches your pi version.

The first thing to verify on your own machine is the config file after one session: open `~/.pi/agent/working-activity.json` and check `contextWarnAt` (default 80), `contextDangerAt` (default 95) and `narrate` (default true). The danger threshold must not be lower than the warning threshold, which is one of the things `/activity doctor` checks.

Editorial conclusion

Adopt it if you already run pi CLI and want the Working line to say what the agent is doing instead of spinning. Skip it if you need a stable documented contract for DSH, or if you dislike a statusline that changes its own text every few seconds. Before installing, run `/activity doctor` and read `~/.pi/agent/working-activity.json` after the first session to confirm the defaults match your context budget.

Frequently asked questions

Official sources

1. ccch1mneyyy/working-activity on GitHub
2. Issues
3. License: MIT
4. README
5. Releases