--- title: "Capy on Morph Ultra: cache hits are free, and we make a lot of them" url: "https://www.morphllm.com/blog/capy-morph-ultra" description: "A Capy thread resends its whole history on every turn. Morph routes each turn back to the GPUs that already hold that history, so most of it is a cache hit, and Morph Ultra does not count cache hits against its rate limits. Here is how that works and how to set it up." date: "2026-11-11" author: "Nick Khami" --- # Capy on Morph Ultra: cache hits are free, and we make a lot of them Capy now connects to Morph Ultra. Paste your Morph API key into Capy and your threads run on Kimi K3.1 and DeepSeek V4.1 Flash for one flat $200 a month. This post is about why that pairing works. A coding agent spends most of its input re-reading things it has already read. Morph is built so those re-reads are cache hits. And Ultra's rate limits do not count cache hits at all. ## An agent mostly re-reads Every turn of an agent loop sends the whole conversation back to the model: the system prompt, the tool definitions, every file it opened, every command it ran, every answer it gave. Only the last step is new. So turn 40 of a Capy thread is turn 39 plus one more step. If the server still holds the work it did on turn 39, its KV cache, it skips all of that and only processes the new step. The part it skips is a cache hit. It comes back faster, and it costs a fraction of fresh input. ## A cache hit depends on where your request lands Here is the part that gets missed. Whether a turn hits the cache is not only about your prompt. It is about where the request lands. The KV cache lives in the memory of the GPUs that processed your last turn. Send the next turn somewhere else, a different server, a different region, a different provider behind a gateway, and the cache is not there. The whole conversation gets processed again from the start. We measured this on an hour of our own Kimi K3.1 traffic today. Turns that stayed in the same region as the turn before got 97.6% of their input from cache. Turns that moved to another region got 86.3%. That sounds close until you look at what was left over: a turn that moved had more than five times as much uncached input to process. So we built the serving stack around keeping each conversation next to its cache: - **Every request is routed by what is already cached.** Our global router checks how much of your prompt each region already holds and favors the one with the least new work to do. Inside that region, the router follows every worker's cache through live cache events and sends the request to the worker with the longest match. - **A conversation stays in one region.** When a conversation carries a session id, the router binds it to one region and only moves it when that region is far busier than the others. For Ultra on Kimi K3.1, the bar is so high that a conversation only moves when its region is overloaded. - **Cache is not thrown away when GPUs fill up.** In the main region for both models, the GPUs write their cache into a shared pool of host memory, terabytes per model, and that pool spills to NVMe instead of deleting. A turn that comes back after a long build or test run still finds its history. Since Ultra launched on November 9, 95.8% of Ultra input on Kimi K3.1 and 93.2% on DeepSeek V4.1 Flash has come from cache. ## Ultra's rate limits skip cache hits Ultra has no token meter on Kimi K3.1 or DeepSeek V4.1 Flash. Each subscription has a per-minute rate limit on two things for each model: uncached input tokens and output tokens. Cached input counts toward neither. That makes your cache hit rate a multiplier on the plan. Every uncached token the limit allows brings its cached tokens along with it:
Cache hit rateInput per minute, as a multiple of the uncached limit
80%5x
90%10x
95%20x
At a 95% hit rate, one minute of the uncached limit carries twenty times that much context. On Ultra, a serving stack that keeps you on a warm cache decides how much work your $200 does. The current limits are in the [Ultra docs](https://docs.morphllm.com/ultra-plan#rate-limits). The costly moment is a cold start: a brand new thread, or a subagent, with nothing cached yet. Each Ultra limit has a burst reserve on top of it for exactly that. ## Keeping a Capy thread warm A few habits keep more of every turn in the cache: - **Stay on one model per thread.** Each model has its own cache. Capy keeps a thread on its model unless you switch it, and a switch starts the thread cold. - **Compact less often.** Capy's **Compact at** setting decides how full a thread gets before it summarizes its history. The summary replaces the history the cache was built on, so the next turn starts cold. Admins set it per model in Settings, then Models. - **Keep tools steady mid-thread.** Tool definitions sit near the top of every prompt. Adding or removing an MCP server partway through changes them, and everything after them misses. - **Expect subagents to start cold.** A Capy subagent starts from its own prompt, not the parent's history, so its first turns are uncached. That is what the burst reserve covers. ## Set it up 1. [Get Ultra](/dashboard/billing?plan=ultra). After checkout, the setup page creates your Morph API key. 2. In Capy, open [Settings, then Models](https://capy.ai/settings/models). Under **Your connections**, add a connection, search for **Morph Ultra**, and paste the key. 3. Pick Kimi K3.1 or DeepSeek V4.1 Flash in a thread. Capy does not charge for tokens on your own key. Machine time still bills to your Capy balance. The full walkthrough is at [morphllm.com/products/ultra/capy](/products/ultra/capy).