Unexpected High Usage After Model Switching - Two Incidents Affecting Zen Balance and Go Quota

Description

Summary

I experienced two incidents on two consecutive days where switching models inside long OpenCode sessions caused unexpectedly high usage and a real financial impact.

I understand that long contexts can be expensive and that switching models may prevent cache reuse. My concern is not simply that the models are expensive.

The problem is that the behavior was unexpected, there was no warning before the model switch, and some aspects of the billing/cache behavior still appear unexplained.

---

Incident 1 — Spark → GPT-5.6 Sol

Date: August 22, 2026

I was using Spark Contributor/Free in a long session. After the free model hit a rate limit, I manually switched to GPT-5.6 Sol to continue a relatively simple task.

The first successful Sol request showed:

• 874,001 input tokens
• 351 output tokens
• $9.8483 cost

That single request exhausted my remaining Zen balance and left my account at approximately -$2.31.

Because the charge was so unexpected, I investigated the local OpenCode files.

For the same request, the local records show:

• New input: 3 tokens
• Cache write: 436,999 tokens
• Output: 302 tokens
• Reasoning: 49 tokens
• Locally recorded cost: 2.190272

I understand that switching models in such a large session may require rebuilding cache and can be expensive.

What I cannot explain is:

Why did Zen charge $9.8483 when the local telemetry for the same request recorded a cost of 2.190272?

I would also like to understand how the backend calculated the 874,001 input tokens shown in the usage history.

---

Incident 2 — Spark → Kimi K3 / OpenCode Go

Date: August 23, 2026

The following day, something similar happened in another long session after switching from Spark Contributor to Kimi K3.

The usage history showed:

• ~408K tokens → $1.2259
• ~408K tokens → $0.1245
• ~408K tokens → $1.2265
• ~410K tokens → $0.1305
• ~411K tokens → $0.1321
• ~411K tokens → $0.1265

In this case, my local investigation confirms that the individual Kimi prices were mathematically correct.

The unusual part is the cache behavior.

The sequence was:

1. ~408K tokens as new input, no cache → $1.2259
2. ~408K tokens successfully reused from cache → $0.1245
3. Only about 16 seconds later, cache reuse dropped to zero and ~408K tokens were again treated as new input → $1.2265
4. Subsequent requests reused the cache normally again → ~$0.12–$0.13

The context size had barely changed.

I would like to understand why a successful cache hit was followed only seconds later by a complete cache miss in the same flow/model/provider, and then cache reuse returned normally afterward.

The local investigation found no subagents, compaction, obvious automatic retry, or hidden request that explains this.

---

Impact on OpenCode Go

Immediately after the second incident, my Go dashboard showed approximately:

• Rolling usage: 100%
• Weekly usage: 41%
• Monthly usage: 20%

My usage had been very low before this sequence.

The local files cannot reconstruct the complete Go quota ledger, so I would like the team to verify how these requests were counted toward my limits.

---

What I am asking the team to review

For the GPT-5.6 Sol incident, please verify:

• why the backend charged $9.8483 while local telemetry recorded 2.190272;
• how the 874,001 input tokens were calculated;
• which pricing/token categories were applied;
• whether any part of the charge was incorrect.

If there was an incorrect charge, I would like the amount to be refunded/credited and the resulting negative balance corrected.

For the Kimi K3 incident, please verify:

• why ~408K cached tokens were successfully reused;
• why the cache was completely missed about 16 seconds later;
• why cache reuse then returned normally;
• how this affected my OpenCode Go quota.

If abnormal cache behavior caused unnecessary quota consumption, I would also appreciate having the affected credits restored.

---

User experience concern

Regardless of whether these incidents are ultimately classified as bugs, I believe OpenCode should warn users before switching models in extremely large sessions.

For example:

This session contains approximately 400K tokens. The current cache may not be reusable by the new model and switching may result in significant usage/cost. Do you want to continue?

From the user's perspective, I was simply switching models to continue my work.

Instead, this happened twice in two consecutive days, first leaving my Zen balance negative and then significantly affecting my Go quota.

---

Evidence attached

I preserved and investigated the records from both incidents.

I am attaching:

• screenshots of both usage incidents;
• screenshot of the negative Zen balance;
• screenshot of the Go quota after the second incident;
• technical investigation reports for both incidents;
• critical and complete CSV timelines;
• a ZIP containing the evidence in an organized structure.

The investigations were performed on copies of the local OpenCode files. No auth.json, API keys, credentials, tokens, or sensitive prompt content are included.

I am not assuming that every high-cost request automatically means there is a bug.

I am asking for a clear explanation and review of these two incidents, and for any incorrect charges or quota consumption to be corrected.

opencode-evidencias-github.zip

Plugins

Not

OpenCode version

v1.18.21

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

Windows 11

Terminal

No response

Start with the attached technical reports, CSV timelines, screenshots, and the local OpenCode records described in the issue; no repository file, test, or reproducible steps are named. Trace both usage sequences against billing, cache, and quota records. Done means explaining the charge discrepancy, transient cache miss, and quota impact, or documenting that they cannot be verified.