Myrlin Workbook

The deciding trait is the scrollback. Every session you have run is still on disk, and this reopens any of them in a live terminal where scrolling up past the top carries on into the recorded conversation, as one selection you can copy. Anyone who has tried to reconstruct what an agent did last Tuesday knows exactly how much that is worth.

What it does not do is any thinking of its own; it is a window onto tools you already run. Pick it if you run several agent sessions a day and lose track of them. Pick tmux and a notebook if you run one at a time.

It depends on two private on-disk formats it does not own. Claude Code sessions come from a directory under a vendor's dotfiles, and Codex threads come out of the same SQLite store a desktop app writes. Neither is a published interface. A schema change ships in someone else's release and the reader breaks with no warning and no version to pin against.

Read-only access limits the blast to a broken view rather than a lost transcript, which is the right choice. The install command still carries an alpha tag, so treat every one of these surfaces as provisional.

1. The cost figures are derived, not reported. They are parsed out of transcripts rather than retrieved from a billing interface, which makes them an estimate whose accuracy depends on the transcript format continuing to record what it currently records. That is worth knowing before anyone quotes one in a meeting. 2. Both readers are read-only by design, so the measurement apparatus cannot perturb the thing it measures.

2. Nothing is claimed beyond that, and nothing needs to be. This is instrumentation, and instrumentation is judged on fidelity rather than capability.

There is no company here, only a person and 380 stars, and the product calls no model of its own, which means it has no cost base and no revenue line. That is a clean position financially and a fragile one structurally: nothing here funds a second year.

Moat: none, and the category is one where a vendor could ship the same view as a menu item in their own client. Likely path: it stays a personal project or it stops. Likely acquirer: nobody, because the thing that gives it value is other people's session formats. Position: use it, and keep your own record of anything you would miss.

Nothing per seat, and nothing central either. This is a Node server on each developer's own machine, so there is no console that tells me who ran what, no directory integration, and no retention policy to point a security questionnaire at. It is a personal tool that sixty people would each run privately.

The workflow fit is good: a board card owns a branch, a worktree and a running session, which is close to how my teams already split work. It does not run in a pipeline. Approved with conditions: individual use only, and not on any machine holding customer data.

AGPL-3.0, no telemetry, no sign-up and no cloud anywhere in it, which is three of the four things I check before I install something that reads my session history. The fourth is that it reads rather than writes, and I can verify that in a Node tree small enough to skim.

The phone layout is served over my own LAN, so the remote access story involves no vendor at all, which is the version of remote I actually want. There is no MCP client, but this is a viewer rather than an agent, so that is not the thing I would ask it for.