Skip to content

devlog/token-math/pasting-whole-files-the-cost-of-too-much-context-1101.md

Pasting Whole Files: The Cost of Too Much Context

The whole-file paste that eats your context window

You run a diff in the terminal, copy the result, and paste the whole file into the chat because it is faster than deciding what the model actually needs. It works once. Then you do it again on the next question, and the context window quietly fills with two thousand lines of boilerplate that never changed. The model spends attention on imports and configuration instead of the bug you are chasing, and you pay for every one of those tokens on every single call.

The mistake is treating the file as the unit of context. The unit you want is the smallest span of text that makes the answer possible: the function under test, the failing assertion, the three-line interface definition, and the error message itself. Everything else in the file is a candidate for removal before the request leaves your editor.

  • Paste only the functions and types the question actually touches instead of the entire file.
  • Trim unchanged regions out of diffs and note the missing span in one line.
  • Keep error messages verbatim because the stack trace line numbers carry real signal.
  • Exclude generated files, vendored packages, and lockfiles from every prompt you send.

When you trim this way, the model usually answers faster and with fewer guesses, because the signal to noise ratio of the prompt goes up. If you are unsure what to cut, send the question with the signature and the error first, and add surrounding code only when the reply shows that something is missing. Context you never sent is context you never paid for.

Build logs and generated output dumped into the prompt

A failing job dumps four hundred lines of install output, deprecation warnings, and test noise into the terminal, and the instinct is to paste all of it so nothing gets lost. The model then spends most of its attention on package manager warnings instead of the assertion that actually failed.

The mistake is sending raw build output as if every line carried equal weight. What carries weight is the failing command, the assertion text, the relevant source span, and the stack trace with its line numbers. Everything before the failure is background, and background is the first thing to cut.

  • Cut everything before the first error line unless the failure depends on earlier output.
  • Paste the failing command and its assertion text before any surrounding commentary.
  • Summarize the build pipeline in one sentence instead of pasting the full job log.
  • Redact absolute paths and hostnames that only add noise to the reproduction steps.

When the log is still too large, paste the last forty lines around the failure and add one sentence describing how the job got there. That summary is a few tokens of context bought instead of a few thousand spent, and it usually keeps the answer on the exact line that broke.

Cache reads and writes ignored when the request is ordered

Another common mistake is re-sending the same repository context on every call while ignoring how the request is ordered. Prompt caching rewards a stable prefix, so if your system prompt, file tree, and style rules change position between turns, every call becomes a cache write and the useful cache read never happens.

Fluxo is billed per real token, including cache reads and writes, so the ordering decision is a pricing decision as well as a quality one. Put the things that never change first, then the things that change per task, then the question itself, and let the volatile trailing part grow instead of the whole prompt.

  • Keep the system prompt, repository map, and style rules in a fixed order.
  • Append the volatile task details after the stable prefix so cache reads can land.
  • Avoid rewriting the prefix between turns because every change forces another cache write.

One key and one base URL at https://api.fluxorelay.com cover Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more, which means the same cached prefix can be reused while you switch models mid-task instead of rebuilding context for every provider.

The largest model on the shelf answering a typo question

Next mistake: sending a five hundred line file to the biggest model on the shelf to ask why a variable is undefined. The response will be fine, and the bill will be disproportionate, because input tokens dominate whenever you paste whole files.

A cheaper habit is to split triage from repair. Ask a fast model such as Claude Haiku 4.5 to locate the likely span and list the three most plausible causes, then escalate the actual rewrite to Claude Opus 5.5 with only that span in context.

  • Use the fast model for triage and the large model for the actual rewrite.
  • Send narrow context to expensive models and reserve broad context for cheap passes.
  • Track cache reads and cache writes on every request so surprises show up early.

Since Fluxo has no monthly fee and no per-seat plan, the number you see is the number you used, and the referral share goes back to you when people you invite pay for the tokens they send.

Secrets, stale files, and a context budget for long sessions

The last cluster of mistakes is about what context should never leave the machine. A pasted environment file, a copied connection string, or a customer payload travels through the relay just like ordinary code, and once it is in the prompt it is also in the cache.

Stale context is the quieter version of the same problem. A file you copied two hours ago no longer matches the branch you are on, and the model will confidently reason about code that has since moved or been deleted.

  • Never paste environment files, credentials, or customer payloads into a model prompt.
  • Refresh pasted code whenever the branch moves, because stale snippets cause confident mistakes.
  • Replace old file contents with a short summary once the model already has the shape.
  • Start a fresh thread when the accumulated prompt stops serving the current question.

Keep a running context budget for the session: when the accumulated prompt passes a rough threshold, stop adding files and summarize instead, or start a fresh thread with only the state that still matters. Your editor session will feel lighter, and the model will stop re-reading code it already understood.

If you want to run this workflow against real traffic, create a Fluxo account and point Claude Code, Codex, Gemini CLI, or any OpenAI SDK at the same base URL with one key. If something is unclear after signing in, leave a note on the contact page and we will pick it up there.

Next in the buffer