token-data-sources
Provides debugging steps and implementation details for fixing missing token data or adding new usage visualizations in the Analysis page.
Install
mkdir -p .claude/skills/token-data-sources && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/10571" && unzip -o skill.zip -d .claude/skills/token-data-sources && rm skill.zipInstalls to .claude/skills/token-data-sources
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
When debugging why the analysis page shows missing or zero token data, or when adding new cost/usage visualizations.Key capabilities
- →Debug missing token data on analysis page
- →Trace data flow from WebSocket events
- →Implement new cost and usage visualizations
- →Fix token record gating issues
How it works
The skill identifies whether token data failure stems from the in-memory Live Agent path or the DB-Persisted Cost path, then provides a plan to fix gating logic in AgentManager.
Inputs & outputs
When to use token-data-sources
- →Debugging 'Waiting for token data' errors
- →Adding new cost-per-agent charts
- →Fixing issues with token record gating
- →Tracing data flow from WebSocket events
About this skill
Analysis Page Token Data Sources
When to use: When debugging why the analysis page shows missing or zero token data, or when adding new cost/usage visualizations.
Two Token Data Paths
The analysis page has two independent data sources for token information. Understanding which is active and when is critical.
Path 1: Live Agent Objects (In-Memory)
- Source:
AnalysisPage.tsxreadsagent.inputTokens/agent.outputTokensfrom the app store - Populated by: WebSocket
agent:usageevents → appStore updates agent objects in memory - Works when: Session is active and agents are running
- Fails when: Session is inactive (agents gone from memory → all zeros → "Waiting for token data...")
- Used for: Time-series token usage chart, total token counts
Path 2: DB-Persisted Cost Records
- Source:
CostBreakdown.tsxfetches/costs/by-agentand/costs/by-taskAPI endpoints - Populated by:
CostTracker.recordUsage()→ writes totask_cost_recordsDB table - Works when: Data has been recorded to the DB (persists across sessions)
- Fails when: The dagTaskId gate blocks recording (see below)
- Used for: Per-agent and per-task cost attribution breakdown
The dagTaskId Gate Bug
In AgentManager.ts, token usage recording has a gate condition:
// packages/server/src/agents/AgentManager.ts ~line 725
if (dagTaskId && agent.parentId) {
tracker.recordUsage(agent.id, dagTaskId, ...);
}
This requires BOTH:
dagTaskId— agent must have an active DAG taskagent.parentId— agent must have a parent (not be the lead)
Problem: The lead agent (which has no parentId) never records usage. And child agents only record when they have an active DAG task. This means task_cost_records is often empty → "No token attribution data yet."
Meanwhile, emit('agent:usage') at line ~730 fires unconditionally, so the time-series chart works fine.
Fix Plan
- Remove the parentId requirement: The lead's token usage should be tracked too
- Fall back to a synthetic task ID: When no dagTaskId exists, use
agent.idor a session-level bucket - Add DB fallback for inactive sessions: When live agents aren't available, fetch historical data from
/costs/by-agentinstead of reading from in-memory agent objects
Key Files
| File | Lines | Role |
|---|---|---|
packages/server/src/agents/AgentManager.ts | ~721-731 | Token usage wiring — emit (unconditional) vs record (gated) |
packages/server/src/agents/CostTracker.ts | 102-154 | recordUsage() — writes to task_cost_records |
packages/server/src/agents/CostTracker.ts | 157-182 | getAgentCosts() — reads aggregated costs |
packages/server/src/routes/lead.ts | 263-296 | /costs/by-agent and /costs/by-task API endpoints |
packages/web/src/components/AnalysisPage/AnalysisPage.tsx | 84-86 | Token data from live agent objects |
packages/web/src/components/TokenEconomics/CostBreakdown.tsx | 34-37 | Fetches DB-backed cost data |
When not to use it
- →General frontend debugging
- →Database schema migrations
Limitations
- →Requires understanding of two independent data paths
- →Fixes are limited to AgentManager and CostTracker logic
How it compares
It specifically targets the discrepancy between real-time WebSocket usage reporting and DB-persisted cost records, which is a common source of 'Waiting for token data' errors.
Compared to similar skills
token-data-sources side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| token-data-sources (this skill) | 0 | 5mo | No flags | Intermediate |
| optimizing-performance | 1 | 2mo | Review | Intermediate |
| audit | 0 | 4mo | No flags | Intermediate |
| analytics-pipeline | 1 | 6mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
optimizing-performance
CloudAI-X
Analyzes and optimizes application performance across frontend, backend, and database layers. Use when diagnosing slowness, improving load times, optimizing queries, reducing bundle size, or when asked about performance issues.
audit
senda-labs
Run complete system health audit of DQIII8 — checks DB integrity, agent performance, pipeline connections, error log, and services. Produces a scored Markdown report.
analytics-pipeline
dadbodgeoff
Real-time analytics with Redis counters, periodic PostgreSQL flush, and time-series aggregation. High-performance event tracking without database bottlenecks.
prisma-connection-pool-exhaustion
blader
Fix Prisma "Too many connections" and connection pool exhaustion errors in serverless environments (Vercel, AWS Lambda, Netlify). Use when: (1) Error "P2024: Timed out fetching a new connection from the pool", (2) PostgreSQL "too many connections for role", (3) Database works locally but fails in production serverless, (4) Intermittent database timeouts under load.
transaction-correctness
tursodatabase
How WAL mechanics, checkpointing, concurrency rules, recovery work in tursodb
data-sql
nholder88
>-