Context is the whole bill

A single Claude Code session on a mid-sized repository can spend 40,000 to 100,000 input tokens before you commit a line of code, and most of that is the model re-reading files it already saw two turns earlier. Portal by Spotify sits between your codebase and the model as an indexing and retrieval layer. In my own runs on a real feature task, it reduced the token volume by roughly 90 percent. That number holds, but it is not magic and it is not universal. It comes from one specific change: the model stops receiving whole files and accumulated tool output on every turn, and starts receiving scoped, relevant slices instead.

The savings are real where the work is exploratory - navigating an unfamiliar codebase, tracing a bug across modules, refactoring something that touches ten files. On a single small script, Portal saves you almost nothing, because there was never much context to trim. So treat the 90 percent as the ceiling for a particular class of workload, not a headline you can staple to every task. What actually changed is the shape of the context sent to the model, and that shape is where the entire cost of an agentic coding session lives.

Here is the part worth internalising before anything else: in Claude Code, your bill is driven by input tokens, not the code the model writes back. Generation is cheap and bounded. Context is expensive and, by default, it grows every turn. Any tool that claims to cut your token usage is really making a claim about how it controls the context window. Portal’s claim is defensible because it attacks that mechanism directly instead of dressing up a prompt trick as an optimisation.

To see why the reduction is that large, you have to understand how Claude Code actually accumulates cost. Every time the agent reads a file, runs a grep, lists a directory, or gets a tool result, that output is appended to the running conversation. On the next turn, the model does not get a fresh, minimal view - it gets the entire history re-sent as input so it can reason with continuity. Read three 800-line files early in a session, and those 2,400 lines ride along in the input on every subsequent turn until the context is compacted or the session ends. The token meter is not measuring what the model thinks. It is measuring what the model is forced to re-read.

Prompt caching softens this but does not remove it. Anthropic’s caching lets repeated prefixes be billed at a lower rate, so re-sent context is cheaper than paying full price each turn. That is genuinely useful, and Claude Code uses it. But caching still assumes the wrong default: that the model should hold whole files and full tool transcripts in view at all. You are paying a discounted rate on context you never needed at full resolution in the first place. Caching optimises the cost of a bloated context. It does not question whether the context should be bloated.

Portal changes the default. It indexes the repository once - symbols, definitions, references, file structure - and then, when the agent needs to understand a function or a module, it serves the relevant slice rather than the whole file. Instead of loading a 900-line service to answer a question about one method, the model receives the method, its signature, and the handful of references that matter. Multiply that across a session with dozens of reads and the re-sending of each read on every turn, and the compounding is where the 90 percent comes from. You are not sending less once. You are sending less, repeatedly, on every turn for the length of the session. That is the mechanism, and it is a system-level change, not a clever instruction.

The most common mistake is believing token usage is about how much the model writes. People try to shrink outputs, cap response length, or ask for terser code, and they are surprised the bill barely moves. It barely moves because output was never the cost centre. On a real coding session the input-to-output ratio is heavily lopsided toward input - often ten to one or worse once files and tool results start stacking up. Optimising generation to control token spend is tuning the wrong dial.

The second mistake is assuming a bigger context window is the fix. A 200,000-token window does not reduce your usage; it raises the ceiling on how much you can waste before the session breaks. Larger windows make the accumulation problem more expensive, not less, because the model will happily fill them with whole-file reads and long tool transcripts that all get re-sent each turn. Capacity is not efficiency. Treating a larger window as a solution is how teams end up with sessions that technically complete but cost several dollars each and slow down as the context fills.

The third mistake is thinking this is a prompting problem. There is a whole genre of advice about writing leaner instructions to Claude Code to save tokens, and it is mostly noise against the real numbers. Your carefully trimmed system prompt might be a few hundred tokens. The files re-sent across a twenty-turn session are tens of thousands. Prompt discipline is fine, but it is rounding error next to context management. The reason Portal moves the number and prompt-tweaking does not is that Portal operates on the layer that actually holds the tokens - what gets retrieved and re-sent - while prompt advice operates on a layer too small to matter. If you want to control cost in an agentic system, you control the flow of context into the model, not the wording of the request.

The first move is not installing Portal. It is measuring what you actually spend. Run a representative task in Claude Code with token accounting visible - a real feature or bug, not a toy - and write down two numbers: total input tokens and total output tokens for the session. On a mid-sized repo you will typically see input dwarf output by ten to one or worse. That ratio is your diagnosis. If input is already small, Portal will do little for you and you can stop here. If input is large and climbing turn over turn, you have confirmed the problem is context accumulation, and that is exactly the layer Portal operates on.

Portal’s job is to index the repository once and then serve scoped slices on demand instead of whole files. In practice that means pointing it at your codebase, letting it build the symbol and reference index, and connecting it to Claude Code as the retrieval layer the agent reaches through when it needs to understand code. On the surface the workflow barely changes - you still ask for a refactor or a bug trace - but underneath, a request about one method returns that method, its signature, and the callers that matter, not the 900-line file it lives in. The discipline is to let retrieval do the navigating and stop reflexively reading entire files by hand, because every manual full-file read you trigger goes straight back into the accumulating context you were trying to shrink.

Match the tool to the work. Portal earns its keep on exploratory, cross-module tasks - tracing a bug through five files, refactoring something with a dozen references, understanding an unfamiliar service. On a single small script it saves almost nothing, and bolting an indexing layer onto that is just overhead. Be honest about which kind of session you are in before you credit or blame the tool for the number it produced.

The failure mode to watch is under-retrieval. Scoped slices are cheaper, but a slice that is too narrow can starve the model of context it genuinely needed - the caller three hops away, the config flag that changes the method’s behaviour, the test that documents the contract. When that happens the model does not stop; it guesses, and you get a confident wrong edit. So keep a fallback to full-file reads for the moments that warrant them, treat the model asking for more context as a signal rather than a nuisance, and validate output the same way you would without Portal: run the tests, read the diff. Retrieval changes what the model sees, not whether it can be wrong. Cheaper context is only a win if the work still holds up.

Take a concrete shape of task: a checkout bug in a mid-sized service where the order total comes out wrong for discounted items. The logic is spread across a controller that receives the request, a pricing service that applies discounts, a shared money utility that handles rounding, and a validation layer that should have caught the bad state. Four files, none of them small, plus the greps and directory listings the agent runs to find them.

Without Portal, the session accumulates fast. The agent reads the controller (600 lines), the pricing service (900), the money utility (300), and the validation module (500) - 2,300 lines before it has even formed a theory. Add the tool output from three or four greps and a couple of directory listings. By turn twelve, every one of those reads is still riding along in the input on each turn, and you are north of 80,000 input tokens for a bug that ultimately lives in eight lines of the pricing service. Caching discounts the re-sends, but you are still paying, repeatedly, to keep 2,300 lines in view in order to reason about eight.

With Portal indexing that same repo, the shape changes. When the agent needs the discount logic, it receives the discount method, its signature, the handful of call sites, and the rounding utility’s relevant function - a few hundred lines of genuinely relevant code instead of 2,300 lines of mostly irrelevant file. Multiply that reduction across the same twelve turns of re-sending, and the input for the session lands closer to 8,000 tokens than 80,000. That is where the 90 percent comes from - not from one smaller read, but from a smaller read re-sent on every turn for the length of the session. The bug is still the same eight lines. What changed is that the model was never forced to carry the other 2,290 to find them.

The same example shows where it can bite. If Portal’s slice of the pricing service omitted a caller in a separate module that passed in the malformed discount, the model might patch the symptom in the wrong place because it never saw the source. That is the under-retrieval risk made concrete. The answer is not to distrust retrieval but to verify against behaviour - reproduce the bug, apply the fix, run the failing case again. The token savings are real and large; they do not replace the check that the fix is actually correct.

Portal by Spotify is not a token trick. It is context management implemented as infrastructure, and the 90 percent reduction is a byproduct of one decision: stop sending whole files and full tool transcripts on every turn, and send scoped, relevant slices instead. Everything else - the indexing, the retrieval, the symbol graph - is in service of that single change to the shape of the context window.

For anything running in production, that is the point that matters. Cost, latency, and reliability in an agentic system are all downstream of how much context you push into the model per turn. A session that carries thousands of irrelevant lines is not just more expensive; it is slower, and more prone to the model losing the thread as the window fills. Controlling the flow of context is the discipline that separates a system that survives real use from a demo that happens to complete. Portal is one implementation of that discipline. If you were building serious AI tooling in-house, you would end up building some version of it yourself.

So do not adopt the number. Adopt the principle behind it. Whoever controls what the model re-reads controls the cost and the failure surface of the entire system, and no amount of prompt trimming, bigger context windows, or terser outputs touches that layer. Measure your input-to-output ratio, treat context as a budget you spend deliberately, and use retrieval to send the model what the task needs and nothing more. Portal cut my usage by 90 percent on the right kind of task. The reason it could is the only thing worth keeping: in agentic coding, the context window is the bill, and the bill is a design decision - not a given.

---

Contains a referral link.