Answers
If every session has to read the team's decisions before acting, doesn't that cost tokens on every single call?
It costs them once per session, and after that only what changed. A read of a project ends with a checkpoint. Present that checkpoint on a later call and the standing rules are referenced instead of written out again, and the space they would have taken goes to the material this particular task needs. Measured in production on a second read: 4,826 tokens referenced rather than reprinted. What is never skipped is the part that moves — work in flight, what landed since, and what ranks as relevant to what you are doing now. So checking what the team has decided before you act stops getting more expensive the more often you check, which is the property that decides whether anyone keeps doing it.
Last updated September 21, 2026
A read has a fixed half and a moving half, and only one of them repeats
Two reads of the same project ten minutes apart are not two copies of one thing. The standing half — the pinned decisions, the rules that apply to every task — is identical between them, word for word. The other half is not: the handoffs still open, the entries written since, and the ranking of everything else against the task you declared are all different on the second call, and they are the reason to call again at all. Sending the fixed half twice buys nothing, and it is not free: it comes out of the same budget as the moving half, so it does not merely cost tokens, it evicts the material that was relevant.
The side that knows decides what it already sent
The checkpoint is a token to present, not a claim to make. A client that decided for itself what had already been delivered would be keeping a second copy of the truth, and the first time the two disagreed the read would silently be missing a rule nobody could point at. So the shape is: present the checkpoint, and let the side holding the memories decide whether it still holds. If it does not — a new conversation, a context that was compacted, a checkpoint this connection never received — everything comes back in full. That is the safe direction to fail, and it is why the cheap path never has to be trusted to be used.
Reading on every task only survives if reading is cheap
The expensive version of this idea is familiar and it does not hold: a rule that says check the shared document first, obeyed for two weeks and then quietly routed around, because the check costs more than the thing being checked. Making the repeat read cheap is what keeps the habit honest. You can ask what has already been decided in the seconds before committing to an answer, several times in one session, without each check taxing the work it is supposed to protect. The economy is not the feature — it is what keeps the discipline affordable enough to still be running in month three.
What it looks like in practice
A scheduled routine opens by reading its project: the standing rules, the handoffs still in flight, last night's log, and the memories that rank against what it is about to do. That first read is the expensive one, and it should be — it is the whole reason the routine is not starting from nothing. An hour in, it is about to commit to a recommendation, and the honest move is to check again: is there a decision here that this contradicts? Without a checkpoint, that check means paying for the same standing rules a second time, and a third time when the question comes up again before the next claim. With the checkpoint presented, the second call brings back what is in flight and the map of what else the project holds, with the standing block referenced rather than reprinted — 4,826 tokens on the measured case. The routine checks three more times before it finishes. None of those three would have happened if each one cost what the first one did.
Questions people ask about this
- What exactly stops being sent?
- The block that did not change: the standing rules and pinned decisions already delivered in this session, written out once and referenced afterwards. Everything else is sent every time, because everything else can have moved — a handoff someone opened twenty minutes ago, an entry written by another session, the ranking of the collection against the task you named on this call. The saving is precisely in the part where repetition carries no information.
- What if a rule changed between the first read and the second?
- Then it comes back. The decision about what to reference is made where the memories live, against the state at the moment of the call — never against a snapshot your side is holding. That is the difference between referencing and caching, and it is why the mechanism is safe on a repeated check rather than only on the first read of the day.
- Could we cache the rules on our end and skip the second call?
- You could, and you would be choosing the one failure this is built to avoid: a local copy that is right until it is wrong, with nothing to tell you which day you are in. The cost of being wrong here is not a stale string on a screen — it is an assistant acting on a rule the team retired, confidently, with no signal that anything is off. Referencing keeps the decision on the side that knows; caching moves it to the side that cannot.
Where this is verifiable
Product documentation on this site (How it works, Install), the answers on the context file that outgrew a page and on why a larger context window does not settle what memory settles, and the session-checkpoint and read-budget behaviour in the sanctioned product spec. The figure quoted was measured in production on 7 September 2026. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/cheaper-reads-when-nothing-changed