One 5-Hour Kilo CLI Session and 20 Million Cache Tokens

TL;DR: One continuous Kilo CLI session over ~5 hours in Kilo CLI (OpenCode fork) produced 20.7 million cache tokens (plus input/output) on glm-5.2. This was part of a day where overall token usage reached 76 million tokens total. The cache from the long-running session was a major driver of the ~48% quota impact.

I was surprised when my Z.ai usage dashboard showed something like 48% of my quota burned in what felt like “just one task.” When I looked at the provided raw data, the numbers were eye-opening.

The numbers

All of this happened on 2026-07-12 in a single 5-hour window, not spread across the day.

The provided raw data showed:

• Overall token usage across the full day/period reached 76 million tokens.
• The long-running session alone produced 20.7 million cache tokens (plus its input and output).

Dominant cluster (the main session, 106 inferences):

• CACHE: 20,700,928 tokens
• INPUT: 693,083 tokens
• OUTPUT: 113,187 tokens

Averages per call in that cluster:

• ~195k cache tokens
• ~6.5k input tokens
• ~1.1k output tokens

The other two clusters (48 calls and 7 calls) were much smaller. The 20.7M cache tokens from the heavy session alone represented a huge portion of the quota burn that led to the ~48% reading.

What actually happened

I started a substantial coding/task session in Kilo CLI (the OpenCode fork) using a model with a 1M context window (glm-5.2).

I worked for about five hours straight. During that time I occasionally used subagents for specific subtasks.

Key factors that turned this into a token monster:

1. Everything stayed in one primary session.
   I never ran /new, /clear, or /fork. The whole thing was one long conversation thread.

2. Subagents still fed the parent.
   Even though Kilo/OpenCode subagents are supposed to run in isolated child sessions, their results (summaries at minimum) get pulled back into the main context. The parent session just kept growing.

3. 1M context removed the guardrails.
   On smaller windows the model would have started struggling or the system would have compacted earlier. With a million tokens available, it was happy to carry 150–250k+ tokens of accumulated history, tool outputs, and project state on almost every turn.

4. Cache did its job (too well).
   Large stable prefixes got cached aggressively. Great for per-token cost. Terrible for “how much quota did I just burn” visibility.

Roughly one inference every 2.8 minutes on average. Very agentic, very chatty loop.

The tooling reality in Kilo / OpenCode

Kilo has good tools for this, I just didn’t use them proactively:

• /compact (or /summarize) — manually shrink the current session
• /new — start completely fresh
• /fork — branch from an earlier message
• Keyboard shortcuts to jump between parent and child subagent sessions

There’s also compaction config you can tune:

// kilo.jsonc or .kilo/kilo.jsonc
{
  "compaction": {
    "auto": true,
    "prune": true, // drops old tool outputs — try this
    "reserved": 8000,
  },
}

Default prune: false means old command outputs tend to stick around.

Lessons I’m taking away

• A huge context window is a superpower and a quota trap for long sessions.
• “Using subagents sometimes” inside one long thread is not the same as proper task isolation.
• Session hygiene is part of the work when you’re doing multi-hour agentic runs:
  • Compact every now and then.
  • Start fresh sessions (or fork) when you switch major phases.
  • Be deliberate about what actually needs to stay in context.
• Even on a yearly plan where dollars are $0, the usage meters still matter.

This one long session produced over 20 million cache tokens (within a day that reached 76 million tokens total) from basically one evolving context.

If you’re doing long runs in Kilo/OpenCode (or similar tools), treat context management as a first-class part of your workflow. The model will happily eat everything you give it.

Numbers based on the provided raw usage data from 2026-07-12.