Non-cached input tokens are dropped from usage, so input is always 0 and cost is under-reported #146

This finding & PR is 100% AI. Apologies if its completely inaccurate and pointless.

Versions

• @stablekernel/opencode-cursor 0.10.0
• @cursor/sdk 1.0.37
• opencode v2.1.2

Summary

mapUsage passes Cursor's inputTokens to opencode as inputTokens.total. Cursor's inputTokens doesn't include cached tokens: the SDK's own totalTokens is inputTokens + outputTokens + cacheReadTokens + cacheWriteTokens. opencode treats total as including cache and subtracts cache read and cache write to get the non-cached input. On any cached turn that comes out negative and gets clamped to 0, so non-cached input tokens never show up in opencode's token counts or cost.

Current code (src/provider, mapUsage)

inputTokens: {
  total: usage.inputTokens,
  noCache: undefined,
  cacheRead: usage.cacheReadTokens,
  cacheWrite: usage.cacheWriteTokens
}

Observed

opencode stats --days 0 --cost --models for one day of cursor/claude-opus-5-5 use, 18 steps:

The Cursor usage dashboard showed about 14.9M tokens for the same day. The ~4.75M gap is about what you'd expect for missing non-cached input. Input has been 0 for every Cursor-model step I checked.

Expected

Non-cached input tokens are reported and priced at the model's input rate.

Suggested fix

function mapUsage(usage) {
  const cacheRead = usage.cacheReadTokens ?? 0;
  const cacheWrite = usage.cacheWriteTokens ?? 0;
  return {
    inputTokens: {
      total: usage.inputTokens + cacheRead + cacheWrite,
      noCache: usage.inputTokens,
      cacheRead,
      cacheWrite
    },
    outputTokens: {
      total: usage.outputTokens,
      text: undefined,
      reasoning: usage.reasoningTokens
    }
  };
}

The suggestion also passes reasoningTokens through, since the SDK includes it in the turn-ended usage when present.

Possibly related

The price table (MODEL_COST) is applied through two routes: the config hook, which lets user provider.cursor.models entries override it, and the provider.models route, which always uses the built-in table. If list prices don't match a user's actual Cursor rates, there's no reliable way to override them. Could user-configured cost be honoured on both routes?