Language: English · 简体中文
This document sketches where context-tracker could go. It is a direction, not a commitment — priorities may shift with real usage and feedback.
Detailed, checklist-driven breakdown: see docs/implementation-plan.md.
context-tracker can grow along three possible identities. The route below is shaped by which one we lean into:
- A. Developer debugging tool (current) — see exactly what a single request sent; troubleshoot agent behavior.
- B. Context & cost analysis — aggregate across requests to answer "where did my tokens go, and how do I trim them?"
- C. Agent observability infrastructure — durable storage, session traces, and team workflows; an APM for LLM agents.
The strongest moat is B: "capture and view requests" has a low technical bar and is easily replaced, but "tell me how my context budget is spent and how to save it" is a real pain point in the agent era — and the protocol-extraction layer already gives us the foundation for it.
- Response deep-parsing — responses are currently stored as raw SSE text. Parse out
stop_reason, tool calls, and tokenusageso the viewer shows what a call actually consumed. This is the key step from "viewing the request" to "seeing the whole picture." - Request diff — diff between consecutive requests. Agents append messages every turn; a diff instantly shows what was added, whether the system prompt changed, and which history got truncated.
- Precise token accounting — feed a tokenizer (or the response
usage) to turn theN msg / N tools / N Bsummary into real token counts, broken down by system / tools / history.
- Context composition — a breakdown showing "40% of this call's tokens are tool definitions, 35% is history, 10% is your actual question" — directly actionable for optimization.
- Cost dashboard — aggregate spend by provider / model / time (usage + a pricing table) to answer "how much did this project cost today." Complements billing-oriented tools that lack per-request context detail.
- Waste detection — automatically flag repeated large tool schemas, never-trimmed history, oversized system prompts, with concrete suggestions.
- Transparent proxy mode (opt-in) — an optional MITM + CA mode for fully config-free capture and signature-authenticated providers (Bedrock / Vertex). The default stays the zero-CA baseURL mode; this is a path for those who need it.
- More clients — Gemini CLI, Cursor, Cline, Aider, etc. Each is mostly a matter of confirming its base URL / protocol and adding an extractor to
protocols.js. - WebSocket / bidirectional streams — for future realtime API scenarios.
- On-disk storage — everything is in memory today and lost on restart. Add optional SQLite/JSONL persistence for post-hoc review and cross-session search.
- Session / trace correlation — group a task's multiple requests into one timeline by
session_id, instead of a flat request list. - Export / share — export a single entry or a whole session to HAR / JSON / Markdown for issues or team review.
- Stability infra — 22 tests exist but there is no CI. Add GitHub Actions (test + lint), a CHANGELOG, and semantic versioning ahead of a public release.
- Programmable API — turn the viewer's
/__historyinto a documented read-only API so others can build analysis/alerting on top. - Hooks / plugin points — allow custom redactors, custom provider extractors, and request transformers.
| Version | Focus | Highlights |
|---|---|---|
| v0.2 | Polish current tool (A) | Publish to npm · CI · response usage parsing · request diff |
| v0.3 | Move toward analysis (B) | Precise token accounting · context composition · cost aggregation |
| v0.4 | Breadth | Opt-in transparent proxy (CA) · more clients (Gemini/Cursor/Aider) |
| v0.5 | Persistence & sessions (C) | On-disk storage · session traces · export |
| v1.0 | Stability & ecosystem | Documented API · plugin points · semver commitment |
- Stay zero-dependency by default. New heavy features (tokenizers, storage, transparent proxy) should be opt-in and degrade gracefully when absent.
- Never touch the live path. Capture and analysis remain fire-and-forget side channels; the agent's request/response must never be blocked or altered.
- Local-first. No telemetry, no data leaving the machine unless the user explicitly exports it.