I Could Measure Claude and Codex Usage. I Still Couldn't Honestly Assign It to a Task.

When utilizing Claude Code or Codex for actual work, simply tallying the total number of usage instances is insufficient. It becomes crucial to understand which specific activities consumed those resources. The author initially overlooked existing token and cost trackers, but later built a monitoring system in Notion. However, when trying to implement this in an operational workflow, they encountered challenges with agent logs remaining on the machine, a need for lightweight dependencies, custom audit metrics, machine-readable output, and distinct session measurement and task attribution.

The ideal solution involves a layer below the dashboard that can address whether a specific number is sufficient for task accounting. Different tools cater to different needs - a broad CLI like ccusage is suitable when coverage across agents is essential, while local interfaces such as token-tracker or AgentMeter are better for detailed project analysis. For fleet-level metrics, logs, and traces, an OpenTelemetry stack is the optimal choice.

The author's preferred setup consists of local observations (auditable normalized facts), explicit pricing status, caller-selected sessions, task-attribution policies, and optional dashboard/Notion/spec-lane integration. The tool reads logs that Claude Code and Codex CLI have already written locally, normalizes each usage event into a fact with a model, token kind, timestamp, and count, all without making network calls or introducing Python runtime dependencies.

A session is observable, but a task is a separate claim. Measuring usage within a time window and dividing the total based on elapsed time or commit count provides numbers that add up, but this allocation is not based on direct observation. One session can encompass multiple tasks, while one task can span several sessions. Therefore, session usage is observable, while session-to-task attribution remains a separate claim.

The caller decides which sessions to measure, and agent-cost does not attempt to infer tasks from branches, pull requests, or timestamps.

The tool accepts only selected session IDs and does not attempt to derive tasks from branches, pull requests, or timestamps. If a session spans multiple tasks and there is no clear way to divide it, leaving that usage unattributed is preferable to creating an artificial allocation. The same principle applies to pricing - agent-cost acknowledges uncertainty instead of hiding it. Unknown models are unpriced, and cache writes without TTL breakdown are priced at the cheaper five-minute rate, labeled as lower_bound.

The tool provides an estimated cost in USD rather than a definitive bill. Allowances, contracts, credits, and batch usage cannot be fully derived from local logs. The output gives a list-price estimate attached to observed tokens. However, allowances, contracts, credits, and batch usage are not recoverable from local logs. The tool offers an estimated cost in USD, not a final bill. This setup aims to provide transparency and accountability while minimizing supply-chain risks and the need for trust in local log access.