Memory Placement Engineering on Grok Bot + Kimi K3: Facts Get an Address, Reasoning Gets a Window

Grok Bot remembers by accumulating a machine. Kimi K3 remembers by holding a window. Pick the wrong one and your agent either forgets what you told it on Tuesday, or costs ten times what it should. One line in the Grok Bot documentation should stop you cold: The headline feature of the product is that it remembers files, browser sessions, app logins, all compounding across turns instead of resetting. And you cannot open the drawer. That is not a bug report. It is a design position, and the exact opposite of the one Kimi K3 takes. Almost every complaint that starts with "the model got dumber" is not about the model. It is about where somebody put the memory.

An agent can only remember in two places A place. A disk that survives. Files, cookies, a logged-in browser profile, a database. It persists whether anyone is looking or not, and accumulates until something prunes it. A window. The context assembled for one run, held while it happens, thrown away. Rebuilt from scratch every time, so it holds exactly what somebody decided to put in it.

Every agent product is a bet on one of these. Grok Bot bets on the place. Kimi bets on the window. Neither is wrong they fail in opposite directions, and knowing which is how you stop debugging the wrong thing.

Grok Bot's bet: memory is a place Every Bot runs against a persistent Linux VM with a browser, a filesystem and a terminal. It does not reset between tasks, does not depend on your laptop, and keeps sessions so you never re-authenticate. And the machine is tied to your account, not to a Bot. All your Bots share the same computer, the same files, the same logins. That single fact is the entire product: one Bot logs into a dashboard, the next picks up the session already authenticated. For any site without an API it is the only thing that works. The failure direction: Opaque. You cannot inspect what it holds, correct it, or export it. When an agent answers strangely, you cannot open its memory and find the stale fact. Shared. One login placed there is available to every Bot you own. On August 20 that machine stuck and every Bot on the account went down together. Chrome profile isolation resets daily. It drifts. A place accumulates and nothing prunes it. A credential rotated two months ago. A CSV that was correct in June. None of it announces itself from the inside, stale and fresh look identical. An agent with a persistent place does not forget. That is the feature, and the problem. So a place needs the one thing Grok Bot does not give you:

Kimi's bet: memory is a window K3 gives you 1,048,576 tokens. The obvious move is to fill it. The tooling is built to stop you. Subagents run in isolated contexts. A subagent takes a task, works in its own context, and returns only conclusions. Its intermediate reasoning and tool-call records never enter the main history the mess was structurally prevented, not summarised away afterwards. Concurrency is plan-gated, from two subagents up to eight. Compaction is automatic, and the official guidance is explicit: use retrieval, stable cached prefixes and compaction rather than filling the window because you can. Skills load on demand. A file on disk with a whenToUse line enters the window only when the work matches. Everything you might need is not everything in front of the model.

The failure direction is the mirror image. It evaporates nothing survives that you did not arrange to survive. And rebuilding it costs money, which is the part almost nobody writes about.

The bill is a memory design problem K3 charges $3.00 per million input tokens on a cache miss and $0.30 per million on a hit. A factor of ten, decided entirely by whether the model has seen your prefix before. Most people read that and think "caching is on, good." On K3 it is more delicate, and the reason is architectural. K3 is a hybrid: full-attention layers store per-token KV in the normal way, but the Kimi Delta Attention layers update a recurrent and convolutional state at every single token and cannot afford a snapshot at every possible prefix boundary. vLLM decouples those large physical KDA state blocks from fine-grained prefix matching, registering snapshots inside the blocks and copying them before extension, so a long shared prompt can reuse both the KDA state and the paged KV. The translation matters more than the mechanism: Your prefix has to be genuinely stable. Not roughly stable. Stable from token zero. Which gives the highest-leverage rule in agent design, and it is almost never stated: volatile content goes at the end.

A timestamp at the top. A file list that re-sorts. A fresh tool result above the standing instructions. Any one of them changes the prefix, and everything after it is a miss you re-pay full freight for a context you already sent. In code the discipline is an ordering rule and one comment you will thank yourself for:

This is why two teams running the same crew, on the same model, can be an order of magnitude apart on cost and both blame the model. One of them put the clock at the top. You do not have to guess whether yours is broken:

The placement rule Everything above collapses into one sentence. Facts get an address. Reasoning gets a window. A fact is anything you could look up again: a credential, a price list, last quarter's numbers, a logged-in session. It belongs in a place, referenced by address. A fact in the window is a fact you pay to re-read forever, and it is the thing most likely to break your prefix when it changes. Reasoning is anything that only makes sense inside this task. It belongs in the window, and it should die there. Reasoning in a persistent place is how an agent confidently repeats a conclusion it drew in March from data that changed in May, with no way for you to audit where it came from. The difference is one line of a payload:

Get it backwards and you get the failures people spend weeks debugging:

Not one of those is a model quality problem. Every one is a placement problem. Written down, the rule fits in one file that every seat reads:

Which to build on Grok Bot when the memory you need is a session sites with no API, tools that require a real login, work where the credential and the browser state are the hard part. Keep sensitive keys off it and accept that you cannot audit it. Kimi Code and K3 when the memory you need is a derivation where you have to show how a number was produced, where runs must be reproducible, where a stable prefix is achievable. Most real setups want both, split by kind rather than by product: the place holds credentials and artefacts, the window holds the thinking, and nothing crosses that line by accident.

What I cannot tell you I have not measured cache hit rates on a real crew. The 10× spread is published pricing; how much of it you actually capture depends on prompt structure I have not benchmarked broadly enough to generalise from. Grok Bot's memory is inspectable by nobody, so I am describing it from the outside, like everyone else. I cannot prove what it holds neither can you, which is the point of that section and also its limit. The KDA caching mechanism is from vLLM's own writeup. I have read it, not profiled it, and inference engines move fast. I have not instrumented compaction either. And the placement rule is a design heuristic that has held up for me, not a benchmark result.

The point A model's intelligence, in practice, is almost entirely a function of what is sitting in front of it at the moment you ask. K3 has a million tokens of room and the best open scores available. That buys you nothing if the million tokens are full of stale facts, or if the one fact that mattered was on a disk nobody read. Grok Bot will remember something you have forgotten telling it, and never show you what. Kimi will forget everything you did not arrange to keep, and show you exactly what it kept. Those are not competing products. They are competing answers to the only question that matters: what deserves to persist. Everything else is a prompt.