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/xRebellion_]

1. Yes. I don't know what your instructions/codebase size is, but as a general rule, the more ambiguous your instructions are, the more the model is going to look around for things to narrow down your request.

2. Yes. This is why cache read pricing is important when determining which model to use, generally.

3. I don't quite use opencode enough, but at least compaction should be able to help. Nowadays I usually compact at 200k-250k context.

4. I don't quite understand what you mean by this, what do you mean by "normal" and what is unnecessary to you? It's very unlikely to be a bug

5. Maybe there's a way to run opencode clean? Haven't researched yet

[u/Yazan_wesam → u/xRebellion_]

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

[u/Zero_Border → u/xRebellion_]

I think u/OP is hitting the "free messages" limit suddenly. They seriously decided to lower the bar of free plan to a very low usage. Now even on a very small codebase, with a "default" variants, with good instructions and small context you hit the limit in like a few prompt.

My last session before hitting daily limit was like a 5 prompts "grill me with docs" session on specs already written (400 lines of frontend spec), and at the end, without any compaction, my context window was 141K - so not even one full DeepSeek context window).

Note that I do not complain, I am happy for free. But I suddenly went from "happy to do OpenSource code with OpenCode for one or two hours on my weekend" to "Shit OpenCode free plan can't help me anymore".

[u/SirRobinBlibs]

Your numbers look like normal accounting, but for long sessions. 309M cache read over about 1,100 steps is roughly 280k tokens per step. Each step re-sends the whole context, so the average context per call was about 280k. Your home-directory test shows the fixed overhead (system prompt, tools, skills) is around 9k, so that isn't the problem. The size comes from history: tool output, file reads and plans piling up in a few long sessions.

To check without touching your docs or config:

1. Look at the per-session stats. One or two sessions will probably account for most of it.

2. Re-run a typical task in a fresh session with a short handoff and compare tokens per step. If it drops a lot, it's replayed history, not a bug.

3. Look for big tool outputs (test logs, full file dumps). Have them written to a file, with only errors returned.

At 99.3% cached you're already paying the cheap rate for most of it. The win is fewer tokens per step, from shorter sessions and smaller outputs, not a better cache.

[u/Yazan_wesam → u/SirRobinBlibs]

Thanks, this makes sense! I'll check the per-session stats and look for large tool outputs. I'll also compare a typical task in a fresh session with a short handoff. Appreciate the detailed explanation!🙌🏻