Classification: METHOD/DESIGN GUIDANCE. This article reports no universal context-size optimum or token-savings percentage.
View the full infographic → · View this article
A model’s maximum context is a capacity limit, not a target. Filling every available slot can carry stale history, irrelevant files or unused tool schemas into a request without making the requested result more correct.
Allocate context around the task
Start from the acceptance criteria. Include binding instructions, source evidence that can change the answer, the minimum relevant task state and the tool definitions actually needed. Reserve room for expected output and model-specific control tokens. The budget should follow the work, not the other way around.
Retrieve only what can affect the decision
- Load source files or records on demand rather than preloading a directory.
- Carry forward a concise verified checkpoint rather than a full transcript.
- Keep active requirements distinct from historical context.
- Remove unused tool schemas only after verifying the workflow does not depend on them.
- Cap output and retries; a large context does not justify an unbounded response.
Test the boundary, not just the text
Record the actual request at the provider boundary where permitted, including wrappers, message roles, tool definitions, cache fields and retries. Provider-reported counts may not match a local tokenizer. Compare like-for-like task quality and verified outputs; do not call a shorter prompt an optimisation if it changes the result or forces additional retries.
Keep the evidence visible
The canary documented in our request-boundary article reported 13,289 input tokens and 10 output tokens in one bounded run. It does not establish each component’s token share or imply every workflow needs less context. Use the Token Optimisation Rules Builder for selectable context rules, then verify them against your task.