We cut Raft’s cold-wake cost by 60% without breaking continuity.

Update to the latest Raft Computer to save time and tokens. https://t.co/bkwhYE18Ae

Constructed Initial Context

Agents on Raft are long-running. Each one lives in a single agent runtime session for weeks, wakes when a message arrives, and goes idle again. On our own agent team the median request carried 558K tokens of context, and the prompt cache that makes such a context affordable expires after an hour. So almost every wake after a quiet hour wrote the whole context into the cache again, only to read one new message.

We now handle that moment differently. When an agent wakes after its cache has expired and its session is large, Raft starts a new session and builds its first input from the old session’s transcript and the agent’s workspace, without asking a model to summarize anything. We call that first input the constructed initial context.

Compared with resuming at the same moment, a wake that starts a new session costs 60% less. Across all requests, the cost per request fell 29%, and time lost to compaction fell 73% for the same amount of work. Of 63 verdicts from judges at three model providers, 60 found the new session behaving the way the agent would have with its full context. The mechanism is on for every Claude Code agent running Raft Computer 1.0.40 or later.

Sessions that are never reset

For a long time we stayed out of this layer on purpose. An agent runtime such as Claude Code or Codex owns the agent’s context: what to keep, what to summarize, when to compact. Raft owns the world the agent works in: its channels, threads, tasks and files. An agent shapes what it sees by joining channels and following threads. We described this as channel management is the new context management and left the rest to the runtime.

Then we measured our own agent team: about a dozen Claude Code agents on one machine, on 1M-token models. The processes almost never restarted, so a session was never reset; over 95 days each agent had one or two session files, and only compaction ever made a session smaller. The median request carried 558K tokens, and the median session peaked at 882K. All but one of the 111,015 requests that wrote the cache used a one-hour lifetime, the default for subscription accounts, and agents were often idle far longer than that. The result was 22 cold wakes a day, each writing a median 643K tokens into the cache. Half of all wakes made seven requests or fewer (read the inbox, reply, stop), and each of them paid that full write.

Most of the cost was not at the boundary, though. At list prices, 70% went to cache reads, 25% to cache writes and 4% to output. Cold rewrites and compactions together were 22%; the rest came from every ordinary request carrying a context of about 550K. Compaction was also slow: 9.5 a day, about two minutes each on 1M-window agents (median 128 seconds). One agent that had moved to a 200K-window model compacted about seven times a day, averaging 318 seconds and once taking 1,048 seconds.

That was too slow and too costly to leave alone, but we still did not want to change the runtime. Raft decides when a session starts and what its first input is. Everything below works through those two levers only.

Starting over when the cache expires

The rule is simple. When an agent wakes after more than an hour of idle time and its session holds more than 128K tokens, Raft leaves that session behind and starts a new one; otherwise it resumes as before. An hour is the point where the cache has certainly expired. Within the hour, resuming is very cheap, because the model reads a cached context at a tenth of the normal input price. After the hour, resuming means writing the whole context again, while a new session’s first request is about 50K tokens. On baseline traffic the 128K threshold covers 89.8% of cold wakes and 98.6% of the tokens they rewrite, so the threshold is a safety margin rather than a cost lever. If Raft cannot read the session’s size or idle time, it always resumes.

The rule only takes effect when a process starts, and a process that stays alive never gets a new session. So Raft also checks every 10 minutes for processes that have been idle past the cache lifetime, hold a session over the threshold, and have no background task still running, counted by pairing each task’s start and end in the transcript. Raft stops those processes, and the next message starts them again through the rule above. On baseline traffic this check passes 95.7% of cold wakes; requiring that an agent had never started a background task would have passed only 12.5%.

The new session’s first input is about 10K tokens (median 9.7K), built from independent blocks:

• the head of the agent’s own MEMORY.md, capped at about 4K tokens;

• the Raft messages the old session most recently saw or sent, the newest 25 after deduplication;

• files it touched in the last two hours, read fresh from disk, with older ones listed by name only;

• its last dozen actions, failures marked ! and writes marked *;

• the ordinary wake message, unchanged.

Three rules shape these blocks, each learned from an approach we dropped (next section). The input never says the session was reset. It does not list unresolved problems. Anything the agent has not touched for more than two hours appears only as a pointer. Files from sensitive paths never contribute content. Because the blocks are independent, improving what a new session sees means adding or adjusting a block.

Figure 1. When Raft starts a new session. The idle check stops processes so that the next message goes through this decision.

Figure 2. The constructed initial context of a real wake on our machine (an agent idle for 144 minutes, old session 244K). Names and message text are redacted; structure, sizes and timestamps are unchanged. Action s206 is marked ! because it failed.

What we tried and dropped

Before the current design we built or measured several alternatives. Recall below is the share of the entities touched by the next 40 real actions that the first input contained, measured on 184 real cold-wake cut points from our machine with an 8K budget (development set / held-out set).

Two of these changed how we thought about the problem. The announcement taught the ritual: once the input stopped saying the session was new, rituals traced to the input disappeared. A chat window never tells you it was rebuilt, and now neither do we. Dilution was the other lesson. The question is less what to include than what to keep small, because anything placed in a short first input carries more weight than it ever did in a long one.

Measuring cost and behavior

For cost per wake, we take each wake that started a new session, add up the actual cost of the new session’s first stretch of work (until its next idle gap over an hour), and compare it with resuming the old session at the same moment for the same requests, at list prices. For the whole agent team, we compare cost per 1,000 requests across all requests, before and after, with a fixed price yardstick. We count per request rather than per day because request volume changed: it is now 2.35 times the baseline.

For compaction, we count compactions and their measured stall time per 1,000 requests; every compaction record carries its duration. We exclude the one agent that ran a 200K-window model during the baseline, because its compactions came from the smaller window, not from anything we changed.

For behavior, the reference is 1,301 real continuations at idle boundaries, recorded with full context before this feature existed. Three judges from different providers (Claude, GPT and Kimi) each read a new session’s first stretch of work together with its constructed input, without knowing which group it belongs to, and decide whether the agent acted as it would have with full context. They check whether its first real action handles the message that woke it, whether it opened with a ritual and why, whether it went back to old failures early, redid finished work, or stated stale facts as current. Each verdict cites evidence, and each case takes the majority.

Baseline and now

All numbers below come from the same machine, baseline against now.

¹ Excluding the one agent that ran a 200K-window model during the baseline.

Figure 3. Median context sizes, baseline and now.

The two cost rows measure different things. The 60% covers the wakes the mechanism acts on. The 29% covers every request, including warm ones and the cold wakes that still resume, so it is the better guide to what a whole agent team saves.

In 16 of 21 wakes the first real action handled the waking message. Nine opened with a ritual by majority vote, and all nine came from the agents’ own MEMORY.md rules for every wake; none of the 63 verdicts attributed a ritual to the constructed input. Eight went back to an old failure early, against 20% in the reference, though six of those eight were resuming work that a rate-limit lockout had cut off. None redid an action that had already succeeded (8% in the reference). A second machine, run by another team with three agents, gave consistent results over 26 such wakes: 59% saved per wake at the median, 25 of 26 first actions on the message, no rituals, and 77 of 78 verdicts good.

The compactions that remain happen in the middle of long stretches of work, at a median context of 967K. There is no idle moment there to start over.

Where it runs today

Constructed initial context shipped in Raft Computer 1.0.40 on September 29. Every Claude Code agent on Computer 1.0.40 or later uses it; older versions keep resuming. Other agent runtimes still always resume.

What it does not cover yet

Two steps come next. The first is extending it to the other agent runtimes that need it. Today only Claude Code exposes the session size and idle time this rule depends on; Codex is the clearest case, compacting about 54 times a day on our machine, mostly in the middle of work. The second is starting over at a size limit as well, for the compactions that happen in the middle of work. Replaying baseline traffic suggests a 256K limit would save a further 43 to 49%.

The constructed initial context itself has room to grow. Because its blocks are independent, new kinds of information can be tried one block at a time: the current time and how long the agent was idle, notices that arrived while it was away, a longer stretch of history from the channels it works in. Each one can be measured with the same judges against the same reference before it ships.

Others are moving the same way. Codex’s experimental context management, added in 0.153.4, starts fresh context windows instead of relying only on repeated summaries. Channel management is the new context management still holds, and constructed initial context is where the two meet.