How to Fix Context Window Exceeded Errors (ChatGPT, Claude, Cursor)

Every heavy user of AI chatbots eventually runs into the same wall. You paste a long document, or your chat has been going for an hour, and instead of an answer you get a red error: “This model’s maximum context length is … tokens,” or “prompt is too long,” or in Cursor, “Your conversation is too long.”

It feels like the model got dumber. It didn’t. You hit the single most fundamental limit in every large language model — the context window — and the good news is that it’s completely fixable once you understand what’s actually happening.

This is the complete guide. We’ll cover what a context window is, what tokens are (with real examples), why the error fires, exactly how ChatGPT, Claude, Gemini and Cursor each behave, and then the full toolkit of fixes — from a 30-second trim to production-grade retrieval. Everything here is grounded in official documentation, linked at the end.

What a context window actually is

A large language model has no memory of its own. Each time you send a request, the model reads a block of text, predicts a response, and forgets everything. The context window is the maximum size of that block — the total amount of text the model can “see” at once for a single request, measured in tokens.

Think of it as the model’s desk. Everything it needs to work on has to fit on the desk at the same time: the instructions, the conversation so far, any files you attached, and — crucially — enough clear space to write the answer. When the pile is bigger than the desk, something falls off. That “something” is your error.

┌──────────────── CONTEXT WINDOW (e.g. 128,000 tokens) ────────────────┐
│ system  │  tool/function │  conversation   │  your new  │  space for │
│ prompt  │  definitions   │  history        │  message   │  the reply │
└──────────────────────────────────────────────────────────────────────┘
     ▲ everything the model sees at once — and the reply needs room too

Two things trip people up here. First, the window holds both what you send and what the model generates — if you fill it to the brim with input, there’s no room left to answer. Second, the window is per-request working memory, not long-term memory. It resets every call. The illusion of a chatbot “remembering” your conversation is just the app re-sending the entire history back to the model on every single turn. That’s why a long chat slowly creeps toward the limit even when each individual message is short.

Tokens, explained (with examples)

Models don’t read words or characters — they read tokens. Tokenization is the process of chopping text into these sub-word pieces before the model ever sees it. A token can be a whole word, part of a word, a single character, a space, or a punctuation mark.

Here are the rules of thumb OpenAI publishes for English text:

• 1 token ≈ 4 characters
• 1 token ≈ 0.75 words
• 100 tokens ≈ 75 words

So a 1,000-word email is roughly 1,300 tokens. A 20-page PDF is often 10,000–15,000 tokens. A long codebase file can be several thousand.

A few concrete examples of how text splits:

• cat → 1 token
• unbelievable → often 3–4 tokens (un, bel, iev, able)
• tokenization → 2–3 tokens
• A space or newline → usually its own token
• 2026-07-13 → several tokens (digits and dashes split up)

This is why code and non-English text cost more tokens per character than plain English prose. Indentation, camelCase and snake_case names, brackets, and symbols each burn tokens, and scripts like Chinese or Arabic tokenize less efficiently than Latin text. If you work in code, budget more generously.

One more subtlety that bites people: different models tokenize differently. A key 2026 change — the newer Claude models (Opus 4.7 and later, Fable 5, Sonnet 5) use an updated tokenizer that produces roughly 30% more tokens for the same text than earlier models. A prompt that comfortably fit last month can suddenly exceed the limit after a model upgrade, with no change to your text. Always count against the model you’re actually calling.

For the mental model behind all of this, our explainer on how large language models actually work goes a level deeper.

Token calculators: count before you send

Guessing token counts is a losing game. Measure. These are the official tools:

Tool	Provider	Best for
OpenAI Tokenizer (web)	OpenAI	Quick visual check for GPT models
tiktoken (library)	OpenAI	Counting in code for GPT models
count_tokens API	Anthropic	Exact counts for Claude (free, rate-limited)
countTokens API	Google	Exact counts for Gemini
Tokenizer Playground	Hugging Face	Comparing tokenizers in the browser

Counting with OpenAI’s tiktoken (GPT-4o uses the o200k_base encoding; GPT-4 and 3.5 use cl100k_base):

import tiktoken

enc = tiktoken.encoding_for_model("gpt-4o")
text = "How many tokens is this sentence, really?"
print(len(enc.encode(text)))   # -> exact token count

Counting for Claude — note you must not reuse tiktoken here, because Claude’s tokenizer is different:

import anthropic

client = anthropic.Anthropic()
resp = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": "How many tokens is this?"}],
)
print(resp.input_tokens)   # counting is free and doesn't use your quota

Counting for Gemini:

from google import genai

client = genai.Client()
resp = client.models.count_tokens(
    model="gemini-2.5-pro",
    contents="How many tokens is this?",
)
print(resp.total_tokens)

Google’s guidance mirrors OpenAI’s — about 4 characters per token, and 100 tokens ≈ 60–80 English words. Gemini also charges tokens for non-text input: an image up to 384px is 258 tokens, video is ~263 tokens per second, and audio is ~32 tokens per second. Multimodal prompts fill the window faster than you’d expect.

What the error looks like in each tool

The wording differs by provider, but they all mean the same thing. Recognizing yours tells you which fix aisle to walk down.

OpenAI / ChatGPT (API), HTTP 400, code: context_length_exceeded:

This model's maximum context length is 128000 tokens. However, you
requested 130512 tokens (129512 in the messages, 1000 in the
completion). Please reduce the length of the messages or completion.

On the GPT-5 family you may instead see a configured-input cap:

Input tokens exceed the configured limit of 272,000 tokens

Anthropic / Claude (API), HTTP 400, invalid_request_error:

prompt is too long

On Claude 4.5-and-newer models there’s a subtler variant: if your input fits but input + max_tokens would overflow, the request is accepted and generation stops with stop_reason: "model_context_window_exceeded" instead of erroring. A separate 413 request_too_large fires if the raw request exceeds the 32 MB Messages API cap.

Google / Gemini (API), HTTP 400:

The input token count (1050000) exceeds the maximum number of
tokens allowed (1048576).

Cursor (UI):

Your conversation is too long. Please try creating a new
conversation or shortening your messages.

…or the shorter “Your message is too long.” When Cursor is running a Claude model, the underlying Anthropic error — “Prompt is too long: the number of tokens exceeds the maximum allowed limit” — sometimes surfaces through the editor.

Every possible cause of the error

The message is always “too many tokens,” but the source of those tokens varies. Here’s the full list — check them roughly in order of how often they’re the culprit:

1. A long conversation. The whole history is re-sent every turn. This is the number-one cause of “why am I hitting this on a short message?” The message is short; the transcript behind it isn’t.
2. A large pasted document or file. A single big PDF, spreadsheet, log file or transcript can blow the window on its own.
3. No room reserved for the reply. Input plus max_tokens (the requested completion length) must both fit. Ask for a 4,000-token answer and you’ve spent 4,000 tokens of the window before the model writes a word.
4. A bloated system prompt. Long instructions, style guides, and few-shot examples are sent on every request and quietly eat the budget.
5. Tool / function definitions. In agentic setups, JSON schemas for tools count as input tokens each turn.
6. Retrieved or injected context. RAG chunks, ChatGPT “memory,” connected files, and browsing results all land in the window.
7. The app tier is smaller than the model. The ChatGPT app caps context by plan (see below) — often far below the model’s raw API maximum.
8. A tokenizer change after a model upgrade. As noted, newer Claude models produce ~30% more tokens for identical text.
9. Multimodal inputs. Images, audio and video consume large, easy-to-underestimate token counts.
10. Code and non-English text. Higher token-per-character ratios push you over sooner than word counts suggest.

How ChatGPT, Claude, Gemini and Cursor handle context

Windows change often, so treat these as a current snapshot (mid-2026) and confirm against the official docs linked below. Note the important distinction between a model’s API window and what an app actually allows.

OpenAI / ChatGPT

Model (API)	Context window	Max output
GPT-4o	128,000	16,384
GPT-4.1	~1,000,000	32,768
GPT-4 Turbo	128,000	4,096
o3	200,000	100,000
GPT-5.5 / GPT-5.6	~1,000,000	128,000

The GPT-5 family enforces a configured input limit around 272,000 tokens even where the total window is larger — exceed it and you get the “configured limit” error above.

The ChatGPT app is stricter than the API. Reported per-tier windows: Free ≈ 16K, Plus / Team = 32K, Pro / Enterprise = 128K. The app also reserves part of that for the system prompt, tools and memory, so your usable input is smaller than the headline number. (See our breakdown of the GPT-5.6 and ChatGPT Work release for how the newer models and modes fit together.)

Anthropic / Claude

Model	Context window	Max output
Claude Opus 4.8	1,000,000	128,000
Claude Sonnet 5	1,000,000	128,000
Claude Haiku 4.5	200,000	64,000

The 1M window is now generally available on the flagship Claude models (the old context-1m beta header that gated Sonnet 4/4.5’s long context is no longer required). Remember the tokenizer caveat: the same text counts ~30% higher on these newer models. Prompt caching can cut the cost of a big repeated prefix, but cached tokens still occupy the window — caching changes what you pay, not whether it fits.

Google / Gemini

Model	Context window	Max output
Gemini 2.5 Pro	~1,048,576 (1M)	65,536
Gemini 2.5 Flash	~1,048,576 (1M)	65,536
Gemini 1.5 Pro	~2,097,152 (2M)	8,192
Gemini 1.5 Flash	~1,048,576 (1M)	8,192

Gemini has the largest windows in the mainstream lineup — up to 2M tokens on 1.5 Pro — which is why it’s a common choice for whole-book or whole-repo analysis. Watch the modest output limits, though.

Cursor (and coding assistants)

Cursor doesn’t publish a fixed per-model number because it manages context for you, and the behaviour is worth understanding because it’s how good coding agents avoid this error entirely:

• Codebase indexing. Cursor splits your repo into meaningful chunks (functions, classes, blocks), turns each into a vector embedding, and stores them in a vector database. Your query is embedded and matched against that store — classic retrieval — so only relevant code enters the prompt instead of the whole project.
• @-mentions. @file, @folder, @Docs, @Terminals, @Past Chats and @Git let you hand the model exactly the context that matters. Cursor’s own advice: use @ when you know which files are relevant; skip it and let the agent search when you don’t.
• Auto-condensing and auto-summarize. When files are too big, Cursor condenses them to signatures and structure. When a conversation fills the window, it automatically summarizes the older turns to make room for the reply.
• Max Mode. Extends the context window to the maximum the underlying model supports, for the rare task that genuinely needs it.

GitHub Copilot’s CLI works the same way, auto-compacting the conversation into a structured summary once it reaches about 80% of the window and leaving a ~20% buffer. The pattern across every serious coding tool is identical: retrieve and summarize instead of stuffing.

The 60-second triage flowchart

Before you reach for heavy machinery, run this decision tree. It resolves the large majority of cases in under a minute:

START ──► "Context window exceeded"
             │
             ▼
   Is it ONE giant input (a file / doc / paste)?
             │
      ┌──────┴───────┐
     YES             NO ─► it's a long CONVERSATION
      │                       │
      ▼                       ▼
 Do you need ALL of it   Start a new chat, or delete old turns.
 in a single answer?     Still failing? Summarize the earlier
      │                  history (summary-buffer memory).
   ┌──┴───┐
  NO      YES
  │        │
  ▼        ▼
 RAG:     Can a bigger-context model hold it?
 retrieve  (GPT-4.1 1M · Claude 1M · Gemini 1–2M)
 only the   │
 relevant ┌─┴──┐
 chunks. YES   NO
         │     │
         ▼     ▼
      Switch  Chunk it, map-reduce
      model.  summarize, THEN answer.

Step-by-step fixes (fastest first)

1. Start a fresh conversation

If the error is from a long chat, this is the instant fix. A new conversation resets the history to zero. Copy forward only the handful of facts the next step actually needs — not the whole transcript.

2. Reserve room for the reply

Set max_tokens deliberately. If your input is 120K tokens on a 128K model and you ask for 16K of output, you overflow. Lower the requested completion length, or move to a model with headroom.

3. Trim the obvious fat

Delete pasted content you no longer need, drop redundant few-shot examples, and cut boilerplate from the system prompt. You’ll often recover thousands of tokens in seconds.

4. Switch to a larger-context model

The blunt-but-effective option: GPT-4.1, Claude Opus 4.8 and Gemini 2.5 Pro all offer ~1M tokens; Gemini 1.5 Pro reaches ~2M. Use this when the content genuinely must be considered together (a long legal contract, a full transcript). But read the warning in the best practices section first — bigger isn’t automatically better.

5. Then reach for the real tools

When trimming and swapping models aren’t enough, the durable fixes are: prompt optimization, chunking, summarization, RAG, and memory management. The rest of the guide covers each.

Prompt optimization: send less, keep the meaning

The cheapest token is the one you never send. Before any advanced technique, tighten the prompt itself:

• Cut filler instructions. “Please, if you would be so kind, kindly ensure that you carefully…” → “Do X.” Politeness is free to the model but costs you tokens.
• Reference, don’t paste. If the model already has a file via retrieval or an attachment, don’t paste it again inline.
• Prune few-shot examples. Three sharp examples usually beat ten mediocre ones — and cost a third of the tokens.
• Move stable instructions to the system prompt once, rather than repeating them each turn (and use prompt caching if your provider supports it, to cut the cost of that repeated prefix).
• Ask for concise output. “Answer in 3 bullet points” reserves less of the window for the completion.

Our prompt engineering guide for beginners covers the structure side of this in depth.

Chunking: split input the model can’t swallow whole

When a document is simply too big, chunking breaks it into pieces small enough to process, ideally along natural boundaries (paragraphs, sections, functions) so meaning stays intact.

A simple word-based splitter with overlap:

def chunk_text(text, chunk_size=512, overlap=64):
    words = text.split()
    step = chunk_size - overlap
    return [
        " ".join(words[i:i + chunk_size])
        for i in range(0, len(words), step)
    ]

The overlap matters: it repeats a little text between neighbouring chunks so an idea that straddles a boundary isn’t sliced in half. A widely used baseline is ~512 tokens per chunk with 50–100 tokens (10–20%) of overlap. Use smaller chunks (128–256) for precise fact lookup, larger ones (up to ~1024) when answers need more surrounding context.

In practice, use a battle-tested splitter that counts tokens rather than words. LangChain’s RecursiveCharacterTextSplitter tries paragraph breaks first, then sentences, then words:

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=64,
)
chunks = splitter.split_text(long_document)

Pinecone’s rule of thumb is the one to remember: if a chunk makes sense to a human on its own, it’ll make sense to the model too. LlamaIndex’s SentenceSplitter and semantic splitters (which cut where the topic shifts) are good next steps when fixed sizes feel too blunt.

Summarization: compress before you ask

If you need the gist of something huge — not every detail — summarize it down to a size that fits, then work from the summary. Three standard patterns from the LangChain playbook:

• Stuff. Put the whole document in one prompt and ask for a summary. Simplest, but only works if it already fits — which is exactly the situation you don’t have.
• Map-reduce. Summarize each chunk independently (“map”), then summarize the summaries (“reduce”). Scales to any length and parallelizes well. Best when each section stands alone.
• Refine. Walk through chunks in order, updating a running summary as you go. Slower and sequential, but better for narratives where later sections depend on earlier ones.

Map-reduce in a nutshell:

# MAP: summarize each chunk on its own
partials = [llm(f"Summarize this section:\n{c}") for c in chunks]

# REDUCE: summarize the summaries into one
final = llm("Combine these into one summary:\n" + "\n".join(partials))

This is how tools summarize 300-page documents with a 128K model: they never load all 300 pages at once.

RAG: the real fix for “the model can’t fit all my data”

If your actual goal is “let the AI answer questions over a big pile of documents,” the answer is almost never “find a bigger window.” It’s Retrieval-Augmented Generation.

The idea: don’t put your knowledge base in the prompt. Store it in a vector database, and at question time fetch only the few chunks relevant to this question. The prompt stays tiny no matter how big your corpus grows.

 Your docs ─► split into chunks ─► embed ─► vector DB
                                              │
 Question ─► embed ─► similarity search ──────┘
                            │
                            ▼
                 top-k relevant chunks
                            │
                            ▼
     [chunks + question] ─► LLM ─► grounded answer

A minimal end-to-end sketch:

# --- Index once ---
chunks = splitter.split_text(document)
store.add(embeddings=embed(chunks), texts=chunks)

# --- Per query ---
hits = store.search(embed(query), k=5)
context = "\n\n".join(hits)
answer = llm(
    f"Answer using ONLY this context:\n{context}\n\nQuestion: {query}"
)

RAG doesn’t just dodge the context error — it’s cheaper (you send five chunks, not a whole wiki), faster, and it reduces hallucinations because the model answers from real, retrieved text. This is exactly what Cursor does with your codebase. For the full walkthrough, see RAG explained, and note that RAG beats fine-tuning for keeping knowledge fresh — fine-tuning changes behaviour, not the window.

Memory management for long conversations

Chatbots overflow because history grows without bound. Managing that history is its own discipline. The three classic strategies (LangChain’s names, but the ideas are universal):

• Sliding-window / buffer memory. Keep only the last K turns; drop the oldest. Simple, predictable, cheap. The cost: the model forgets the start of the conversation.
• Summary memory. Replace old turns with a running summary. Preserves the gist of a long chat in a fraction of the tokens.
• Summary-buffer (hybrid). Keep recent turns verbatim and a summary of everything older. The best of both — recent detail plus long-term gist — and the pattern most production assistants use.

A sliding window is a few lines of code:

MAX_TURNS = 10
history.append({"role": "user", "content": user_msg})

# Always keep the system prompt; keep only the last N turns after it.
messages = [system_msg] + history[-MAX_TURNS:]

For a summary-buffer, when history crosses a token threshold, summarize the oldest half into a single system note and keep the recent half intact. This is precisely what Cursor and Copilot do automatically when they “condense” or “compact” a long session.

Context engineering: the discipline behind all of this

Zoom out and every fix above is one move in a bigger game the field now calls context engineering — deciding what information occupies the model’s limited window at each step so it has exactly what it needs and nothing it doesn’t. Prompt engineering is how you ask; context engineering is what you put on the desk.

The core principles:

• Relevance over volume. More context is not better context. The right 2,000 tokens beat the wrong 200,000 — and models literally perform worse when key facts are buried in the middle of a huge prompt (the “lost in the middle” effect).
• Budget the window. Treat tokens like a spending limit. Allocate deliberately across system prompt, tools, retrieved context, history and reply.
• Retrieve, don’t stuff. Pull information in on demand (RAG, tool calls, MCP) rather than pre-loading everything.
• Compress the past. Summarize history and long documents so the window holds meaning, not raw text.
• Isolate with sub-agents. Hand a big sub-task to a separate agent with its own fresh window (Cursor’s “Explore” subagent does exactly this) and return only the conclusion — a pattern central to modern AI agents.

Best practices: a checklist

• Count tokens before large requests. Branch to chunking or RAG when you approach ~70–80% of the window; leave a buffer for the reply.
• Right-size max_tokens. Reserve enough for the answer, no more.
• Prefer retrieval to a bigger window. Reach for 1M-token models only when the content truly must be reasoned over together.
• Recount after model or tokenizer changes. Especially on newer Claude models (~30% higher counts).
• Keep system prompts lean and cache stable prefixes.
• Chunk with overlap (~512 tokens, 10–20% overlap) as a starting point, then tune on your data.
• Summarize old conversation turns automatically past a token threshold.
• Log token usage in production so you catch creep before users hit errors.
• Test at your real input sizes, not just short demo prompts.

Common mistakes to avoid

• Assuming a short message means low token usage. The whole history counts — every turn.
• Forgetting the output needs window space too. Input that just fits still fails once max_tokens is added.
• Reusing tiktoken counts for Claude or Gemini. Every model tokenizes differently; counts don’t transfer.
• Treating a bigger window as a free lunch. It raises cost and latency and can lower accuracy via “lost in the middle.”
• Pasting the same document repeatedly across turns instead of retrieving or attaching it once.
• Chunking with no overlap, slicing sentences and ideas in half at boundaries.
• Reaching for fine-tuning to “add knowledge” — that’s RAG’s job, not fine-tuning’s.
• Confusing the ChatGPT app’s tier limit with the model’s API maximum. The app is usually smaller.

Tool-specific quick fixes

ChatGPT (app): Start a new chat; on Free/Plus you may need Pro or the API for large documents. Split long files and feed them in parts, or summarize section by section. Remember memory and custom instructions consume the window too.

Claude: Use count_tokens before big requests. On 1M-token models you have huge headroom, but watch the ~30% higher token counts. Use prompt caching for repeated context to save cost (not window space).

Gemini: Your best bet for genuinely huge single inputs (1–2M tokens). Use countTokens first, and remember images/video/audio are token-expensive.

Cursor: Start a new chat to reset; remove stray @-file mentions; lean on codebase indexing and @-mentions so only relevant files load; switch to a larger model or enable Max Mode; let auto-summarize condense old turns.

GitHub Copilot: It auto-compacts around 80% of the window; if you still overflow, start fresh and scope your @-references tightly.

FAQ

What does “context window exceeded” mean? Your total tokens — system prompt, history, attached files and your new message — plus the space reserved for the reply exceeded the model’s maximum window. Send fewer tokens (trim, summarize, chunk, retrieve) or switch to a larger-window model.

How many tokens is my text? Roughly 1 token per 4 characters, or 0.75 words (100 tokens ≈ 75 words) for English; code and non-English run higher. For an exact figure use the official tokenizer for your model — counts don’t transfer between providers.

Why do I get a context error even though my message is short? Because the model reads the entire conversation, not just your last line. Long history, big system prompts, tool definitions and retrieved documents all count every turn. Start a new chat or summarize the history.

Does a bigger context window fix everything? No. It buys room but raises cost and latency and can reduce accuracy (“lost in the middle”). Retrieving only the relevant chunks is usually better than a giant prompt.

How do I fix “Your conversation is too long” in Cursor? Start a new chat, remove unneeded @-mentions, let auto-summarize condense old turns, and switch to a larger model or Max Mode. Rely on codebase indexing so only relevant files load.

What’s the difference between the context window and ChatGPT’s memory? The window is short-term working memory for one request. “Memory” is a long-term store of facts about you that gets injected back into the window later — and still costs window tokens when included.

Why did I suddenly start hitting limits after upgrading models? Newer Claude models tokenize the same text ~30% higher. A prompt that fit before can overflow after an upgrade. Recount against the exact model you’re calling.

Will RAG or fine-tuning solve context limits? RAG solves it directly by retrieving only relevant chunks so the prompt stays small. Fine-tuning changes style/behaviour, not the window — for “can’t fit all my documents,” use RAG.

What chunk size should I use for RAG? Start near 512 tokens with 50–100 tokens (10–20%) overlap; smaller (128–256) for fact lookup, larger (up to 1024) for context-heavy answers. Tune on your own data.

How do I count tokens before sending? tiktoken or the web tokenizer for GPT, count_tokens for Claude, countTokens for Gemini. Counting is fast and (for Claude/Gemini) free — check before every large request.

Keep learning: videos and official docs

Recommended YouTube channels (search these queries on each): OpenAI, Anthropic, Google for Developers, LangChain, and freeCodeCamp.org. Useful searches:

• “what are tokens in LLMs explained”
• “context window limit LLM how to fix”
• “RAG chunking strategies tutorial”
• “LangChain map reduce summarization”
• “count tokens with tiktoken python”

Official references (all current as of July 2026):

• OpenAI — What are tokens and how to count them · Tokenizer tool · tiktoken
• Anthropic — Context windows · Token counting · API errors
• Google — Understand and count tokens (Gemini)
• Cursor — Codebase indexing · @-mentions
• GitHub — Copilot CLI context management
• Pinecone — Chunking strategies · Weaviate — Chunking for RAG
• LangChain — Summarization tutorial · LlamaIndex — Node parsers

---

The context window isn’t a bug to be defeated — it’s a budget to be managed. Once you stop thinking “how do I cram everything in?” and start thinking “what does the model actually need on its desk for this step?”, the error stops being a wall and becomes a design constraint you route around. Count your tokens, retrieve instead of stuffing, summarize the past, and reserve room for the answer. Do that, and “context window exceeded” becomes a message you rarely see again.