The Hidden Cost of Re-Explaining Context to Every AI Tool

Take the preamble you paste at the start of a fresh AI session. The stack, the constraints, the schema, the two decisions from last month that explain why the code looks the way it does. Call it 800 tokens, which is a modest estimate for anything real. You do that six times a day, across three tools, because the tools do not share state.

Run the numbers.

preamble       = 800 tokens
sessions/day   = 6
workdays/month = 21

800 * 6 * 21 = 100,800 input tokens/month, per person

# Sonnet-class input pricing at $3 / million tokens:
0.1008 * 3   = $0.30/month

# 30 engineers:
                ~$9/month

Nine dollars. The token cost is not the problem, and any post that leads with the token cost is selling you something. Current input pricing makes pasted context effectively free at individual scale. Prompt caching makes it cheaper still if the preamble is stable and you hit the cache.

The cost is in the other column.

reconstruct    = 3 min   (recall it, find it, paste it, correct the misread)
6/day * 21     = 378 min/month = 6.3 hours/month, per person

# 30 engineers:
                 189 hours/month  ~= 1.1 FTE

Three minutes is conservative if you have ever actually watched yourself do it. It is rarely a clean paste. It is opening the old thread to find what you said last time, remembering the constraint you left out, and then correcting the model when it proceeds on the stale version. Even at 90 seconds, thirty people spend half an engineer's month retyping things a machine already knew.

The interruption tax on top

The three minutes undercounts because it prices the typing and not the context switch. Gloria Mark's interruption research at UC Irvine put the recovery time to return to a primary task at roughly 23 minutes when attention moves through intervening tasks. Not every re-explanation triggers a full switch, and it is a mistake to multiply 23 minutes by six and claim you lost two hours. But the shape is right: leaving your problem to go reassemble background for a tool is a switch away from the thing you were holding in your head, and the reassembly happens exactly when you had momentum, because that is when you reached for the tool.

The failure that does not appear in any column

Here is the part that actually costs money, and it is unmeasurable by construction: the context you forget to paste.

You re-explain the service architecture and the database. You omit that the Postgres instance is behind pgbouncer in transaction pooling mode, because you were not thinking about connection handling. The model suggests a pattern using session-level prepared statements. It is a completely correct suggestion for the problem you described. It fails in production, and the failure looks like a model error when it was an input error.

This is the asymmetry that makes re-explaining worse than it looks. An LLM given 80% of the relevant context does not produce 80% confident output. It produces fully confident output about a subtly different problem. There is no signal in the response that distinguishes "answered your question" from "answered a neighboring question you accidentally asked." A human collaborator says "wait, aren't you behind a pooler?" A fresh session cannot, because it does not know what it is missing.

Context reconstruction drift

There is a second-order version that is harder to spot. Each re-explanation is written from memory, so each one is slightly different. Monday you describe the ingestion path as "a queue consumer that writes to Postgres." Thursday, thinking about a different problem, you describe it as "a batch job that upserts nightly." Both are partially true. They are different specifications.

So the model answers a slightly different problem each time, and the answers disagree. Then you conclude the tool is inconsistent and unreliable. It is not. It was consistent about three different problems that you described on three different days, and the variance you are seeing is variance in your own prompt, not in the model.

The compounding damage is that inconsistent answers erode the habit of trusting the tool for anything load-bearing, which pushes people back toward using it for isolated snippets, which is where the least value is.

Why per-vendor memory does not close this

Every major assistant now has some memory feature, and each one is scoped to its own vendor. That is not an oversight or a roadmap gap. Memory is a retention mechanism: the accumulated context is the switching cost, and no vendor has an incentive to make it portable.

The practical consequence for someone using three tools:

• You now maintain three divergent memory stores. What you told one is invisible to the others, so the re-explanation problem persists between tools even though it is solved within each one.
• The stores drift independently. Tool A learned the Go migration in March, tool B still believes the service is TypeScript. You now get confidently contradictory answers depending on which tab you are in, and no way to reconcile them.
• None of it survives the vendor. Switch models, or use a coding agent that talks to a different provider, and you start from zero with no export path that any other tool can consume.

Which means per-vendor memory partially fixes the cheap problem (the tokens, the typing) and does not touch the expensive one (omitted context producing confidently wrong output), because the omission happens whenever you cross a tool boundary, and crossing tool boundaries is the normal case.

The measurable cost of re-explaining context is a rounding error. The unmeasurable cost is the answer you acted on that was correct for a problem you did not have.

What actually helps

The honest version of the fix is boring: the context has to live somewhere outside any single tool, get written once, and get read by whatever you are using. Checking a versioned context file into the repo gets you most of the way and costs nothing, and if that is enough for you, do that instead of buying anything. It breaks down when the context is personal rather than project-scoped, when it changes mid-conversation, or when you are on a phone.

That gap is the specific thing Unimatrix is for: one store, reachable over MCP by whichever model you happen to be in, so the preamble is retrieved rather than retyped. Whether that is worth a subscription depends entirely on how many tools you actually switch between, which is a calculation you can do from the numbers above and the pricing page.