In a nutshell
I built a view layer over Claude Code that turns each run into an office floor and only shows me what I actually need to know: errors, requests for input and usage limits. Building it was the easy part. Working out that those were the three things I cared about took far longer, and I think that applies to any dashboard.
My coding setup looked like a CCTV room
Over the past few weeks, a lot of us at Alphero have been swapping examples on Slack. We've been looking at what's possible with interactive dashboards (custom views that show you what matters about a complex system and nothing else), and a lot of the best examples have been people building their own interfaces for coding agents. No two looked alike.
Every one of them made me look a bit harder at my own setup, which for the better part of a year has looked like a CCTV room. Four or more terminals tiled across my screens, each one a Claude Code session scrolling away, and I sat in front of them like a security guard waiting for something to move, which is a strange way to spend an evening if you think about it for too long.
It worked, though.
Everything I needed was in there somewhere. I was just reading paragraphs to answer questions that only needed a glance, and I hadn't really noticed.
I think Claude Code is the best place to run Claude, as the model is tuned to work inside it, so it knows when to ask a question and when to spin up a subagent. That loop is built for the model and it's very good. Though the terminal it prints into is a separate thing, and nothing says I have to watch it directly.
So what was I actually watching for?
I'd stopped reading the thinking traces a while ago, so quite honestly it came down to whether something had gone wrong, whether something needed me (a permission, or a call on taste) and how close I was to my usage limit. Each of those wanted a signal, and what I had was a wall of scrolling text.
So I spent a weekend building my own view on top of the harness, mostly off the back of what everyone had been posting. It's called The City, and it shows each Claude Code run as a floor of robot-staffed offices, with every project folder as its own building. When a robot needs approval a card appears at its desk and a beacon lights up over the building, and my 5-hour and weekly usage limits sit in the top corner.
Every animation comes from the event stream Claude Code already puts out, so the harness still does all the hard work and The City just decides what I see. A plain status list would do the same job, I know. I wanted something I'd enjoy leaving open.
As The City owns no logic (it only draws what the harness reports and passes my answers back), it was a safe thing to let Claude build almost entirely. The worst bug I could ship was a glitchy animation.
So I barely read the code.
For most features I described what I wanted the way a user would, something like 'I want a menu bar that shows the progress of jobs'. For the trickier parts, like how Reception should read a job I've typed and suggest which floor takes it, or a new floor if nothing fits, and where Apple's on-device models fit in, I sketched the system flow in FigJam, wrote implementation notes in the margins and handed the whole thing over.
A lot of those margin notes ended in a question mark, like whether Reception could use BM25 for fast matching, or whether it should just give up after 12 seconds and let me choose myself if the model was being slow. Here's my idea, basically, but suggest something else if it fits better. It felt a lot more like writing a brief than writing instructions.
It's rough, and it's built around my workflows and my appetite for information (a very specific audience of one). Some people will find it far too busy, all stats and statuses, while others will feel it takes too much control away from them. It also only shows runs it started itself, so anything I kick off in a terminal is invisible to it.
Quite honestly, the building was the easy part. The part that actually took time was the better part of a year sat in front of the wall before I could say which three things I was watching for, and I don't think a faster model would have got me there any sooner. Once I knew, the view more or less fell out of it.
That's where I think this gets interesting beyond coding agents. If your organisation runs something complex, whether that's a support queue or a set of internal agents, I'd guess you have your own version of the wall, a view built around what the system can report, which isn't always what the people watching it need to know. Building the view is getting quicker all the time, so the work worth doing properly is sitting with those people and finding their three questions. That's the kind of dashboard I think the examples on Slack are really pointing at.
If you'd like to see how mine works, the code is at github.com/Slaymish/theCity, and I've written up the technical side (piping the harness into a view layer, and driving the animations and world state from it) separately on my own site. This one only exists because other people shared theirs first.
I still leave it open most evenings. It's a quieter room now, a little city with the lights on, and I only look up when one of the beacons does.