Time-to-context: the hidden tax on AI-assisted development

Time-to-context is how long an AI needs before it can act correctly on your project — the real bottleneck in AI-assisted work, and how to drive it to zero.

Time-to-context (TTC) is the time an AI needs, after connecting to a project, before it can act correctly. It is the gap between "the model is online" and "the model knows what this project is, why it is built this way, what has been decided, and what comes next." On most teams this gap is paid over and over — every new chat, every new model, every new teammate's agent — and almost no one measures it.

This article defines the tax, names the liability behind it, puts a number on it, and explains why — counter-intuitively — it gets worse as your models get better.

The tax nobody puts on the invoice

Every time you open a fresh AI session, you re-explain. You paste the architecture. You remind it that you already tried the "obvious" approach and it failed for a specific reason. You re-state the constraint that isn't written down anywhere. Then you do real work for twenty minutes — and tomorrow, with a new session, you pay it again.

That re-explaining is time-to-context, and it compounds:

• Across sessions. Yesterday's reasoning lives in a transcript you'll never reopen. The next session starts from zero.
• Across models. Switch from one assistant to another and the new one inherits none of the hard-won why. It re-suggests the path you already rejected.
• Across people. A teammate's agent has no idea what your agent concluded last week. Two AIs, same repo, zero shared memory.

Think of the underlying liability as context debt — the uncaptured why a project accumulates, scattered across closed chats, merged PRs, and people's heads. Like technical debt it compounds; unlike technical debt, every new model and teammate pays the interest from scratch. Time-to-context is just the meter; context debt is the principal.

The cost is not only minutes. It's wrong minutes: an AI with low context confidently rebuilds something you deliberately removed, or re-litigates a decision that was settled for good reasons. The most expensive errors in AI-assisted development aren't hallucinated APIs — they're hallucinated intentions.

Put a number on it

The tax feels invisible because it's never on one invoice — it's smeared across every session. Make it visible with a back-of-envelope model (substitute your own numbers):

A 5-engineer team opens ~6 fresh AI sessions per person per day. If each costs ~8 minutes of re-explaining before the AI is useful, that's 5 × 6 × 8 = 240 minutes/day — roughly 20 hours a week for a five-person team, and it scales from there. And that's before the rework caused by an AI acting on context it never actually had.

Score your own TTC — open a brand-new session on a real task and count: (1) how many turns until the AI's first correct, non-trivial action; (2) did it re-propose anything you've already decided or reverted; (3) how much of your first three messages was context you've typed before. "Several / yes / most of it" means your context debt is high — and recoverable.

Why a bigger context window doesn't fix it

The intuitive fix is "just give the model more context." Bigger windows, more retrieval, the whole repo in the prompt. It helps at the margin and misses the point. Time-to-context is a selection-and-trust problem, not a capacity problem.

• More tokens raise the ceiling on how much fits. They don't decide what belongs. Dumping the full history in front of a model buries the three decisions that matter under three thousand that don't.
• Raw history is the what, not the why. A diff tells you a function changed. It cannot tell you that you chose this design over a cleaner-looking one because the cleaner one broke under a production constraint. That reasoning is the expensive part, and it's the part that never makes it into the window.

Retrieval alone makes it worse

Teams reach for RAG — retrieve the relevant history, inject it, done. But this is the core of RAG's limitations for project memory: retrieval optimizes for similarity, not currency or truth. It will happily surface a year-old design note, a closed PR's rejected approach, or a since-reverted decision, and hand it to the model as relevant. Without an anchor that says this was superseded, the model can't tell live reasoning from dead reasoning — so it acts on the corpse. More retrieval without anchoring doesn't lower time-to-context; it raises it, by supplying more confident, stale material to be wrong with.

The counter-intuitive part: it gets worse as models get better

Most teams assume smarter models will need less of this — that capability will paper over missing context. The opposite is true.

A weak model that lacks context stalls and asks. A strong model that lacks context acts — confidently, quickly, and at scale — on whatever partial, stale picture it assembled. Capability without context isn't safer; it's faster in the wrong direction. So as models improve, time-to-context doesn't shrink — its downside grows.

And it compounds non-linearly. Every model or teammate you add multiplies the re-explanation surface, and every low-context action — rebuilt code, re-litigated decisions — becomes more context debt someone has to notice and correct later. The principal rises faster than headcount. Which is exactly why the fix isn't a better model; it's a better substrate of context underneath every model.

What "low TTC" looks like

High TTC. Monday, you and an AI decide to tear out a GraphQL gateway and go back to plain REST — the schema churn was costing more than the flexibility earned at your surface area. That reasoning lives in Monday's closed chat. Thursday, a fresh session opens the repo, sees REST endpoints, and three turns in proposes: "this would be cleaner behind a GraphQL layer." You re-explain. Again.

Low TTC. The Monday decision was recorded as an anchored ledger entry:

decision  4f3a9c…  "Drop the GraphQL gateway, return to REST"
  why: schema churn cost more than the flexibility earned at our surface area.
  supersedes  9b1c2e…  "Add a GraphQL gateway"

Thursday's AI connects, reads the assembled current truth, sees that GraphQL was tried and reverted and why — and doesn't re-propose it. No human in the loop. That's time-to-context trending to zero.

Driving time-to-context toward zero

If TTC is a selection-and-trust problem, the solution is a small, durable record of reasoning that is curated, current, and verifiable — delivered to the AI automatically. Three properties matter:

• Capture the why, not just the what. Code and commits already store the what. The missing layer is the reasoning: the decision, the rejected alternative, the constraint. Context engineering is the discipline of paying down context debt — where time-to-context is the metric, context engineering is the practice that moves it.
• Anchor every claim. Each item of context is tied to the immutable record of the event that produced it, and corrections reference what they supersede. The model can trust it — and see what was reverted — instead of guessing.
• Deliver it on connect, not on request. A fresh model should get the assembled truth the moment it connects — over a standard interface like MCP — not when a human remembers to paste it.

This is what Lifeline does: an append-only, content-addressed, anchored ledger of a project's why, served to any AI over MCP, so a new model connects and already answers what / why / decided / next.

Try it in two commands — open source, no signup:

pip install lifeline-context python -m lifeline context

Key takeaways

• Time-to-context is the time an AI needs before it can act correctly on your project — the real bottleneck in AI-assisted work, and most teams never measure it.
• The liability behind it is context debt: the uncaptured why that compounds, where every new model and teammate pays the interest from scratch.
• Bigger windows add capacity; retrieval without anchoring adds stale confidence; better models add confident speed in the wrong direction. None of them solve selection or trust.
• Driving TTC toward zero means capturing the why, anchoring every claim (with supersession), and delivering the assembled truth automatically on connect.

Frequently asked questions

What is time-to-context? Time-to-context (TTC) is the elapsed time between an AI connecting to a project and the moment it can act correctly — knowing what the project is, why key decisions were made, what is decided, and what is next. Lower is better; the ideal is near-zero.

What is context debt? Context debt is the uncaptured why a project accumulates — the reasoning behind decisions that lived only in chats, PRs, and people's heads. It is the liability behind a high time-to-context: like technical debt it compounds, but every new model and teammate pays the interest from scratch.

Why doesn't a bigger context window reduce time-to-context? A larger window raises the ceiling on how much text fits, but it does not decide what belongs there. Time-to-context is a selection-and-trust problem, not a capacity problem: the model needs the right why, anchored and current, not a larger pile of raw history.

Why does time-to-context get worse as models get better? A weak model that lacks context stalls and asks; a strong model that lacks context acts — confidently, quickly, at scale — on whatever stale picture it assembled. Capability without context is faster in the wrong direction, so the downside of high time-to-context grows as models improve.

Related reading: What context engineering is · How AIs inherit each other's context. Lifeline is an open-source context runtime — git for reasoning.