The problem with `--verbose` is that it floods the terminal, making real-time debugging a headache.
Also, this isn't a wrapper—it’s a passive viewer. I built it specifically to keep the native terminal workflow intact.
It’s especially useful when you're running multiple parallel sessions. Have you ever tried digging through raw JSON logs to retroactively debug passed sessions at once, since the session is already shut down? It’s nearly impossible without a proper UI. This tool is for those "post-mortem" moments, not just for watching a single stream.
I don't sit there watching every session either—that's definitely not the point.
It's more like standard observability. You don't watch your server logs all day, but when an error spikes, you need deep tracing to find out why.
I use this when the agent gets stuck on a simple task or the context window fills up way faster than expected. The tool lets me "drill down" into the tool outputs and execution tree to see exactly where the bad loop started.
If you're running multiple parallel sessions across different terminal tabs, trying to grep through raw logs to find a specific failure is a massive productivity sink. This is for when things go sideways and you need to solve it in seconds, not for babysitting every keystroke.
To be clear, I'm not saying they solve high-level software design.
The goal is to prevent the agent from getting derailed by basic noise. Forcing it to deal with strict TS errors, dead code (Knip), or broken formatting in the feedback loop keeps the context clean.
It’s less about architecting the app and more about giving the agent immediate stderr signals so it stays on the rails.
True. They actually do support basic OTel now, but it's mostly limited to high-level metrics like token usage and session counts.
Until then, parsing the local files seem to be pretty much the only way to get real observability.
I actually had the exact same worry when I started building this.
But it turns out Claude Code's official VS Code extension is built to read these exact same local `.jsonl` files. So unless Anthropic decides to intentionally break their own first-party extension, it should remain relatively stable.
Of course, they will add new payload types (like the recent "Teams" update), but when that happens, it's pretty trivial to just add a new parser handler for it—which I've already been doing as they update the CLI.
Fair point. The root directory can be seen noisy right now. There are two main reasons for that:
1. Cross-platform distribution: Shipping an Electron app across macOS (ARM/Intel), Linux (AppImage/deb/rpm), Windows, and maintaining a standalone Docker/Node server just requires a lot of platform-specific build configs and overrides (especially for electron-builder).
2. Agentic coding guardrails: As I built most of this project using Claude Code itself, I wanted strict boundaries when it writes code
The ESLint, Prettier, strict TS, Knip (dead code detection), and Vitest configs act as quality gates. They are what keep the AI's output from drifting into unmaintainable spaghetti code. Without those strict constraints, agentic coding falls apart fast.
I'd rather have 20 config files enforcing quality than a clean root directory with an AI running wild. That said, I totally take your point—I should probably consolidate some of these into package.json to clean things up.
To clarify on what the others mentioned: `/usage` and `/status` in the CLI do give you basic session token counts.
But regarding khoury's original point about the actual "gas in the tank" (billing/account balance)—no, my tool doesn't show that either.
Since `claude-devtools` strictly parses your local `~/.claude/` logs and makes zero network calls, it doesn't have access to your Anthropic account to pull your actual dollar balance.
What it does provide is high-resolution context usage. Instead of just a total session count, it breaks down tokens per-turn (e.g., how many tokens were eaten by reading a specific file vs. the tool output). It helps you manage your context window locally, but for billing, you're unfortunately still stuck checking the web dashboard.
Also, this isn't a wrapper—it’s a passive viewer. I built it specifically to keep the native terminal workflow intact.
It’s especially useful when you're running multiple parallel sessions. Have you ever tried digging through raw JSON logs to retroactively debug passed sessions at once, since the session is already shut down? It’s nearly impossible without a proper UI. This tool is for those "post-mortem" moments, not just for watching a single stream.