There's a specific kind of helplessness that shows up once you start handing agents work that takes more than a couple of minutes. You give Claude Opus a long task, walk away, and then spend the next twenty minutes squinting at tool-call output trying to reverse-engineer where it is. Is it still working the plan?
Did it wander off three steps ago and start fixing something you didn't ask about?
You don't want to stop the session in case it's close, but you also can't tell if it's stuck. A Claude Code heavy user put it plainly in a post about his own fix: after you hand off the task, there's no intuitive way to see which step it's on, so you can't tell whether it drifted, and you're afraid to kill the session.
His answer was CCProgress, a mod that bolts a progress bar onto the terminal now that Claude supports mods. The first reply was the obvious jab — if you already know when a task ends, you're reinventing the wheel — and his response is the honest one: the bar isn't a prediction, it just surfaces the agent's stated goals. That exchange is the whole design problem in two lines. You can show intent. You can't show a real ETA.
The terminal gauge is the throwaway part
If you look at what's actually valuable in that setup, the progress bar in the terminal is the disposable half. It lives in one shell, on one machine, in front of one person. The moment you walk to another room or check from your phone, it's gone. The durable, reusable half is the thing underneath it: a stream of "here's the step I just started" events coming out of the agent. That stream is worth capturing on its own, independent of how you choose to render it.
Another post made the cost of not capturing it very concrete. Someone wired Claude Code sessions to spawn more Claude Code sessions across a machine, delegating a model migration and a couple of bug fixes. The work itself mostly landed. The visibility didn't. His list of problems reads like a spec for what to build: the sub-sessions pushed confirmation requests to his phone and the notifications never arrived, so two sessions sat waiting for two hours; the confirmation requests timed out after about ten minutes and replies after that went nowhere; and when a downstream session finished or jammed, the session that launched it had no idea — he had to go look himself. Sessions he opened and sessions the agent opened were tangled together with no way to tell them apart.
Every one of those is a reporting-and-visibility failure, not a model failure. The agents were fine. The problem was that the only record of "where things stand" lived inside ephemeral sessions nobody could see into.
What to build instead: an external checkpoint ledger
So rebuild the honest half and drop the gauge. Three pieces, all inside confirmed VicroCode capabilities.
First, a small endpoint the agent reports into. You can run Python online for this and host it as an API endpoint — a single `POST /checkpoint` that takes a run id, a step label, a status like `started` / `done` / `blocked`, and a free-text note. The agent calls it at the top of each step and again when the step closes. That's the entire contract. You're not asking the model to predict anything, which sidesteps the "reinventing the wheel" objection. You're just asking it to say what it's doing, out loud, to somewhere that outlives the session.
Second, the ledger itself. Each checkpoint is a row in a SQLite table: `run_id`, `seq`, `step`, `status`, `note`, `created_at`. A ledger, not a status field you overwrite — you want the full trail so you can see that it spent four steps on the thing you asked and then quietly opened a fifth you didn't. When something looks wrong, a SQLite editor lets you open the table directly and read the sequence, or correct a run's state by hand if the agent marked something `done` that clearly isn't. That direct-edit path matters more than it sounds, because it means the board is never a black box you can only watch.
Third, the view. A hosted board you can run HTML online and open from any device — phone on the couch, laptop in another room. It polls the endpoint, groups rows by `run_id`, and shows the latest step per run plus how long ago the last checkpoint arrived. That last-seen timestamp is doing the heavy lifting. It's what replaces the fantasy of a real progress percentage with something true: this run last spoke 90 seconds ago versus this run has been silent for 40 minutes. The tangled-sessions complaint gets solved for free, because every run is its own labeled lane whether you started it or an agent did.
Draw the line at what you can't see
This is where honesty has to be built into the thing, not bolted on. A reporting ledger shows you exactly what the agent chose to report and nothing else.
It cannot see inside the model's reasoning. A step labeled `fixing auth middleware` tells you the stated intent, the same way CCProgress surfaces goals — it does not tell you whether the fix is correct or whether the agent misunderstood the task. Wrong-but-confident still looks like steady progress on the board.
It cannot detect a crash by itself. A process that dies mid-step can't post its own death. All you get is silence, which is why the board should lead with staleness and let you set your own threshold for "this looks stalled." Stall is inferred from a quiet timestamp, never confirmed by a signal, and you should treat it that way.
And it can't give you a real ETA. If you don't know when the task ends — and with a dynamically adjusting agent you usually don't — no amount of instrumentation invents that number. Steps completed over steps planned is a comfort metric at best, because the plan itself moves.
The confirmation-timeout problem from the delegation story is worth calling out as explicitly out of scope here too. A checkpoint ledger is one-directional: the agent tells you where it is. Round-trip approvals, retries, and delivery guarantees for "can I proceed?
prompts are a different mechanism with its own failure modes, and whether a given setup handles them reliably is unverified. Don't let a read-only board quietly imply it's doing something it isn't.
Why this shape holds up
What makes the ledger worth more than the gauge is that it decouples capture from display. The agent's job stays dead simple — emit a line per step. Everything else is yours to shape: a board today, a daily digest later, a query that flags any run silent for more than ten minutes. Because the data sits in SQLite rather than scrolling past in a terminal, you can go back a week and ask what a run actually did, which you cannot do with a bar that only ever showed the present moment.
It's a modest build. One endpoint, one table, one page, all hostable in one place and shareable by link. But it turns the current reality — walk away, come back, squint, guess — into something you can glance at from your phone and actually trust, as long as you keep trusting it only as far as the agent is willing to talk.