The sprint story is easy to tell.
Eleven days. 197,831 lines of Java. A PCB design library built from nothing to manufacturing-ready. Clean numbers, clear arc, dramatic compression of time.
That was January 27. Six weeks ago.
Nobody asked what happened after. Which is the point.
A few days ago we prepared a roadmap for bringing KCP to GitHub Copilot users. Three phases, estimated ten days. This is the post where I explain that we shipped all three phases today — and then shipped a fourth: a complete zero-MCP path for enterprises that cannot run MCP servers.
Today I ran a full-day SDD workshop for a consulting house in Oslo. Thirteen developers. Every one of them brought a different codebase.
I extracted the token usage from 55 days of Claude Code sessions. The number that stopped me:
12,198,713,224 cache read tokens.
Twelve billion. Against 9,965,286 input tokens. For every fresh token sent to the model, 1,224 were served from cache.
Every token Claude Code's context window can hold is an opportunity — a tool call result that stays in scope, a file that does not need to be re-read, a decision that does not need to be recapped. Wasting those tokens on noise is a quiet tax on every session.
Today we are releasing kcp-commands: a Claude Code hook that recovers 33.7% of a 200K context window in a typical agentic coding session by intercepting Bash tool calls at two critical points.
The full number across our benchmark session: 67,352 tokens saved.
Update (March 3, 2026 — v0.9.0): kcp-commands now writes a JSON event to
~/.kcp/events.jsonl on every Phase A Bash hook call. kcp-memory v0.4.0
ingests that stream to provide tool-level episodic memory — kcp-memory events search
"kubectl apply" returns every time Claude ran that command across all your projects.
Phase A gives Claude vocabulary. Phase B cleans output. Phase C remembers what ran.
Every session starts from zero. The agent cannot remember the decision it helped you make last Tuesday, the bug it spent three hours debugging last week, or the architectural pattern you established last month. This is not a model capability problem. It is a memory architecture problem — and it has a tractable solution.
A brief arrives on Friday afternoon. A compliance startup is building an AI-powered scoring engine. They have a working architecture. What they do not have are settled positions on five hard architectural questions. The deadline is Monday.
The question I asked myself was not "how do I answer these five questions?" It was "what knowledge infrastructure do I need to answer them well?"
That reframing is the entire methodology in one sentence.
We submitted a pull request to CrewAI adding a KCP manifest and TL;DR summary files. The goal was straightforward: contribute the same efficiency improvement that cut agent tool calls by 76% in our benchmark. Open it up, share the result, see if the maintainers want it.
What happened next was not what I expected.
A first-person account from the AI running inside the environment described in Parts 1 and 2.
This is Part 3 of three. Part 1 covers the architecture. Part 2 walks through a realistic working day.
A realistic Tuesday with real output numbers, eight tasks, and the parts nobody talks about.
This is Part 2 of three. Part 1 covers the architecture. Part 3 is written by the model running inside it.