DEV Community: Slim

Sniffing Claude Code's API Calls: What Your IDE Is Really Sending

Slim — Mon, 16 Mar 2026 05:05:11 +0000

Every time you press Enter in Claude Code, something interesting happens behind the scenes. Your full conversation — system prompt, message history, tool definitions, everything — gets packaged into an API call and sent to Anthropic's servers.

But you never get to see those calls. Claude Code logs a JSONL transcript of what it did (tool calls, responses, thinking blocks), but not the raw API traffic that made it happen. The system prompt, HTTP headers, request parameters, latency per call, and one entirely hidden API call — all invisible.

So we built a way to see everything.

The Trick: One Environment Variable

Claude Code officially supports ANTHROPIC_BASE_URL — an environment variable that redirects API traffic to a custom endpoint. It's meant for enterprise proxies, but it works perfectly for local interception:

Claude Code  ──plain HTTP──▶  Sniffer (localhost:7735)  ──HTTPS──▶  api.anthropic.com
                                    │
                                    ▼
                          ~/.claude/api-sniffer/*.jsonl

Start the sniffer in one terminal, launch Claude Code in another:

# Terminal 1
claudetui sniffer

# Terminal 2
claudetui sniff

claudetui sniff auto-detects the sniffer port and launches Claude Code through the proxy. If the sniffer isn't running, it falls back to launching Claude Code directly — so you never get stuck with a ConnectionRefused retry loop.

Every API call now flows through the proxy and gets logged. Claude Code works identically — it doesn't know (or care) that traffic is being captured.

No TLS interception. No certificates. No patching binaries. Just a localhost HTTP server that forwards to the real API over HTTPS.

What You See

The sniffer prints one line per API call as it happens:

  ClaudeTUI API Sniffer — listening on http://127.0.0.1:7735

  Use:  ANTHROPIC_BASE_URL=http://localhost:7735 claude
  Log:  ~/.claude/api-sniffer/sniffer-20260314-103000.jsonl

  #1   POST /v1/messages  opus-4-6  45.2k->1.5k  $0.120  2312ms  740KB/4.2KB  98%c  [Tt]
  #2   POST /v1/messages  opus-4-6  48.1k->0.8k  $0.094  1134ms  741KB/2.1KB  99%c  [TU]  Edit
  #3   POST /v1/messages  opus-4-6  50.3k->52    $0.081  1823ms  742KB/0.3KB  100%c  [U]  Glob,Grep
  #4   POST /v1/messages  opus-4-6  12.3k->2.1k  $0.041  3412ms  42KB/6.8KB   95%c  [Tt]  compaction
  #5   POST /v1/messages  sonnet-4-6  14.3k->2.1k  $0.008  2341ms  42KB/6.8KB  [Tt]  +agent.1

  Summary: 5 requests | $0.344 | 170k in | 5.6k out | 2.3MB sent | 18KB recv | 1 sub-agent

Each line shows the model, input->output tokens, estimated cost, latency, traffic size, cache hit ratio, content block types, tool names, and sub-agent tracking. Compaction events get flagged automatically.

The content blocks tell you what Claude is doing: T = thinking, t = text, U = tool use, S = server-side tool (like WebSearch). Cache ratio (98%c) shows how much you're saving — a 0%c (shown in red) means a cache miss, 12.5x more expensive.

Meanwhile, every request and response is logged as structured JSONL for later analysis.

What Transcripts Don't Tell You

Claude Code's JSONL transcripts are useful, but they omit a lot. Here's what the sniffer captures that transcripts don't:

Data	In Transcript?	In Sniffer?
Token usage (input/output/cache)	Yes	Yes
Raw system prompt	No	Yes
Full conversation history per request	No	Yes
Request parameters (max_tokens, temperature)	No	Yes
HTTP headers (anthropic-beta, version)	No	Yes
Request/response latency	No	Yes
Hidden compaction API call	No	Yes
Error response bodies	Partial	Yes
Streaming SSE events	No	Yes
Tool definitions (full JSON schema)	No	Yes

The most interesting items on this list are the system prompt and the hidden compaction call.

The System Prompt

Claude Code's system prompt is sent on every single API call. It contains:

Claude Code's internal instructions and behavioral guidelines
Tool definitions (Read, Write, Edit, Bash, Glob, Grep, etc.) with full JSON schemas
Your CLAUDE.md project instructions
Memory files, hooks output, and other injected context
Safety and permission guidelines

With --full mode, the sniffer captures the complete system prompt text. In our sessions, it consistently measures ~14k tokens — a fixed tax on every API call.

This is useful for understanding exactly what Claude Code "knows" about your project. Your CLAUDE.md, your hooks output, your memory files — it's all there in the system prompt, and now you can read it.

The Hidden Compaction Call

This is the one we were most curious about.

When Claude Code's context window fills up (~167k of 200k tokens), it triggers compaction. The entire conversation gets compressed into a summary, and the next turn starts fresh with just the system prompt + summary.

But here's the thing: the API call that generates the compaction summary doesn't appear in the transcript. Claude Code makes it, receives the summary, and continues — but the JSONL transcript shows nothing. You see a compact_boundary marker, but not the actual summarization call.

The sniffer catches it because it's just another POST /v1/messages:

  #12  POST /v1/messages  opus-4-6  12.3k->2.1k  $0.041  3412ms  compaction

The sniffer detects compaction by comparing consecutive requests. When the message count drops by more than 50% or the total content size drops by more than 70% compared to the previous request, it flags it as post-compaction. The dramatic shrinkage — from 167k tokens of conversation down to a ~15k summary — is unmistakable.

This is the only way to observe the compaction call's actual cost, latency, and output tokens. In our sessions, compaction summary generation takes 2-4 seconds and produces 11-19k tokens of compressed context.

The Tool Use Loop

When you see a line like this in the sniffer:

  #17  POST /v1/messages  opus-4-6  114.3k->531  $0.217  16047ms  [U]  tool

That's 114k tokens in but only 531 out. Why so few output tokens? Because Claude isn't writing prose — it's calling a tool. The response is just a small JSON block:

{"type": "tool_use", "name": "Read", "input": {"file_path": "/src/app.py"}}

Here's the full cycle for a single tool call:

Claude Code sends the full conversation to the API (114.3k input tokens — system prompt, message history, tool definitions, everything)
API responds with a tool_use block — just the tool name and parameters (531 output tokens)
Claude Code executes the tool locally — reads the file, runs the command, whatever the tool does
Claude Code sends another request with the tool result appended as a tool_result message — now input tokens are higher because the file contents (or command output) are part of the conversation

That's why you see rapid back-to-back requests in the sniffer. A single "read this file and edit it" from the user might generate 5+ API calls:

  #17  POST /v1/messages  opus-4-6  114.3k->531   [U]  tool     ← decide to read file
  #18  POST /v1/messages  opus-4-6  116.1k->204   [U]  tool     ← decide to edit file
  #19  POST /v1/messages  opus-4-6  117.8k->1.2k  [Tt]          ← respond to user

Each round-trip adds the tool result to the conversation, growing the input tokens. This is why context fills up faster than you'd expect — tool results (file contents, command output, search results) are often much larger than the tool call itself.

SSE Streaming Under the Hood

Claude Code uses Server-Sent Events (SSE) for streaming responses. The API returns text/event-stream and sends data in chunks as the model generates tokens.

The sniffer handles this transparently — it forwards each chunk to Claude Code as it arrives (so you don't notice any delay), while capturing the entire stream for logging.

After streaming completes, it reassembles the SSE events to extract structured data: model, usage, stop reason, and content block types (text, thinking, tool_use). This is what makes the one-line terminal output possible — you get clean 45.2k->1.5k $0.120 2312ms instead of raw SSE data.

The key technical detail: we use response.read1(8192) instead of response.read(8192). The read1() method reads whatever data is currently available without waiting for the full buffer to fill — critical for streaming, where you need to forward partial data immediately.

Sub-Agent Tracking

When Claude Code spawns a sub-agent (via the Agent tool), the sub-agent makes its own API calls — often using a different model. The sniffer tracks these by session ID:

  #8   POST /v1/messages  opus-4-6    89.1k->3.2k  $0.182  8234ms  99%c  [TU]  Agent
  #9   POST /v1/messages  sonnet-4-6  14.3k->2.1k  $0.008  2341ms         [Tt]  +agent.1
  #10  POST /v1/messages  sonnet-4-6  16.5k->1.2k  $0.006  1823ms         [TU]  Read  agent.1
  #11  POST /v1/messages  sonnet-4-6  22.8k->0.5k  $0.009  1243ms         [t]   agent.1
  #12  POST /v1/messages  opus-4-6    92.3k->1.5k  $0.152  4312ms  99%c  [Tt]

+agent.1 marks the first request from a new sub-agent. Subsequent requests from the same agent show agent.1. The main session has no label.

This reveals things you can't see from the transcript: sub-agents often use Sonnet (cheaper, faster) for research tasks while the main session runs on Opus. You can see exactly how many API calls each sub-agent makes, their cost, and how they overlap with the main session.

Cache Misses — The Silent Cost Spike

The cache ratio (98%c, 100%c) shows what percentage of input tokens were cache reads. Most of the time it's near 100% — great, you're paying the cheap rate.

But leave your session idle for ~5 minutes and watch what happens:

  #6   POST /v1/messages  opus-4-6  129.4k->15   $0.199   3336ms  100%c  [t]
  #7   POST /v1/messages  opus-4-6  129.5k->428  $2.460  16108ms  0%c    [Tt]
  #8   POST /v1/messages  opus-4-6  130.0k->600  $0.248  18310ms  100%c  [Tt]

Request #7 cost $2.46 — 12.5x more than usual — because the cache expired. All 129.5k tokens went through cache_creation at $18.75/M instead of cache_read at $1.50/M. Same data, same tokens, wildly different price.

The sniffer shows 0%c in red to make these cache misses impossible to miss.

Per-Request Cost Tracking

The sniffer calculates cost per API call using the token breakdown from the response:

{
  "usage": {
    "input_tokens": 3,
    "cache_read_input_tokens": 45000,
    "cache_creation_input_tokens": 800,
    "output_tokens": 1500
  }
}

With model-specific pricing (Opus: $15/$1.50/$18.75/$75 per 1M tokens for input/cache-read/cache-write/output), each line shows the exact cost of that call. No estimation, no averaging — real cost per request.

This revealed something we didn't expect: the variance between calls is huge. A simple response might cost $0.03, while a long code generation can cost $0.50+ — in the same session, same model.

What We Learned

After running the sniffer on real sessions, a few things stood out:

1. The system prompt is remarkably stable. It barely changes between calls within a session. The ~14k tokens are almost entirely cached after the first call, making them cheap ($1.50/M vs $15/M for Opus). But they still consume context window space.

2. Compaction is expensive in latency, not just tokens. The summary generation call takes 2-4 seconds — during which Claude Code is unresponsive. On a long session with 3 compactions, that's 6-12 seconds of dead time.

3. Cache hit rates are extraordinary. In typical sessions, 95-98% of input tokens are cache reads. The stateless-API design sounds expensive, but caching makes it practical.

4. Error responses are more informative than you'd think. When Claude Code encounters a 429 (rate limit) or 529 (overloaded), the response body often includes retry-after headers and detailed error messages. These are swallowed by Claude Code's retry logic and never shown to you.

5. Beta headers reveal feature flags. The anthropic-beta header shows which experimental features are active. Watching this change across Claude Code versions is interesting.

Security Notes

The sniffer is designed to be safe by default:

Localhost only — binds to 127.0.0.1, never 0.0.0.0
API keys redacted — x-api-key and authorization headers stripped from logs by default (use --no-redact to override)
Restricted permissions — log files created with 0o600 (owner read/write only)
Local plaintext — the API key transits in plain text only over the loopback interface, which is standard for local proxy patterns

Try It

The sniffer is part of ClaudeTUI:

# Install
brew tap slima4/claude-tui && brew install claude-tui && claudetui setup

# Or
curl -sSL https://raw.githubusercontent.com/slima4/claude-tui/main/install.sh | bash

# Run
claudetui sniffer              # Terminal 1: start proxy
claudetui sniff                # Terminal 2: launch claude through proxy
claudetui sniff --resume abc   # or resume a session through proxy

Options:

--port PORT     Custom port (default: 7735)
--full          Log complete request/response bodies (warning: large files)
--no-redact     Include API keys in logs (use with caution)
--quiet         Suppress terminal output, log only

Python 3.8+, stdlib only — no external dependencies.

What's Next

The sniffer captures data that was previously invisible. Combined with ClaudeTUI's existing context efficiency analysis, this gives a complete picture of what Claude Code is doing under the hood — from high-level token waste tracking down to raw HTTP traffic.

Some things we're exploring:

Replaying captured sessions for cost modeling ("what would this session cost on Sonnet vs Opus?")
Diffing system prompts across Claude Code versions to track changes
Correlating latency with context size — does response time scale linearly with input tokens?
Analyzing compaction summaries — what gets preserved and what gets lost?

If you're curious about what your Claude Code sessions actually look like at the API level, point the sniffer at a session and watch the data flow.

ClaudeTUI is open source and MIT licensed. Stdlib-only Python, zero external dependencies.

GitHub: github.com/slima4/claude-tui

Where Do Your Claude Code Tokens Actually Go? We Traced Every Single One

Slim — Sat, 14 Mar 2026 06:25:43 +0000

You're paying for 200,000 tokens of context. But how many of those tokens are actually doing useful work?

We built ClaudeTUI — a set of monitoring tools for Claude Code — and dug into the raw JSONL transcript data to trace every token. What we found surprised us: there are four distinct categories of token usage, and only one of them is your actual work.

What Happens When You Press Enter

Here's something most Claude Code users don't realize: every time you press Enter, the entire conversation is sent from scratch.

The Claude API is stateless. It doesn't remember your previous messages. So every single keystroke triggers an API call that includes:

System prompt (~14k tokens) — Claude Code's instructions, tool definitions, your CLAUDE.md
Full conversation history — every message, every tool call, every tool result since the last compaction
Your new message

On turn 1, that's maybe 15k tokens. By turn 15, it's 100k. By turn 30, it's 167k — and then compaction fires.

This is why Claude gets slower and more expensive as your session goes on. Each Enter keystroke processes more tokens than the last. And it's why compaction exists: without it, you'd hit the 200k wall and the session would simply stop.

The good news: Anthropic's prompt caching makes this less painful than it sounds. But it's worth understanding how.

The Cache Lives on Anthropic's Servers

Your machine sends the full conversation on every request — the same bytes go over the network every time. The optimization happens server-side: Anthropic checks "have I seen this exact prefix of tokens recently?" If yes, it skips re-processing them and charges the cheaper cache read rate ($1.50/M instead of $15/M for Opus — a 10x discount).

In a 157-turn session, we measured 98% of all tokens as cache reads. That makes sense: by turn 100, you're re-sending 99 turns of history that are already cached. Only the newest content goes through the expensive cache_creation path.

The cache has a TTL — likely ~5 minutes for conversation content. If you pause too long between turns, the cache expires and the next call pays full input price for everything. This is also why compaction is expensive: it blows away the entire cached conversation and replaces it with a brand new summary that goes through cache_creation from scratch.

One more thing: the tokens still count toward your 200k context window, even when cached. Caching saves money, not space.

Now let's look at what those tokens actually are.

The Four Types of Tokens

Every API call Claude Code makes has a token usage breakdown in its transcript. By parsing thousands of these calls across real sessions, we identified four categories:

1. System Prompt (~14k tokens) — The Constant Tax

Every single API call includes a system prompt: Claude Code's internal instructions, tool definitions, safety guidelines, and your CLAUDE.md file. In our sessions, this was consistently ~14,328 tokens.

This isn't something you can avoid. It's infrastructure. But it means that out of your 200k window, only ~186k is ever available for actual conversation.

We discovered this by looking at cache_read_input_tokens after compaction events. The value resets to exactly 14,328 every time — that's the system prompt floor. During normal operation, cache_read grows from 14k to 167k as your conversation accumulates in the cache.

2. Compaction Summary (~11-19k tokens) — The Rebuild Cost

When compaction fires, Claude Code compresses your entire conversation into a summary. The next API call has to read that summary to reconstruct context. This is the real overhead of compaction.

From a real 3-compaction session:

Compaction	Summary Size	What It Costs
#1	18.8k tokens	$0.47 (Opus)
#2	10.6k tokens	$0.22 (Opus)
#3	17.8k tokens	$0.37 (Opus)

These summaries are lossy. Your 167k of rich context — exact error messages, file contents, code snippets — gets compressed into 11-19k tokens. Details are lost.

3. Useful Work — What You Actually Paid For

This is everything else: your prompts, Claude's responses, tool calls, file reads, code edits, test output. The actual productive content of your session.

4. Headroom (~33k tokens) — The Unused Buffer

Claude Code doesn't wait until 200k to compact. It triggers at roughly 83% capacity (~167k tokens), reserving ~33k tokens as a buffer for the compaction process itself.

That means ~16.5% of your context window is never available for useful work. You're paying for 200k but only getting ~167k.

A Real Session, Dissected

Here's an actual 4-segment session from our monitoring data:

  Seg 1  ▒▒▓▓████████████████████████████████████████████████░░░░░  200.0k
         14.3k system │ 152.7k useful │ 33.0k headroom │ → compacted

  Seg 2  ▒▒▓▓▓████████████████████████████████████░░░░░░░░░░░░░░░  200.0k
         14.3k system │ 18.8k summary │ 114.4k useful │ 52.5k headroom │ → compacted

  Seg 3  ▒▒▓▓▓████████████████████████████████████████████████░░░  200.0k
         14.3k system │ 17.8k summary │ 141.2k useful │ 33.9k headroom │ → compacted

→ Seg 4  ▒▒▓▓██████                                                44.8k
         14.3k system │ 10.6k summary │ 12.7k useful

  Efficiency: 76%  │  Wasted: 166.5k/644.8k

76% efficiency means 76% of the total tokens went to useful work. The other 24% went to compaction summaries and headroom.

Notice how Seg 1 has no summary — it's the first segment, nothing to rebuild from. But starting from Seg 2, every segment pays the summary tax.

The Hidden API Call

One thing we couldn't find in the transcript: the compaction summary generation itself. Claude Code makes a hidden API call that reads your ~167k context and produces the summary, but this call is not logged in the JSONL transcript.

Based on the preTokens metadata we found in compaction events, this hidden call reads the full pre-compaction context (~167k tokens). At Opus pricing ($1.50/M for cached reads), that's roughly $0.25 per compaction just for the summary generation — on top of the rebuild cost.

What This Means for Your Wallet

Let's do the math for a long Opus session with 3 compactions:

Token budget: 644.8k total

Category	Tokens	Cost (Opus)	% of Total
Useful work	490k	~$8.50	76%
Compaction summaries	47k	~$0.85	7%
Headroom (unused)	108k	$0 (not billed)	17%
System prompt (constant)	~43k	~$0.06 (cached)	—
Hidden summary generation	~500k reads	~$0.75	—

The headroom tokens aren't billed directly — they represent capacity you couldn't use. But the summaries and hidden calls are real costs.

With Sonnet 4.6 the same session would be dramatically cheaper. Sonnet supports up to 1M context, so with 644k tokens you'd hit zero compactions:

All tokens are useful work
Efficiency: 100%
Cost: ~$5.50 (vs ~$10+ on Opus)

The System Prompt Discovery

Perhaps the most interesting finding: the system prompt is a constant ~14k tax on every segment.

Before our investigation, we were counting the full post-compaction context as "rebuild waste." A segment showing 33.1k rebuild looked like 33.1k of compaction overhead. But 14.3k of that is system prompt — you'd pay it regardless.

The actual compaction overhead (the summary) is only 33.1k - 14.3k = 18.8k. That's a 43% difference in how you measure waste.

How we detected it:

After compaction #1: cache_read = 14,328  ← system prompt
After compaction #2: cache_read = 14,328  ← same
After compaction #3: cache_read = 14,328  ← same

During normal operation: cache_read grows from 14k → 167k

The cache_read value tells you exactly what's already cached. After compaction, only the system prompt survives in cache — everything else (the compaction summary) goes through cache_creation.

The Compaction Cache Structure

Here's how token caching works across a compaction boundary:

Before compaction (normal operation):

cache_read: 166,575    ← almost everything is cached
cache_creation: 312    ← tiny new content
input_tokens: 3        ← negligible
output_tokens: 126

First call after compaction:

cache_read: 14,328     ← only system prompt survives
cache_creation: 18,793 ← compaction summary, written fresh
input_tokens: 3
output_tokens: 1,249

The cache gets blown away by compaction. Everything that was cached (your conversation, tool results, file contents) is gone. Only the system prompt persists because it's on a separate, longer-lived cache (likely a 1-hour TTL vs the 5-minute conversation cache).

7 Things You Can Do Right Now

1. Use /compact manually at logical breakpoints

Don't wait for auto-compaction at 167k. After finishing a feature or fixing a bug, compact yourself. You can guide what gets preserved:

/compact Preserve all file paths, error messages, and the list of modified files

2. Use /clear between distinct tasks

Switching from implementation to debugging? Starting a new feature? A fresh 186k of clean context beats 80k of stale context with irrelevant history.

3. Delegate verbose work to subagents

Each subagent gets its own isolated 200k context window. Running tests, searching large codebases, or fetching documentation in subagents keeps verbose output from bloating your main session.

4. Read files with line ranges

Instead of reading entire files, specify what you need: "Read lines 40-90 of handler.ts." Especially critical in debugging loops where you might read the same file repeatedly.

5. Disable unused MCP servers

Each MCP server loads its full tool schema into context on every request. A 20-tool server can consume 5-10k tokens just by existing. That's on top of the 14k system prompt.

6. Keep CLAUDE.md under 200 lines

CLAUDE.md is part of that ~14k system prompt. It loads on every single API call and survives all compaction cycles. If it's bloated, you're paying on every call.

7. Monitor your efficiency

Install ClaudeTUI and watch the numbers in real-time. Seeing "Efficiency: 76%" drop to "Efficiency: 68%" after a compaction changes how you think about context management.

How to See This Yourself

Install ClaudeTUI:

# Via Homebrew
brew install slima4/claude-tui/claude-tui && claudetui setup

# Or directly
curl -sSL https://raw.githubusercontent.com/slima4/claude-tui/main/install.sh | bash

Open a second terminal and run:

claudetui monitor    # live dashboard
claudetui chart      # efficiency chart (standalone)

The efficiency chart shows the 4-component breakdown for every segment in your session — updated live as you work. Press w in the monitor to open it, or v to toggle between horizontal and vertical views.

The Bottom Line

Every Claude Code session has four types of token usage:

System prompt (~14k) — constant tax, can't avoid it, but it's cheap (cached)
Compaction summaries (~11-19k each) — the real cost of compaction, lossy compression of your work
Useful work — what you actually paid for
Headroom (~33k) — buffer that's never available for work

In a typical 3-compaction Opus session, about 76% of tokens are useful work. The rest is overhead. Making this visible — and understanding what each component actually is — is the first step to spending tokens more intentionally.

ClaudeTUI is open source and MIT licensed. Stdlib-only Python, zero external dependencies.

GitHub: github.com/slima4/claude-tui

ClaudeTUI v0.3: Claude Code statusline gets a unified CLI, interactive configurator, and a proper splash screen

Slim — Wed, 11 Mar 2026 07:27:08 +0000

A couple of days ago I shared ClaudeTUI — a real-time statusline, live monitor, and session analytics for Claude Code. Since then, a lot has changed. Here's what's new in v0.3.

One command to rule them all

The biggest change: instead of six separate CLI commands for managing the Claude Code statusline, monitor, and analytics, there's now a single claudetui dispatcher.

# before
claude-ui-monitor
claude-stats --days 7
claude-sessions list
claude-ui-mode compact

# after
claudetui monitor
claudetui stats --days 7
claudetui sessions list
claudetui mode compact

Every subcommand passes arguments straight through — claudetui is just a 60-line Python script that resolves the right tool and execs it. No overhead, no framework. If you type claudetui --help, you get the full menu:

claudetui — CLI for ClaudeTUI (Claude Code utilities)

Commands:
  monitor     Live session dashboard (separate terminal)
  stats       Post-session analytics
  sessions    Browse, compare, resume, export sessions
  mode        Switch statusline mode (full/compact/custom)
  setup       Configure statusline, hooks, and commands
  uninstall   Remove ClaudeTUI configuration

The old command names (claude-ui-monitor, claude-stats, etc.) are gone. Clean break, clean namespace.

Interactive statusline configurator

The Claude Code statusline has 20+ components across three lines — context usage, cost, model, git stats, tool trace, and more. Previously you could only choose between "everything" (full mode) and "almost nothing" (compact mode). Now there's a third option:

claudetui mode custom

This opens a curses TUI where you can toggle individual components with arrow keys and spacebar:

Each component shows a live preview of what it looks like — colored progress bars, sparklines, git stats — right in the menu. You can pick from five widget styles for the matrix rain area, or apply presets (all, minimal, focused).

Don't like interactive menus? Use flags:

claudetui mode custom --hide model,cost,session_id
claudetui mode custom -w hex -p focused
claudetui mode custom -l   # show what's currently hidden

Config saves to ~/.claude/claudeui.json and hot-reloads — no restart needed.

Monitor got a facelift

The live monitor (claudetui monitor) picked up several improvements:

Splash screen — the monitor now shows an ASCII art logo while it loads the session in the background. Looks cool, masks the 1-2 second discovery time.

Pinned layout — the header (context, cost, stats) and footer (hotkey bar) are now fixed. Only the log section scrolls. No more hunting for the help bar when the log fills up.

Configurable log size — add "monitor": {"log_lines": 12} to your claudeui.json, or set it to 0 to hide the log entirely. Default is 8. Adjustable from the settings panel too (press c in the monitor).

Responsive footer — the hotkey bar adapts to terminal width. Full labels at 60+ columns, abbreviated at 40+, minimal below that.

The rebrand

You might have noticed: it's ClaudeTUI now, not ClaudeUI. The old name was too generic and clashed with other projects. Everything got renamed — repo, Homebrew tap, slash commands (/ui:* → /tui:*), CLI tools, docs, landing page, and all the screenshots.

The installer handles migration automatically — if you have the old claudeui Homebrew tap, it untaps it and points you to the new one.

brew tap slima4/claude-tui
brew install claude-tui
claudetui setup

Or the one-liner:

curl -sSL https://raw.githubusercontent.com/slima4/claude-tui/main/install.sh | bash

What's next

The transcript parsing approach works surprisingly well, but it's still reverse-engineering an undocumented format. Every Claude Code update is a small gamble. I'd love to see an official API for session metadata — even just a stable JSON schema for the transcript would help.

In the meantime, if you use Claude Code and want a statusline with real-time context tracking, cost monitoring, and session analytics: github.com/slima4/claude-tui

Stars and issues welcome.

I built a real-time dashboard for Claude Code because I kept losing track of my sessions

Slim — Mon, 09 Mar 2026 08:04:57 +0000

Claude Code has a 200k token context window but gives you zero visibility into how much of it you've used — until auto-compaction kicks in and wipes half your context. I got tired of that surprise, so I built ClaudeTUI.

The problem

If you use Claude Code daily, you've probably hit these:

Auto-compaction fires mid-task and you lose context
No idea how much a session is costing you
Can't tell which files Claude has been touching
No way to compare sessions or track patterns over time

Claude Code is a powerful tool, but it's a black box. You type, it works, and you hope for the best.

What ClaudeTUI does

It's a collection of tools that plug into Claude Code and give you full visibility:

Statusline — a real-time status bar that sits at the bottom of Claude Code:

 0110100 Opus 4.6 │ ████████░░░░░░░░░░░░ 42% 65.5k/200.0k │ ~24 turns left │ $2.34 │ 12m │ 0x compact
 1001011 my-project │ main +42 -17 │ 18 turns │ 5 files │ 0 err │ 82% cache │ 4x think │ ~$0.13/turn
 0110010 read config.ts → edit config.ts → bash npm test → edit README.md │ config.ts×2 README.md×1

Context usage, cost, cache ratio, git diff, tool trace, compaction prediction — all live. There's also a compact 1-line mode if you prefer minimal.

Live Monitor — open a second terminal and get a full dashboard:

$ claude-ui-monitor

Context sparkline with compaction history, cost breakdown with cache savings, per-turn activity (tools, files, errors), session-wide stats, and a scrollable log viewer with filters. It even tracks agent spawns and their results. The matrix rain header pauses when Claude is idle.

Hooks — automatic context injected into your sessions:

Session start: shows which files you've been editing recently across sessions
After edit: warns you about reverse dependencies ("4 files import this module")
Before edit: flags high-churn files ("config.ts edited 43 times in 5 sessions — maybe refactor?")

Session Stats — post-session analytics:

$ claude-stats --days 7 -s

Cost breakdown, token sparklines, tool usage charts, file activity heatmaps. See which sessions burned the most tokens and why.

Session Manager — browse and compare sessions:

$ claude-sessions list
$ claude-sessions diff abc123 def456

Side-by-side comparison of cost, duration, tools used, and file activity between any two sessions.

Slash Commands — deep reports without leaving Claude Code:

/ui:session    # full session report
/ui:cost       # cost deep dive
/ui:perf       # tool efficiency analysis
/ui:context    # context window predictions

How it works

Everything runs by parsing Claude Code's transcript JSONL files from ~/.claude/projects/. No API keys, no external services, no dependencies — just Python 3.8+ and the standard library.

The statusline uses Claude Code's statusLine config to run a Python script that reads session metadata from stdin and the transcript file from disk. It does two passes: a reverse pass to find current context size, and a forward pass to accumulate costs and activity.

The hooks use Claude Code's hooks system to run scripts on events like SessionStart, PreToolUse, and PostToolUse.

The monitor watches the transcript file for changes and redraws when it detects new content.

Install

One command:

curl -sSL https://raw.githubusercontent.com/slima4/claude-tui/main/install.sh | bash

It sets up everything — statusline, hooks, slash commands, and CLI tools. The installer asks you to pick full or compact mode for the statusline. You can switch anytime with claude-ui-mode compact or claude-ui-mode full.

To uninstall: claude-ui-uninstall

What I learned

Building tools that parse another tool's internal format is fragile by nature. Claude Code's transcript format isn't documented, so I had to reverse-engineer it by reading JSONL files and figuring out the structure. It works well today, but could break with any Claude Code update.

The other challenge was performance. The statusline runs on every refresh, so it needs to parse the transcript fast. For long sessions with thousands of entries, the reverse-pass-first approach helps — you find the current context size quickly without reading the entire file sequentially.