Context Window Economics: The Hidden Cost Structure of Large Language Model Applications

Context windows are usually sold as capability. In production they behave like a tariff schedule plus a retrieval problem. As of April 4, 2026, Anthropic's latest 1M-token Claude models price long prompts flat across the full window, OpenAI's GPT-5.4 exposes a 1.05M window but re-prices the entire session once input exceeds 272K tokens, and Google's Gemini 2.5 Pro doubles input price and raises output price once a request crosses 200K tokens. That means "window size" is not one number; it is a cost surface with cliffs. (Claude API Docs)

The second half of the story is quality. Public long-context evidence does not show a smooth "more context = better results" relationship. Lost in the Middle found that models tend to use information best at the beginning or end of a prompt and degrade when the relevant material is buried in the middle. RULER found large performance drops as context length increased, with only about half of tested models maintaining satisfactory performance at 32K despite claiming 32K+ contexts. NoLiMa then removed literal lexical cues and found a sharper failure mode: at 32K, 11 models fell below 50% of their strong short-context baselines, and even a top exception (GPT-4o) fell from 99.3% to 69.7%. Google's own long-context guide now explicitly warns that multi-needle retrieval accuracy varies widely with context and that longer queries generally increase latency. (ACL Anthology)

The practical consequence is simple: the engineering objective is not "fill the window." It is "pay only for tokens that still improve task success." Long context expands the maximum feasible working set. It does not eliminate ranking, retrieval, caching, summarization, state externalization, or careful prompt topology. Related entries: Context Engineering, Retrieval-Augmented Generation, Prompt Caching, Agent Memory, Long-Context Benchmarking.

1. Pricing snapshot: the relevant 2026 surfaces

I will compare standard paid-tier text-token rates, because that is the cleanest base layer for architectural analysis. Batch, flex, priority, and tool-specific charges matter operationally, but they do not change the core shape of the context economics.

Provider	Model	Documented context window	Input price	Cached/read price	Output price	Important rule
Anthropic	Claude Sonnet 4.6	1M	$3 / MTok	5m write $3.75, 1h write $6, read $0.30	$15 / MTok	Full 1M at standard pricing
Anthropic	Claude Opus 4.6	1M	$5 / MTok	5m write $6.25, 1h write $10, read $0.50	$25 / MTok	Full 1M at standard pricing
Anthropic	Claude Haiku 4.5	200K	$1 / MTok	5m write $1.25, 1h write $2, read $0.10	$5 / MTok	Smaller window, cheaper tier
OpenAI	GPT-5.4	1,050,000	$2.50 / MTok under 272K; $5.00 over 272K	$0.25 under 272K; $0.50 over 272K	$15.00 under 272K; $22.50 over 272K	Above 272K, input is 2x and output 1.5x for the full session
OpenAI	GPT-5.4-pro	1,050,000	$30 under 272K; $60 over 272K	—	$180 under 272K; $270 over 272K	Same long-context rule
Google	Gemini 2.5 Pro	1,048,576	$1.25 / MTok at ≤200K; $2.50 above 200K	$0.125 / MTok at ≤200K; $0.25 above 200K; plus $4.50 / MTok-hour storage for explicit caches	$10.00 / MTok at ≤200K; $15.00 above 200K	Price step at 200K
Google	Gemini 2.5 Flash	1,048,576	$0.30 / MTok	$0.03 / MTok; plus $1 / MTok-hour storage for explicit caches	$2.50 / MTok	1M window with a much cheaper slope
Google	Gemini 2.5 Flash-Lite	1,048,576	$0.10 / MTok	$0.01 / MTok; plus $1 / MTok-hour storage for explicit caches	$0.40 / MTok	Cheapest 1M-class option in the current standard table

Sources for the table: Anthropic model overview and pricing/prompt-caching docs; OpenAI GPT-5.4 model and pricing docs; Google Gemini model and pricing/caching docs. (Claude API Docs)

A few patterns matter more than the raw numbers.

First, output is expensive. GPT-5.4 short-context output is 6× its short-context input price; Claude Sonnet 4.6 output is 5× input; Gemini 2.5 Pro output is 8× input below 200K and 6× above. Systems that emit long patches, long reports, or verbose agent traces can become output-bound even when their input is huge. (OpenAI Developers)

Second, the cliff often matters more than the slope. On GPT-5.4, crossing 272K changes both fresh input pricing and cached-input pricing. On Gemini 2.5 Pro, crossing 200K changes input, cached-token, and output pricing. Anthropic's latest 1M Sonnet/Opus pricing is the notable exception: the incentive to prune there is mainly quality and latency, not a sudden price jump. (OpenAI Developers)

A small illustrative cliff table makes the point.

Model	Scenario A	Cost A	Scenario B	Cost B	Increase
GPT-5.4	271K input + 10K output	$0.83	273K input + 10K output	$1.59	+92%
Gemini 2.5 Pro	199K input + 10K output	$0.35	201K input + 10K output	$0.65	+87%
Claude Sonnet 4.6	199K input + 10K output	$0.75	201K input + 10K output	$0.75	~flat

These are simple arithmetic examples from the official standard rates above. The important architectural point is that a "prompt compressor" whose only job is to shave 2K tokens can be economically rational on OpenAI and Google well before it becomes technically necessary. (OpenAI Developers)

2. Context length and quality: capacity is not competence

The cleanest way to think about long context is this: capacity is about what can be presented; competence is about what can still be retrieved and used. Those are different functions.

Lost in the Middle established the basic positional pathology. Relevant information placed at the beginning or end of the context was used more reliably; relevant information placed in the middle degraded performance sharply, including on explicitly long-context models. That result matters because most naïve "stuff the corpus into the prompt" systems produce exactly the worst case: the user's real question arrives at the end, and the crucial evidence ends up somewhere in the middle. (ACL Anthology)

RULER pushed further. Vanilla "needle in a haystack" retrieval was too flattering, so the authors expanded the task family to include multiple needles, aggregation, and multi-hop tracing. Their result is blunt: near-perfect single-needle behavior does not imply robust long-context reasoning, and almost all tested models degraded as length increased. The economics implication is immediate: every extra token has a direct cost, but its value decays once retrieval and integration become brittle. (OpenReview)

NoLiMa is the most economically relevant result of the three because it attacks the common benchmark loophole. If the question and relevant passage share obvious wording, the model can partly "grep" the prompt with attention. When lexical overlap is minimized, performance falls much faster with length. That is exactly the regime many real products live in: code review comments that must connect distant design constraints, research synthesis where terminology differs across papers, and refactoring tasks where the right file is semantically but not lexically related to the request. In that regime, a larger prompt can absolutely cost more while helping less. (OpenReview)

Google's own long-context documentation effectively endorses the same operational lesson. It says multi-needle performance varies widely, advises placing the query at the end of a long prompt, says "if you don't need tokens, avoid passing them," and notes that longer queries generally increase time-to-first-token. That is not a marketing footnote. It is a vendor-level admission that 1M context does not make token discipline obsolete. (Google AI for Developers)

The right inference is not "long context is fake." The right inference is that long context is best used as a staging area, not a garbage dump. It is highly valuable when it lets you avoid brittle chunk boundaries, pull in whole code subtrees, or synthesize across full document sets. It is far less valuable when it becomes an excuse to skip ranking, salience filtering, or structured state management. Related entries: Information Retrieval for LLMs, Evaluation for Agentic Systems.

3. Prompt caching: usually the highest-ROI optimization after threshold avoidance

Across vendors, the basic caching advice converges:

Put stable, reusable content first.
Put variable user/task content last.
Keep prefixes identical when you want hits.

OpenAI says cache hits require exact prefix matches and recommends static content first and variable content at the end. Anthropic says to place static content—tools, system instructions, context, examples—at the beginning and mark the end of reusable content with cache_control. Google advises putting large/common content at the beginning and sending similar prefixes close together. (OpenAI Developers)

That convergence is not cosmetic. It means your prompt is no longer just an instruction artifact. It is also a cache topology.

Anthropic: explicit arithmetic, predictable break-even

Anthropic's pricing is the easiest to reason about. For prompt caching, 5-minute writes cost 1.25× base input, 1-hour writes cost 2×, and cache reads cost 0.1×. Anthropic's own docs say that means 5-minute caching pays off after one cache read, and 1-hour caching after two cache reads. The cache lifetime is 5 minutes by default and refreshes at no extra cost whenever used. (Claude API Docs)

For a repeated prefix of size T MTok with base input price P, used across N total calls:

5-minute cache: C = 1.25PT + 0.1P(N-1)T
1-hour cache: C = 2PT + 0.1P(N-1)T

That is unusually developer-friendly. The write premium is explicit, the read discount is explicit, and the break-even is not guesswork. If your workload is "large shared prefix, multiple short follow-ups in one sitting," Anthropic's cache math is very hard to beat operationally. (Claude API Docs)

The hidden constraint is structure. Anthropic's cache entries are cumulative prefix hashes; changing anything before the breakpoint changes the hash and kills reuse. Anthropic also documents a common mistake: putting cache_control on a per-request block that changes every call, which turns caching into an endless sequence of write misses. (Claude API Docs)

OpenAI: no write fee, so the problem is operational hit rate

OpenAI's prompt caching is architecturally different. The docs say caching works automatically on recent models, can reduce input cost by up to 90%, and has no additional fee for writing to cache. GPT-5.4's pricing table shows cached input at one-tenth the normal input rate both below and above the 272K cliff. OpenAI also says in-memory cache retention is typically 5–10 minutes of inactivity (up to one hour), and GPT-5.4 supports extended 24-hour retention with the same prompt-cache pricing. (OpenAI Developers)

That changes the ROI model completely. There is no explicit write premium to amortize. A hit is upside immediately. So the optimization problem is not "is caching worth it?" but "how do I create stable prefixes and route traffic so that I actually get hits?" OpenAI documents three practical constraints: exact prefix matching, prompt_cache_key for routing affinity, and reduced effectiveness once identical-prefix traffic exceeds roughly 15 requests per minute on one prefix/key combination and spills across machines. (OpenAI Developers)

For a repeated prefix T on GPT-5.4, the simplified economics are:

first uncached use: PT
later cached use: PcT, where Pc is 10% of P

So any nonzero hit rate helps. The hidden cost is operational: if your app mutates the prefix every turn, routes requests too diffusely, or spaces follow-ups beyond retention, the beautiful nominal cache price is irrelevant. (OpenAI Developers)

Google: implicit caching is elegant; explicit caching is storage-sensitive

Google offers both implicit and explicit caching. The official docs say implicit caching is enabled by default on Gemini 2.5+ and gives a 90% discount on cached tokens when hits occur, but it does not guarantee savings. Explicit caching guarantees the discount, but you pay storage for the cache lifetime. Google's Vertex docs say cache creation is billed at the standard input price; the Gemini pricing page gives the discounted cached-token price and the per-token-hour storage price. (Google Cloud Documentation)

That yields a very different break-even equation. For repeated prefix size T, standard input price P, cached-token price Pc, storage price S, and cache lifetime H hours:

C_explicit = PT + NPcT + SHT

Break-even against naïvely resending the prefix for N requests occurs when:

N > (P + SH) / (P - Pc)

For Gemini 2.5 Pro (P = $2.50, Pc = $0.25, S = $4.50 / MTok-hour), that means:

about 2 uses for a 10-minute cache,
about 4 uses for a 1-hour cache,
about 50 uses for a 24-hour cache.

That is the most important Google-specific economic fact. Explicit caching is excellent for bursty, dense reuse; it is mediocre to bad for sparse reuse over long TTLs unless the cached corpus is queried many times. If you can tolerate nondeterminism, implicit caching is often the nicer economic default because it avoids storage charges. (Google Cloud Documentation)

4. Compaction strategies and their information-loss profiles

"Compaction" is not one thing. At least five distinct policies get called compaction in practice, and they fail differently.

Hard trimming / last-N turns This is the cheapest and most reproducible policy. OpenAI's session-memory guidance says trimming is deterministic, adds no latency, and preserves recent work verbatim, but it forgets older constraints abruptly and can produce visible agent "amnesia." Loss profile: low distortion, high omission risk. (OpenAI Developers)
Generated summaries OpenAI's guidance is candid: summaries preserve long-range continuity and can replace hundreds of turns, but they introduce summarization loss, bias, latency spikes, and "context poisoning" if a bad fact enters the summary. Loss profile: medium omission, medium-to-high distortion risk. (OpenAI Developers)
Selective context editing / payload clearing Anthropic's context editing clears old tool results or thinking blocks when thresholds are reached. This is economically attractive for tool-heavy agents because old file dumps and search results are often dead weight after the model has processed them. But Anthropic also says clearing invalidates cached prefixes and should therefore remove enough material to justify the cache reset. Loss profile: low-to-medium omission risk if your deleted payloads were truly already "digested". (Claude Platform)
Provider-managed opaque compaction OpenAI's compaction returns encrypted opaque items that carry forward prior state and reasoning while reducing token footprint. Anthropic recommends server-side compaction over SDK-based summarization when you want automatic context management. This category is operationally useful, but it is not auditable in the same way as a visible summary, and OpenAI explicitly says the returned item is not intended to be human-interpretable. Public evidence on the end-task quality of vendor compaction is still thin relative to the evidence on long-context retrieval failure modes. Treat these systems as practical infrastructure, not as proved lossless compression. Loss profile: lower manual burden, uncertain latent omission, poor inspectability. (OpenAI Developers)
Externalized state artifacts Anthropic's own best-practices guidance for multi-window coding suggests structured files like tests.json, progress notes, and git logs, and even says that in some cases starting fresh from a brand-new context window can beat compaction because the model can rediscover state from the filesystem. This is not "compaction" in the narrow API sense, but architecturally it is the most reliable memory pattern for long autonomous coding. Loss profile: lowest semantic distortion, but higher orchestration complexity. (Claude API Docs)

A practical comparison:

Strategy	What you save	What you lose	Best fit
Trim last-N	Cost and latency with almost no extra machinery	Long-range commitments vanish abruptly	Short workflows, local context, ops automations
Summary	Big compression and continuity	Summary drift, poisoned state, audit burden	Long threads, analyst/research assistants
Context editing	Removes dead tool payloads efficiently	Anything you deleted but later needed	Tool-heavy agents
Opaque vendor compaction	Lowest manual overhead	Inspectability and explicit control	Long-running agent sessions
External state artifacts	Durable, auditable memory outside transcript	More harness work	Coding, research, multi-window agents

The table's loss labels are a synthesis of OpenAI's session-memory/compaction docs and Anthropic's context-editing/compaction guidance. (OpenAI Developers)

The deepest design point is this: compaction is a policy choice about what kind of forgetting you are willing to buy. The right question is not "should I compact?" It is "do I prefer omission, distortion, or orchestration complexity?"

5. Concrete workflow economics

All examples below are text-token calculations at standard rates, using current official prices. They ignore batch discounts, ancillary tool charges, and multimodal tokenization.

Workflow A: code review

Assume a one-shot PR review with:

120K input tokens (diffs, touched files, test output, house style guide)
8K output tokens (review memo + prioritized comments)

Using the common "strong reasoning/coding default" models:

Model	Cost
Claude Sonnet 4.6	$0.48
GPT-5.4 (under 272K tier)	$0.42
Gemini 2.5 Pro (under 200K tier)	$0.23

Computed from official prices. (Claude API Docs)

At this size, the dominant decision is not caching. It is model choice plus threshold awareness. You are safely below OpenAI's 272K cliff and Google's 200K cliff, so this is the regime where direct review of the full packet is usually rational. If the same diff will be revisited multiple times in the same session, caching becomes attractive; if not, cache complexity is often unnecessary overhead. The lower-cost tiers are dramatically cheaper on pure token math—Haiku 4.5 at $0.16, GPT-5.4-mini at $0.126, Gemini 2.5 Flash at $0.056—but those are not capability-equivalent substitutes for deep review on hard codebases. (Claude API Docs)

Workflow B: research synthesis over a 600K-token corpus

Assume:

fixed corpus: 600K tokens
initial synthesis prompt: +10K input, 15K output
4 follow-up questions: each +5K input, 3K output

This is the canonical "upload many documents, then interrogate them" workload.

No caching

Model	Total cost
Claude Sonnet 4.6	$9.50
GPT-5.4 (long-context tier)	$15.76
Gemini 2.5 Pro (over 200K tier)	$7.98

With caching

Model	Cache mode	Total cost	Savings vs no cache
Claude Sonnet 4.6	1-hour cache	$4.82	49%
Claude Sonnet 4.6	5-minute cache	$3.47	64%
GPT-5.4	automatic/retained cache hits	$4.96	69%
Gemini 2.5 Pro	explicit cache, 10-minute lifetime	$3.18	60%
Gemini 2.5 Pro	explicit cache, 1-hour lifetime	$5.43	32%

Computed from the official cache/input/output prices and Google's documented explicit-cache storage model. (Claude API Docs)

This table exposes the real vendor differences better than any marketing page.

For Anthropic, the economics are clean and predictable: a 1-hour write premium still halves cost over five uses, and a 5-minute cache is even better if the session is dense enough. Anthropic's documentation is unusually honest here; the break-even is explicit and low. (Claude API Docs)

For OpenAI, GPT-5.4 looks expensive in the uncached version because the fixed 600K corpus pushes the session into the long-context tariff. But once cache hits are retained, the picture changes sharply because cached input is one-tenth the uncached input rate and there is no write fee. In this workload, OpenAI's nominal long-context penalty is largely redeemed by caching. That is a recurring theme: on GPT-5.4, repeated corpus interrogation is economically fine; repeated uncached corpus interrogation is not. (OpenAI Developers)

Google is the most TTL-sensitive. A 10-minute explicit cache is excellent here; a 1-hour explicit cache is merely decent because storage eats the margin. If you expect many clustered follow-ups, Google explicit caching is strong. If the user may return later, implicit caching or a different architecture may be preferable. Google's own long-context guide effectively points in this direction when it frames context caching as the primary long-context optimization and ties cost reduction to repeated reuse. (Google AI for Developers)

Workflow C: multi-file refactoring over six turns

Assume a medium-large coding session:

static repo/spec context: 370K tokens
new per-turn context: 15K tokens
output per turn: 10K tokens
total turns: 6

Now compare three architectures:

Naïve full resend: send 385K every turn.
Cached static prefix: cache the 370K repo/spec, send only deltas each turn.
Retrieved/compacted working set: keep each turn to ~65K total input (e.g. 60K targeted files + 5K structured state).

Model	Naïve full resend	Cached static prefix	Retrieved/compacted 65K working set
Claude Sonnet 4.6	$7.83	$3.95 (1h cache)	$2.07
GPT-5.4	$12.90	$4.58	$1.88
Gemini 2.5 Pro	$6.68	$4.27 (1h explicit cache)	$1.09

Computed from current official pricing. (Claude API Docs)

This is the core economic lesson of 1M-class coding agents: the best use of a giant window is usually to establish a plan, not to drag the whole repo through every iteration.

On GPT-5.4, the naïve pattern is punished twice: every turn is over 272K, so the whole session stays on the expensive tariff, and you keep paying high uncached input rates. Merely caching the static repo context cuts the session cost by about 65%. Keeping each turn under the short-context tier by narrowing the working set cuts cost by about 85%. (OpenAI Developers)

On Sonnet 4.6, there is no 272K/200K style tariff cliff, but targeted context still wins decisively. Why? Because even without a cliff, irrelevant input still costs money and still competes for attention. Anthropic's own best-practices guidance for multi-window coding reinforces this: structure persistent state, keep tests and progress artifacts, and sometimes start fresh from filesystem state rather than relying on compaction. (Claude API Docs)

On Gemini 2.5 Pro, a 1-hour explicit cache helps, but it still loses badly to a compact working set because storage turns the static-prefix cache into a recurring liability. This is the cleanest example of why a 1M window does not replace Retrieval-Augmented Generation or structured state. It changes the first-pass architecture; it does not eliminate the need for iterative narrowing. (Google Cloud Documentation)

6. What 1M+ windows actually change

They simplify the first request more than the tenth

Google's long-context guide explicitly says "chat with your data" historically required more complex RAG pipelines and that cached uploads can now make a more direct approach viable. OpenAI says GPT-5.4's 1M window makes it easier to analyze entire codebases, long document collections, or extended agent trajectories in one request. Those claims are real. The first request can now be much less brittle: fewer chunk-boundary errors, less premature summarization, less need to guess which files or papers matter before the model sees them. (Google AI for Developers)

But the tenth request is a different economic object. By then you usually have: a stable policy prefix, a static corpus, a mutable local working set, some durable artifacts, and a narrow current goal. That is where caching, selective retrieval, and externalized state dominate. The optimal architecture becomes layered:

static reusable prefix: instructions, schemas, corpus, repo snapshot
mutable working set: current files, current evidence, current error traces
durable state artifacts: tests, progress notes, git history, extracted facts
compressed conversational state: summaries, compaction items, trimmed transcript

This layered design is not a theoretical preference. It is what the vendor docs converge toward when read together. Anthropic recommends structured files and multi-window state tracking; OpenAI recommends compaction, prompt caching, and deferred tool loading; Google recommends caching as the primary long-context optimization and still tells you not to send tokens you do not need. (Claude API Docs)

They do not eliminate retrieval; they change its granularity

The 32K-era default was "retrieve before every meaningful call." In the 1M era, the better pattern is often "retrieve coarsely once, then refine aggressively." Whole-repo or whole-dossier ingestion is useful for initial planning. Subsequent steps should usually be narrower, because public evidence says the model's effective use of buried or semantically distant information degrades with length. Large windows reduce the need for premature retrieval, not the need for retrieval itself. (ACL Anthology)

Tool surfaces become part of context economics

OpenAI's docs note that tools can be cached and that GPT-5.4 tool_search defers loading large tool surfaces, reducing token usage, improving latency, and preserving cache performance. Anthropic's prompt cache hashes the prefix over tools, system, then messages, which means giant tool schemas are literally part of your cache key. In large agent systems, "tool design" and "prompt design" collapse into the same budget problem. (OpenAI Developers)

External artifacts matter more than transcripts

Anthropic is unusually clear here: for multi-context coding, keep structured state, use git, and consider starting fresh from filesystem state rather than always compacting the transcript. That advice is broader than Claude. It reflects a general truth: files, tests, issue lists, and extracted facts are auditable memory. Transcripts are expensive memory. Compaction can preserve continuity, but durable artifacts preserve accountability. (Claude API Docs)

Latency remains a first-class constraint

Google says longer queries generally increase time-to-first-token. OpenAI's tool-search docs sell deferred tool loading partly as a latency optimization. In practice, the best architecture is rarely the one that minimizes token count alone; it is the one that minimizes time-to-correct-answer. But once you factor in quality degradation from oversized prompts, latency and accuracy often point in the same direction: a narrower working set. (Google AI for Developers)

7. Design rules that survive vendor churn

Optimize threshold avoidance before anything fancy. If you are on GPT-5.4 or Gemini 2.5 Pro, staying just under 272K or 200K can beat much more elaborate downstream optimizations. (OpenAI Developers)
Model the prompt as static prefix + dynamic suffix. If your prompt is not structurally decomposed that way, you are forfeiting most of the available cache upside across all three vendors. (OpenAI Developers)
Use explicit Google caches only when reuse density justifies storage. Dense, bursty sessions are excellent. Sparse, low-frequency revisit patterns are not. (Google Cloud Documentation)
Prefer targeted working sets for iterative coding and research. The evidence on long-context quality is much stronger on retrieval failure modes than on magical "whole window reasoning." Large windows are a staging advantage, not a license to stop selecting. (ACL Anthology)
Treat summaries and compaction outputs as model outputs, not facts. Evaluate them, log them, and decide whether you prefer omission or distortion risk. OpenAI's own guidance on summary drift and Anthropic's guidance on less-ideal compaction use cases both point to the same caution. (OpenAI Developers)
For 1M-class agents, externalize durable state. Put tests, progress markers, decisions, extracted facts, and repo state somewhere inspectable. Then use context windows for active reasoning, not as a permanent warehouse. (Claude API Docs)

Bottom line

The hidden cost structure of long-context applications is not "token price times token count." It is:

effective cost = piecewise token pricing + cache miss rate + storage/TTL choices + latency + quality decay from irrelevant context

That last term is the one teams under-model. A 1M window increases what is possible to send. It does not guarantee that sending it is rational. In many real systems, the cheapest architecture is not the smallest prompt, and the smartest architecture is not the largest prompt. The winning design is usually the one that uses a giant window selectively: broad enough to avoid brittle preprocessing, narrow enough to stay on the useful side of both the billing curve and the attention curve. (Claude API Docs)

See also: Context Engineering, Prompt Caching, Retrieval-Augmented Generation, Agent Memory, Long-Context Benchmarking, Tool Calling Economics, Latency Budgets, Evaluation for Agentic Systems.

Primary sources referenced

Anthropic Claude models overview and pricing docs for current model windows, input/output prices, long-context pricing, and prompt-caching multipliers. (Claude API Docs)
OpenAI GPT-5.4 model page, pricing docs, prompt-caching guide, and compaction guide. (OpenAI Developers)
Google Gemini pricing, model docs, long-context guide, and context-caching docs. (Google AI for Developers)
Liu et al., Lost in the Middle: How Language Models Use Long Contexts (TACL 2024). (ACL Anthology)
Hsieh et al., RULER: What's the Real Context Size of Your Long-Context Language Models? (COLM 2024). (OpenReview)
Modarressi et al., NoLiMa: Long-Context Evaluation Beyond Literal Matching (ICML 2025). (OpenReview)