Files

T

nntrivi2001 57dc91585d feat: Claude Code Monitor — lanes, pipelines and a merged workspace

Internal SmartGift build of a Claude Code monitoring dashboard.

Lanes: a durable unit of parallel agent work, one per working directory,
tracked across session restarts. Managed lanes are git worktrees the
dashboard provisions and can reset or remove behind a three-check destroy
guard and a counted preflight; adopted lanes are directories you already
own and are never destroyable.

Pipelines: a lane moves through pipeline stages. A stage the agent declares
with evidence renders green; a stage inferred from the tool-event stream
renders dashed amber and never counts as done. Detection is forward-only
within a 30-minute window, and never writes the declared stage.

Workspace: one page at /run with a lane grid, the selected lane's pipeline,
and a full Claude console behind a disclosure.

2026-07-30 14:39:03 +07:00

2.9 KiB

Raw Permalink Blame History

description

description
Produce a detailed report on APIError events from Agent Monitor data — counts over time, which sessions and models are affected, and the likely root cause (rate limits, overload/529, or context-window pressure) inferred from each event's summary and data payload. Use when API errors spike or when you need to explain why requests are failing.

API Error Report

Drill into APIError events: how many, when, where, and most likely why.

Input

The user provides: $ARGUMENTS

This may be:

empty or "all" — report on every APIError in the recent window (default)
a session ID — report APIErrors for that one session only
a window like "today" or "last 7d" — restrict the time range
a cause filter: "rate-limit", "overload", or "context"

Data Sources

Endpoint	Returns
`GET /api/analytics`	`event_types` (total `APIError` count), `daily_events` (365d) — APIError volume and trend over time
`GET /api/events?session_id=X`	Per-session event stream — each `APIError` carries `summary`, `data`, and `timestamp` used to classify the cause
`GET /api/sessions?limit=N`	Sessions with `id`, `model`, `started_at` — attribute each error to a model and place it on the timeline

Report Sections

1. Volume & Trend

From GET /api/analytics: total APIError count and its share of total_events. Use daily_events to chart APIErrors over the requested window and flag any day that spikes above the window mean.

2. Affected Sessions & Models

For each session in scope, pull GET /api/events?session_id=X and collect APIError events. Group by session_id and, via GET /api/sessions, by model. Report the top affected sessions and which model accounts for the most errors.

3. Likely Cause Classification

Inspect each error's summary/data and bucket it:

Rate limit — mentions 429, "rate limit", "quota", or retry-after.
Overload — mentions 529, "overloaded", or capacity.
Context — mentions context length, token limit, or "too long" (correlate with nearby Compaction events).
Other — anything else; quote the summary. Report the count and percentage in each bucket.

4. Timeline

List the most recent APIErrors with timestamp, session_id, model, classified cause, and a one-line summary excerpt.

Output

A Markdown table per section (volume, by model, by cause).
Rates as percentages to 2 decimals; any currency in USD to 4 decimals.
Cite exact session_id, model, timestamp, and summary values — never invent a cause not supported by the payload; bucket as "Other" when unclear.
End with the dominant cause and a concrete mitigation (e.g., back off and retry on 529, reduce context to cut context errors, slow request rate on 429).
Read-only: only report what the API returns. If curl cannot reach http://localhost:4820, tell the user to start the dashboard with npm start from the repo root.

2.9 KiB Raw Permalink Blame History