Token usage

[n-osennij]

Opencode go, DeepSeek V4 Flash, plannotator v0.19.21, opencode TUI 1.15.10

1. First message Create a plan to create a simple one-page website about cats..
2. A page with the plan opens. I add one comment and click 'send feedback' button
3. Opencode processes it, and the corrected plan opens. I click Approve (no switch) button.
4. In opencode, I type the message "Are wy ready? No mistakes?"
5. I check the token usage panel and notice a strange behavior.

For some reason, the second call completely overwrote the session and the cache. I assume that if I previously had a conversation and a full cache, it would have been wiped out.

For some reason, my message "Are wy ready? No mistakes?" also arrived at an empty session without a cache

All of this is very strange and dangerous, as it significantly increases spending on expensive models. I am attaching the session export file:

session-ses_1aaf.md

[backnotprop]

I've traced through your logs, thanks for sharing. I don't see anything immediate.

I don’t think Plannotator reset the session. That small 812 token row is probably OpenCode naming the chat in the background.

The later 11k token row means the chat history was still there.

Cache Read: 0 is probably an OpenCode/DeepSeek caching/reporting thing, not Plannotator deleting anything.

---

I'm gonna create my own test and cost harness tonight though, just to be sure. I will report my findings here.

[backnotprop]

I tested this against OpenCode 1.15.10 + DeepSeek V4 Flash + Plannotator 0.19.21.

I do not see evidence that Plannotator wipes or replaces the OpenCode session.

The attached session export does not look like a reset:

• initial user message is still present
• first plan is still present
• denied Plannotator feedback is still present
• revised plan is still present
• approval is still present
• later Are wy ready? No mistakes? message is still in the same session

I ran local A/B sessions and read OpenCode's SQLite usage data.

Pair 2:

Baseline:

• session: ses_1a7eef96effe4WHVps6Ze0gSYL
• cache read: 24,192
• assistant calls: 4
• tool calls: 2

Plannotator:

• session: ses_1a7ebc755ffeIG2ewnz16Di7R5
• cache read: 77,824
• assistant calls: 7
• tool calls: 5
• submit_plan calls: 2

The Plannotator run did not show cache reads dropping to zero.

One real thing found: after denied feedback, the model can produce an invalid submit_plan call before retrying correctly. In my test that failed call cost:

• cost: $0.0008022672
• input: 3,998
• output: 455
• reasoning: 273
• cache read: 13,824

That is real overhead, but it is not a session/cache wipe.

Current conclusion:

• likely not Plannotator resetting the session
• likely usage-panel/provider-reporting behavior, or an OpenCode Go / DeepSeek cache reporting edge
• separate issue: harden submit_plan instructions/schema path to avoid invalid retry calls

Branch with collector/methodology: https://github.com/backnotprop/plannotator/tree/fix/oc-tokens