Cost Tracking: Data to Drive Pricing and Quota Decisions

At the end of each business day, your restaurant prints a daily report — total revenue, quantities of each dish sold, ingredient costs — filed for reference, so the next shift can pull it out for comparison.

Claude Code's cost tracker does the same thing. src/cost-tracker.ts writes cost data to the project config file at the end of each session, ready to be restored at the next startup:

// src/cost-tracker.ts
export function saveCurrentSessionCosts(fpsMetrics?: FpsMetrics): void {
  saveCurrentProjectConfig(current => ({
    ...current,
    lastCost: getTotalCostUSD(),              // How many USD this session cost
    lastAPIDuration: getTotalAPIDuration(),   // Total API call duration
    lastToolDuration: getTotalToolDuration(), // Total tool execution duration
    lastLinesAdded: getTotalLinesAdded(),     // Lines of code added
    lastLinesRemoved: getTotalLinesRemoved(), // Lines of code removed
    lastTotalInputTokens: getTotalInputTokens(),   // Tokens sent to Claude
    lastTotalOutputTokens: getTotalOutputTokens(), // Tokens Claude produced
    lastTotalCacheReadInputTokens: ...,  // Tokens read from cache (much cheaper than freshly generated)
    lastTotalCacheCreationInputTokens: ..., // Tokens written to cache
    lastSessionId: getSessionId(),
  }))
}

This data is used in two places:

User interface: At session end, shows Total cost: $0.23, Added 150 lines, Removed 42 lines
Product analytics: The product team uses this data to answer "how much more does a certain feature cost users on average," informing pricing and quota decisions

Costs are tracked per-model group, because Claude Code may use multiple models in a single session (main agent uses Sonnet, sub-agent uses Haiku) — just like the daily report needs to split "dine-in" and "takeout" separately; mixing them together hides each channel's margin.

There's also an interesting field: lastFpsAverage (average frame rate) and lastFpsLow1Pct (lowest 1% frame rate) — tracking CLI interface rendering smoothness, equivalent to "average customer wait time for food" in the daily report. It helps engineers identify "which version made the interface lag."