Summary
External tools and plugins building session analytics need token usage data and session lifecycle signals. Currently there is no way to know how many tokens a session consumed, what it cost, or when tasks within a session start and end.
What's needed
- Token counts per session — tokens_in, tokens_out exposed via hooks, events, or API
- Session/task lifecycle events — signals when a session starts/ends and when logical tasks within a session begin/complete
- Tool call observability — post-tool-execution event should include truncated response content, not just tool name and exit code
- Usage introspection — API or CLI to query remaining usage limits
Use case
Building a session observatory that shows developers:
- Cost per session and per task
- Session drill-down with tool call inputs AND outputs
- Quality metrics (first-try-right rate, rework rate) correlated with cost
- Which approaches are efficient vs expensive
Proposed events
// Session end
{"event": "session.end", "tokens_in": 24000, "tokens_out": 8000, "turns": 8}
// Task boundaries
{"event": "task.start", "prompt_preview": "Fix the parser bug"}
{"event": "task.end", "outcome": "completed", "turns": 8, "duration_s": 180}
// Post-tool enrichment
{"event": "tool.post", "tool": "search", "response_preview": "Found 3 results..."}
Why opencode
opencode's open architecture and plugin system are ideal for this — richer lifecycle data than proprietary alternatives would be a strong differentiator.
Summary
External tools and plugins building session analytics need token usage data and session lifecycle signals. Currently there is no way to know how many tokens a session consumed, what it cost, or when tasks within a session start and end.
What's needed
Use case
Building a session observatory that shows developers:
Proposed events
Why opencode
opencode's open architecture and plugin system are ideal for this — richer lifecycle data than proprietary alternatives would be a strong differentiator.