After updating to 0.9.14 it doesn't show any cost

[didlika]

After updating globally to the latest version, there is no cost data displayed, tried on two different machines, same behavior on both:

[ozymandiashh]

The screenshots point at the Copilot provider, not pricing. Everything else parses (435 calls, projects, tools, activities), but the header shows 0 in 0 out 0 cached 0 written and By Model lists Copilot (Anthropic) at $0.00. Zero tokens means zero cost, so this is a token-parsing regression, not a pricing one. I checked the bundled LiteLLM snapshot and the upstream table and both are fine, and a clean 0.9.14 with non-Copilot data prices correctly here.

Where Copilot tokens come from, for context:

• The OTel SQLite store (agent-traces.db) carries the full input/output/cache breakdown, but it is opt-in: it needs github.copilot.chat.otel.dbSpanExporter.enabled: true, which defaults to false. Most users never have this DB.
• The JSONL session-state files only ever carry output tokens (input/cache are never written there).

Your 0 in is consistent with not having the OTel DB (input only comes from OTel). The 0 out with 435 calls is the actual bug: the JSONL path is yielding calls with zero output tokens, which lines up with the OTel/JSONL refactor that landed in 0.9.14 (#477, then #527) changing how session-state files are classified and read. A Copilot-only user without the OTel DB enabled now gets token-less rows where older builds read output tokens.

To pin the exact field/format and fix it, could you share:

1. ls -la ~/.copilot/session-state/ and one sample .jsonl from there (a single message object is enough, redact content) so I can see which key holds the output token count and whether it is being treated as a transcript.
2. Whether the OTel DB exists: ls -la "$HOME/Library/Application Support/Code/User/globalStorage/github.copilot-chat/agent-traces.db".
3. codeburn --verbose 2>&1 | grep -i copilot (any skipped-file or parse warnings).
4. Your Copilot CLI / chat extension version (the on-disk format has shifted across versions).

With a sample session object I can reproduce and propose a fix for the JSONL token read.

[didlika]

Session-state path — ~/.copilot/session-state/ does not exist on Linux. VS Code stores sessions at:

~/.config/Code/User/workspaceStorage//chatSessions/.jsonl
~/.config/Code/User/globalStorage/emptyWindowChatSessions/.jsonl
Sample kind=2 object — token fields:

{ "requestId": "request_8c8ce017-6e3f-460a-9931-5a16825d231a", "modelId": "copilot/claude-sonnet-4.6", "completionTokens": 490, "result": { "metadata": { "promptTokens": 32543, "outputTokens": 60, "toolCallRounds": [ { "thinking": { "tokens": 0 }, "modelId": "claude-sonnet-4.6" } ], "resolvedModel": "claude-sonnet-4-6", "agentId": "github.copilot.editsAgent" } } }

Fields present: result.metadata.promptTokens, result.metadata.outputTokens, completionTokens. No cachedTokens field.

OTel DB — not present (agent-traces.db does not exist, opt-in not enabled).

codeburn --verbose grep — Copilot (Anthr) $0.00 - 447 - (zero tokens, 447 calls).

Copilot Chat extension — 0.52.0, built-in at copilot.

[ozymandiashh]

Thanks, that single request object was exactly what was needed to find the token fields. One more thing before I finalize: I want to make sure the parser reads your real files, not just the inner request object.

In VS Code's chatSessions/*.jsonl (and emptyWindowChatSessions/*.jsonl), each line is usually a wrapper record rather than a bare request, something like { "kind": 2, "v": { "requests": [ { "requestId": ..., "result": { "metadata": { ... } } } ], "pendingRequests": [ ... ] } }. The request you pasted looks like the inner v.requests[] entry. If the parser only reads the top-level line it will still yield zero calls on real files, so I need to confirm the exact nesting on your machine.

Could you paste ONE full raw line from a real file (prompts/content redacted, but keep the structure and the numeric token fields intact)? Specifically:

• head -c 2000 "$(ls -t ~/.config/Code/User/workspaceStorage/*/chatSessions/*.jsonl 2>/dev/null | head -1)" (or the emptyWindowChatSessions path), so I can see the top-level keys and where the requests array sits.
• If a line is huge, even just the top-level key names (kind, v, and the first level of v) plus one nested request with its result.metadata token fields is enough.

With one real line I can build the fixture from the actual wrapper and the fix will work against your data instead of a hand-shaped sample.

[didlika]

The kind=2 line uses v as an array, not an object. Top-level structure:

So the path to token fields from the top-level line is:

`{
  "kind": 2,
  "v": [
    {
      "requestId": "...",
      "timestamp": ...,
      "agent": "...",
      "modelId": "copilot/claude-sonnet-4.6",
      "responseId": "...",
      "result": { "metadata": { ... } },
      "followups": [...],
      "modelState": {...},
      "contentReferences": [...],
      "codeCitations": [...],
      "timeSpentWaiting": ...,
      "completionTokens": 490,
      "elapsedMs": ...,
      "modeInfo": {...},
      "response": "[REDACTED]",
      "message": "[REDACTED]",
      "variableData": {...}
    }
  ]
}`

Field Path Sample value
Input tokens v[0].result.metadata.promptTokens 32543
Output tokens v[0].result.metadata.outputTokens 60
Completion tokens v[0].completionTokens 490
Resolved model v[0].result.metadata.resolvedModel "claude-sonnet-4-6"
Tool call rounds v[0].result.metadata.toolCallRounds (array, length 4) —
Per-round model v[0].result.metadata.toolCallRounds[N].modelId "claude-sonnet-4.6"
Thinking tokens v[0].result.metadata.toolCallRounds[N].thinking.tokens 0

No cachedTokens field present anywhere in the object. v is always a single-element array on this file (length 1).

[ozymandiashh]

Got it, and your dumps nailed it. This is a missing data source, not a pricing bug.

Root cause. The Copilot provider reads three places: the legacy CLI store (~/.copilot/session-state/), the OTel agent-traces.db, and the legacy extension transcripts (workspaceStorage/<hash>/GitHub.copilot-chat/transcripts/). On your setup none of those carry token counts: there's no session-state/, the OTel DB is opt-in and absent, and the transcript path only ever yields output-less rows. The place VS Code actually persists per-request usage for you is its core chat store, which the provider never read:

• workspaceStorage/<hash>/chatSessions/*.jsonl
• globalStorage/emptyWindowChatSessions/*.jsonl

So the calls that showed up came from a token-less fallback, while the real promptTokens / outputTokens sat unread in chatSessions. Hence 435/447 calls at $0.00.

Why it's not trivial. These files aren't plain JSONL records, they're a VS Code delta-journal: line 1 is a kind:0 snapshot of the session object, then kind:1 path edits ({"k":[...path],"v":...}) and kind:2 array appends ({"k":["requests"],"v":[...]}). You can't read a request off a single line, you have to replay the journal to reconstruct requests[]. Your second dump (the v-as-array shape) is exactly what let me model this.

The fix (PR linked below) adds chatSessions + emptyWindowChatSessions as a fourth source:

• replays the kind:0/1/2 journal (prototype-pollution-safe: __proto__ / prototype / constructor path segments are rejected),
• reads result.metadata.promptTokens / outputTokens (falls back to completionTokens) and prices on result.metadata.resolvedModel (e.g. claude-sonnet-4-6),
• avoids double counting: it prefers OTel when present and skips a workspace's legacy transcripts when that workspace has chatSessions.

Reproduced end to end against the exact request object you posted:

call: project=myproject model=claude-sonnet-4-6 in=32543 out=60 cost=$0.098529
TOTAL  calls=1  in=32543  out=60  cost=$0.098529   (was: 0 calls / $0.00)

If you can run the PR branch against your real ~/.config/Code and confirm the totals look right, that'd be the last bit of validation. One known limitation: this journal has no cache-token field, so cache reads/writes show as 0 for Copilot Chat unless you enable the OTel store.

PR: #563

[didlika]

Looks good now, thanks!

[ozymandiashh]

Glad to hear that, probably one of the hardest fixes I’ve had on this repo until now. Just couldn’t figure it out why it was happening.