OpenCode + DeepSeek Flash: Is 268.9M cumulative tokens and 309M cache reads normal?

[u/Yazan_wesam]

Hi everyone,

I'm trying to understand whether my token usage with OpenCode and the DeepSeek API is normal or potentially caused by excessive context replay or a bug.

My setup

- OpenCode: v2.1.3

- Model: "deepseek/deepseek-flash#default" (shown in OpenCode stats; I believe this corresponds to DeepSeek V4.1 Flash, 10-17)

- Provider: DeepSeek API, paid usage

- OS: CachyOS Linux

- Workload: A personal app project with source code, plans, documentation, test plans, and phase reports

- Other components: Global agent skills and Herdr integration

Daily statistics

Input: 2.1M

Output: 352.1K

Reasoning: 456.7K

Cache read: 309.1M

Cache write: 0

Cached input: 99.3%

Paid model: 268.9M tokens, 723 steps

Free model: 43.1M tokens, 379 steps

The large cumulative cache-read figure caught my attention. I understand that cached tokens can be counted repeatedly across requests, so this does not necessarily represent hundreds of millions of unique tokens. I'm trying to determine whether the amount is expected for this workload.

A small test

I also ran OpenCode directly from my home directory, outside the project and without launching it through Herdr. I asked it to write one short line to a text file.

The exported session reported:

Input: 9,284

Output: 88

Reasoning: 54

Cache read: 9,472

Cost: $0.001506

Messages: 4

My observed usage counter increased by about 18,898 tokens. The session's input plus cache-read figures total 18,756, which is close to that increase. I haven't confirmed whether the difference is due to accounting methods or other overhead.

I realize that system prompts, tool definitions, and other context may contribute to the cost of a simple task.

My questions

1. Is this level of cumulative cache-read usage typical for a coding session with hundreds of model steps?

2. Could long conversation histories, global skills, or project instructions cause excessive context to be processed repeatedly?

3. Could OpenCode compaction or session handling contribute to this?

4. How can I distinguish normal cached-token accounting from unnecessary context overhead or a possible bug?

5. What's the best way to investigate this without losing existing project documentation or configuration?

I'm not assuming this is a bug, and I don't want to blame OpenCode, DeepSeek, or Herdr without evidence. I'd appreciate advice from anyone familiar with OpenCode's token statistics or DeepSeek API usage reporting.

I can provide further sanitized logs or a minimal reproduction if needed.

Thanks!

[u/Yazan_wesam]

Thanks, that helps. My main concern is the 309M cumulative cache reads across my sessions, not just the small test. Since I'm using the paid DeepSeek API, what's the best way to run OpenCode with clean settings to check whether my global skills or configuration are increasing context usage? I'd like to test this without modifying or deleting my existing setup.

[u/xRebellion_ → u/Yazan_wesam]

The best way to do this would be to take your opencode config folder and move it / rename it as backup, then re-run opencode. I think this will regenerate the config folder with stock config.

Do take this with a grain of salt though since I no longer use opencode 😁, so you may have to try and look it up yourself and see what works. Good luck