51enuxu/cc-cache-playbook — explained in plain English
Analysis updated 2026-05-18
Reduce repeated context sent on every turn in a long running chat gateway
Raise prompt cache hit rates for a subscription billed LLM upstream
Detect and log when a conversation's context has quietly broken down
| 51enuxu/cc-cache-playbook | 0xpira/sskills | 8thpark/geode | |
|---|---|---|---|
| Stars | 25 | 25 | 25 |
| Language | — | JavaScript | TypeScript |
| Setup difficulty | hard | easy | moderate |
| Complexity | 3/5 | 2/5 | 2/5 |
| Audience | developer | developer | vibe coder |
Figures from each repo's GitHub metadata at analysis time.
This is a technique writeup to apply to your own gateway code, not a ready to run project.
This repository is a written playbook, not a piece of software you install. It documents lessons learned from running a self built chat gateway (for example a Telegram bot or web chat) that sits in front of Claude Code as a subscription based upstream, where usage is billed by request count rather than by the amount of text sent. The author explains how they cut the extra context sent on every turn from twenty to thirty thousand characters down to about two thousand, while raising their cache hit rate to ninety six percent. The core idea is that with a subscription plan, a long running conversation costs nothing extra to keep alive, but recalculating a conversation from scratch after a cache miss is expensive in wasted requests. So the advice is to keep sessions continuous whenever possible, and only start a fresh one when the conversation has genuinely broken off, saving heavy summarization for when a hard context limit is close. To decide whether a new message continues an old session, the playbook recommends hashing the content of the last user message as an anchor, rather than counting messages, since message counts can shift for unrelated reasons. For information that changes each turn, such as memory notes or status updates, it suggests sending only the parts that changed, marking removed sections clearly, and occasionally resending everything in full as a safety check. Content that never changes, like a persona's core instructions, is placed in a cached system prompt section instead of being repeated. The author also stresses logging context size, cache hit rate, and how many segments changed on every turn, since without this visibility a system can quietly get worse until it is obviously broken. A closing section on fallback summarization covers batch limits, backup upstream providers, and a check for a broken provider that returns an identical response no matter what is sent in.
A practical writeup on cutting repeated context and raising cache hit rates for a chat gateway running on top of a subscription based Claude Code upstream.
The explanation does not state a license for this content.
Setup difficulty is rated hard, with roughly 1day+ to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Don't trust strangers blindly. Verify against the repo.