[Bug]: DCP compression makes session cost tracking discontinuous / wrong

[AutomatorAlex]

[Bug]: DCP compression makes session cost tracking discontinuous / wrong

Plugin version: 3.1.8 (latest)
OpenCode version: 1.3.11
OS / Setup: Linux, global DCP config

---

Problem Statement

When DCP's compress tool replaces a range of messages with summaries, the post-compression token count used by OpenCode's session cost tracker drops sharply. This creates a non-monotonic, discontinuous cost curve that no longer reflects actual API spend.

For users who rely on per-project cost reporting (e.g. opencode stats --project or opencode export + custom scripts), the final dollar figure is wrong because:

1. Tokens that were paid for are no longer counted after compression.
2. Summary tokens are added to context but their cost is not tracked.
3. The delta is unpredictable — it depends on when the model chose to compress, which messages were in the range, and how efficiently the summary was written.

Concrete Impact

Scenario	What opencode stats shows	What actually happened
Session at 200k tokens → compressed	Cost drops from $0.80 → $0.45	API spend never decreased; it only increased to ~$0.85
Long-running agent loop	Cost oscillates up/down each compression	Cost should be strictly monotonic
Monthly client invoicing	Underestimated by 30-50%	Significant revenue loss

Reproduction

1. Start a new session with DCP enabled (default settings).
2. Run an agentic loop that accumulates tool calls (e.g. file reads, codebase searches).
3. Watch token count grow to ~200k (or your configured maxContextLimit).
4. Trigger compression manually (/dcp compress) or let nudges fire.
5. Run opencode stats --project before and after compression.
6. Observe: total cost decreases or makes a sharp discontinuity.

Expected Behaviour

DCP should not retroactively alter the cost basis of already-billed tokens. The session's cumulative cost should remain strictly equal to the sum of all per-step API usage, regardless of how much DCP has compressed the active context window.

Suggested Fix

Conceptually there are two layers that need isolation:

1. Billing layer — counts actual per-step API tokens. Never touched by DCP.
2. Context layer — counts effective tokens in the prompt DCP sends to the model. Managed by DCP.

Currently OpenCode appears to compute stats from the context layer (post-DCP). Options:

• A) DCP tracks a separate counter (e.g. state.stats.rawTokens) that accumulates per-step API usage before compression. Expose this via /dcp stats raw or a field in opencode export.
• B) DCP appends a metadata block to each compression summary containing the pruned token count and associated cost. A downstream script can sum summaryCost + liveCost to get true total.
• C) OpenCode core fixes its stats / export pipeline to read from per-message usage metadata instead of the live token counter.

Workarounds (for users today)

1. Use opencode export + a script that reads per-step usage objects rather than the final session token count. I wrote a reference implementation here: opencode-cost-tracker.py.
2. Track externally via provider dashboard (OpenRouter, etc.) by session or API key.

---

Additional Context

• Related upstream OpenCode issues: anomalyco/opencode#8945, anomalyco/opencode#5951
• OpenCode has known cost-tracking bugs (double-counting cache tokens, missing subagent costs, missing title-generation costs). DCP compression makes the existing inaccuracies much worse because it actively rewrites the cost basis.
• DCP's own /dcp stats shows pruned tokens, but there is no way to add those pruned tokens back to OpenCode's session total to reconstruct true spend.