A 1M context window lets an AI model work with up to roughly one million tokens in a single context. For software teams, that can mean examining source code, tests, API contracts, and architecture notes together. It does not mean every repository fits, every dependency is noticed, or an entire application can be rewritten correctly in one response.
The useful question is where the extra context changes an engineering decision. A migration plan spanning several modules may benefit from a large, carefully assembled input. A small bug fix may be faster and cheaper with the relevant files and a test. This guide covers how to choose between them, budget the tokens, calculate the cost, and evaluate the result.
Capacity is not the same as understanding
Use a larger context when the task needs relationships across more evidence. Measure whether it catches important dependencies and reduces review time. Filling the window is not a success metric.
The Short Answer: Which Tasks Need Long Context?
| Development task | A useful starting approach | What to verify |
|---|---|---|
| Local bug fix or autocomplete | Selected files and targeted search | The relevant caller, interface, and failing test are present |
| Cross-module migration planning | A larger, versioned context bundle | Dependencies, assumptions, and unsupported conclusions |
| Pull-request review | Diff plus affected dependencies; expand when needed | Real defects found, false positives, and review time |
| Repository onboarding | Search or retrieval with source references | Answers point to the current implementation |
| Requirements-to-code mapping | Requirements plus relevant code and tests | Evidence for each requirement, with gaps marked explicitly |
What a 1M Token Context Window Actually Contains
A context window is the information available while a model generates a response. In Anthropic's context-window documentation, that includes instructions, conversation messages, tool definitions and results, supplied documents, and the generated output. Thinking tokens also consume capacity under the model's accounting rules. The maximum output length is a separate limit: a million-token context is not a million-token answer.
A token is a unit produced by the model's tokenizer, not a line of code or necessarily a whole word. Identifiers, punctuation, language, and formatting affect the count. There is no reliable conversion from "500,000 lines of legacy code" to "fits inside 1M tokens." Count the actual request using the tokenizer or counting endpoint for the model you will call.
Anthropic documents 1M-token support for models including Claude Sonnet 4.6 and Opus 4.6. Check the exact model and hosting platform you use: an IDE integration may reserve capacity for tools, truncate files, or compact conversation history before the underlying model's limit is reached. Provider documentation describes API capacity, not necessarily what your coding tool sends.
The window is also distinct from persistent memory. A repository summary saved by an agent can be loaded into a later request, but the model does not retain the original files simply because it saw them earlier. Our CTO guide to how LLMs work explains the broader architecture behind these integrations.
Will Your Codebase Fit? Build a Token Budget First
Start with the task, then inventory the evidence it needs. Include owned source files, relevant tests, schemas, configuration, and selected documentation. Leave generated bundles, vendor directories, binary assets, and unrelated logs out of the default package. Keep dependency versions when they matter; a migration may need a lockfile or its relevant entries even when it does not need the installed dependencies.
Here is an illustrative allocation for a model with a 1,000,000-token combined window. It is a planning example, not a measurement of a typical repository or a recommended target size.
| Context component | Example allocation | Why it is there |
|---|---|---|
| Selected application source | 600,000 tokens | Implementation and cross-module dependencies |
| Relevant tests and fixtures | 150,000 tokens | Expected behaviour and existing regression coverage |
| Schemas, specifications, architecture notes | 100,000 tokens | Contracts and intended behaviour |
| Instructions and tool definitions | 30,000 tokens | Task rules and available operations |
| Current question and prior task discussion | 20,000 tokens | The change being investigated |
| Reserved output, including thinking if used | 50,000 tokens | Must also fit the model's output limit |
| Unallocated headroom | 50,000 tokens | Room for a subsequent step, subject to recounting |
This leaves 900,000 tokens of initial input. A later tool result and the previous response can consume the remaining room, so recount at each step rather than assuming the first request's budget lasts for the whole session. Anthropic's token-counting endpoint estimates request size before generation; the response usage fields report actual consumption.
Where More Context Helps Software Development
Legacy migration and cross-module refactoring
Suppose a backend is moving from a synchronous payment client to an asynchronous one. The relevant evidence may span request handlers, retry logic, webhook processing, scheduled jobs, and tests. A larger context can put those relationships in the same analysis instead of forcing the model to reason from one file at a time. Ask for a dependency map and a phased migration plan before asking for patches.
This still has a boundary. A selected repository snapshot will not reveal an undocumented external consumer, a production-only setting, or a runtime path absent from the supplied material. Have the analysis list missing evidence and assumptions. A useful plan tells the engineer what to investigate next as well as what the code appears to do.
Pull-request reviews with the affected contracts
A diff changing a response field is easier to review when the model also sees the serializer, callers, API schema, and contract tests. That is a reason to expand beyond the diff, not automatically to include every file and all Git history. Supply relevant context from identified base and head revisions so the reviewer can distinguish existing behaviour from the proposed change.
Requirements-to-implementation tracing
A model can draft a mapping from requirement IDs to functions and tests when the specification and implementation are available together. Require evidence and mark each item as supported, partial, missing, or unclear. This is review assistance: a generated mapping is not proof that the implementation satisfies every requirement. Clear specifications make the task easier; our software development process and SRS guide covers how those requirements fit into delivery.
Long Context vs RAG: Use the Evidence the Task Needs
Retrieval-augmented generation, or RAG, selects relevant material before the model answers. For source code, retrieval can combine text search, symbol references, dependency information, and semantic search. A vector database is one possible component, not the definition of the entire approach. Long context gives you more room for the material you select.
| Approach | Useful when | Main failure to watch |
|---|---|---|
| Large preassembled context | A bounded task depends on many connected files | Important evidence is included but overlooked |
| Targeted retrieval | Questions are narrow or the repository is too large to send | The retrieval step omits a critical dependency |
| Hybrid: retrieve, expand, then analyse | You can start small and follow dependencies as needed | Expansion misses a relationship or adds irrelevant material |
For interactive coding, begin with the task, changed files, and nearby dependencies. Expand when a question cannot be resolved from that set. For a broad migration, assemble a larger subsystem snapshot and let the model request additional evidence. Both approaches need current source references and a way to detect omissions.
The Lost in the Middle study found that the position of relevant information affected performance in the models it tested. RULER extended long-context evaluation beyond finding a single fact to tasks such as multi-hop tracing and aggregation. These 2023–2024 results do not score today's models, but they explain why "the answer was somewhere in the prompt" is not an adequate quality test.
What Does a Large-Context Code Review Cost?
For a concrete calculation, Anthropic's published pricing table, checked for this revision, lists Claude Sonnet 4.6 at $3 per million base input tokens and $15 per million output tokens. The following scenarios assume 5,000 billed output tokens per call, uncached input, and standard API pricing. They are arithmetic examples, not measured review performance or a claim that all three inputs produce equally good answers.
| Input sent per review | Input cost | Output cost | Total for 1,000 reviews |
|---|---|---|---|
| 50,000 tokens: selected context | $0.150 | $0.075 | $225 |
| 250,000 tokens: broader subsystem | $0.750 | $0.075 | $825 |
| 750,000 tokens: large snapshot | $2.250 | $0.075 | $2,325 |
The calculation is input tokens ÷ 1,000,000 × input rate + output tokens ÷ 1,000,000 × output rate. The largest example is $2.325 per call. An agent that makes several model calls for one pull request must count every call, including retries and additional billed thinking tokens. Retrieval, CI execution, and engineering review time are separate costs.
For workflows that choose their own next steps, estimating one call is only the start. Our AI agent cost-control guide explains how to enforce a shared task budget across model calls, paid tools, retries, and parallel workers.
Prompt caching changes the repeated-call economics
Using the same published Sonnet 4.6 rates, a five-minute cache write costs $3.75 per million tokens and a cache read costs $0.30. With a reusable 700,000-token prefix, 50,000 new input tokens, and 5,000 output tokens, the first cache-writing call costs $2.85. A later cache-hit call costs $0.435. That assumes the prefix matches, the entry is still valid, and no other pricing modifiers apply.
Keep stable instructions and repository content before the changing task where the provider's caching interface supports it. Track cache writes, hits, and uncached tokens in usage data. Changes to the prefix or an expired cache can alter the bill; a cache hit also does not make the cached tokens disappear from the context window. Recheck rates for your model and platform when planning a deployment.
Measure latency even for background jobs
Long inputs can increase time to first token, while generated output adds its own delay. Measure cold and warm-cache requests at realistic concurrency. A nightly analysis still has a completion deadline, token-rate limits, and retry costs. A background job has a different latency budget from autocomplete; it does not have an unlimited one.
A Repeatable Workflow for Long-Context Code Analysis
- Define one engineering question. Specify the change, constraints, and expected deliverable: a dependency map, review findings, or migration steps. A request to "analyse the whole repo" has no clear completion test.
- Pin the source versions. Record the commit SHA and paths included in the bundle. For PRs, identify both base and head revisions; avoid silently mixing code from different states.
- Select and count the evidence. Include the relevant contracts, tests, and configuration alongside code. Label each file, list exclusions, and count the complete request against the selected model.
- Ask for references and uncertainty. Findings should point to files and symbols, explain the dependency, and distinguish observed facts from assumptions. Require an explicit list of missing information.
- Validate before expanding the change. Inspect the referenced code and run relevant type checks, tests, or static analysis. Use validated findings to choose a small patch, then evaluate that patch separately.
- Record the result and cost. Save the model ID, prompt version, source revision, input/output usage, cache behaviour, latency, and reviewer outcome so the workflow can be compared after changes.
A starting prompt for the payment-client example could look like this. The manifest identifies exactly which files are available; the model should not assume that omitted files have been checked.
Task: Plan the migration from synchronous to asynchronous payment calls.
Source: Use the repository revision and file manifest supplied below.
Return:
1. Entry points and callers affected, with file paths and symbols.
2. Changes needed in retries, error handling, webhooks, and tests.
3. A phased implementation plan with a validation step for each phase.
4. Missing files or runtime details needed to confirm the plan.
Distinguish observed behaviour from assumptions.
Do not treat a missing reference as proof that no caller exists.
Do not generate implementation patches in this analysis step.How to Decide Whether the Larger Window Is Worth It
Take a set of completed changes with known outcomes: a local fix, a cross-module change, an API-contract update, and a migration task. Keep separate examples for prompt tuning and final evaluation. Compare selected context, expanded retrieval, and a large snapshot on the same held-out tasks using the same model where possible.
| Measure | What it tells the team |
|---|---|
| Important dependencies found and missed | Whether more context improves coverage |
| Valid findings versus false positives | Whether the review creates useful work or noise |
| Correct file and symbol references | Whether an engineer can verify the answer |
| Patch correctness and regression tests | Whether any generated changes preserve required behaviour |
| Review minutes, latency, and total cost | Whether the workflow improves delivery economics |
Run more than one trial because model outputs can vary. For dependency tests, place relevant information in different parts of the bundle and include cases where the evidence is absent. The correct answer in an incomplete case may be a request for another file rather than a confident conclusion. Start in a non-blocking review role and measure the results before making the workflow a required step in CI.
The decision is task-specific. If broader context catches a consequential dependency and saves investigation time, the higher token bill may be justified. If it produces the same answer more slowly, the smaller request is the better default. Define acceptable quality and turnaround before looking at the comparison.
How UData Can Help Build the Workflow
UData's software development and automation services can support repository analysis, context assembly, API integration, CI checks, and evaluation tooling. A useful first scope is one workflow with an observable outcome: for example, a PR reviewer that produces verifiable findings or a migration planner that maps affected modules.
Bring representative tasks, the repository setup, current review steps, and your cost and latency targets. The deliverables can include a versioned context builder, a comparison against your current process, usage reporting, and an implementation estimate. If you need engineers working alongside your team, our dedicated developers page explains that engagement model.
Use the Million Tokens When the Task Earns Them
A 1M context window expands the evidence an AI coding workflow can consider at once. Its strongest use is a bounded question that crosses enough files or documents to benefit from that capacity. Keep retrieval for focused tasks, use larger bundles where relationships matter, and judge both by verified engineering outcomes. The goal is a better change or a better decision, not a larger prompt.
Sources and Calculation Notes
- Anthropic: context windows — model capacity, input/output accounting, and context management.
- Anthropic: token counting — estimating the size of a structured request for the selected model.
- Anthropic: prompt caching — the Sonnet 4.6 rates used here, cache matching, and usage reporting.
- Lost in the Middle (2023) — position sensitivity in the long-context tasks and models studied.
- RULER (2024) — evaluating retrieval, tracing, and aggregation at increasing context lengths.
The token budget and cost scenarios are illustrative calculations. They are not UData client results, measured speedups, or benchmark scores. Prices were checked for the September 24, 2026 revision; actual billing depends on model, platform, cache usage, output and thinking tokens, and any applicable pricing modifiers.
Frequently Asked Questions
It gives a supported model room for roughly one million tokens of context, which can include code, tests, documents, instructions, tool results, and generated output under the provider's accounting rules. It can help with cross-file analysis, but capacity alone does not guarantee that the model notices every dependency or produces correct changes.
Some selected repository snapshots fit; others do not. Tokens are not lines of code, and tests, documentation, tool definitions, conversation history, and output also need space. Count the actual request with the chosen model's tokenizer or token-counting endpoint rather than estimating from repository size alone.
No. Retrieval selects relevant evidence, while a larger context window provides more room to analyse it. Focused coding tasks often benefit from selected files and search. Broad migration tasks may benefit from a larger bundle. A hybrid workflow retrieves first and expands when additional dependencies are needed.
At the cited Sonnet 4.6 standard rates of $3 per million input tokens and $15 per million output tokens, 750,000 uncached input tokens plus 5,000 billed output tokens cost $2.325 for one call. Additional calls, thinking tokens beyond that output allowance, retries, tools, and platform pricing can change the total.
No. Cached tokens still count toward the context window. Caching can reduce repeated processing cost and latency when a reusable prefix matches a valid cache entry. Track cache writes, reads, and uncached tokens, and keep room for new messages, tool results, and output.
No. Context is the information available for the current generation. An application can save notes, summaries, or files and load them into later requests, but the model does not retain the full original repository just because it appeared in an earlier context. Summaries and compaction can also omit details that need to be retrieved again.