Last checked against Anthropic’s published documentation on 17 September 2026.
Claude stopping halfway through a sentence is almost always the response length limit, not a crash and not the conversation running out of room. Each single reply has a maximum length, and long answers hit it before they finish. Say “continue” and Claude picks up where it stopped. The better fix is asking for the work in pieces so no single reply has to be that long.
Claude is halfway through the thing you asked for and it just stops. Mid sentence, sometimes mid word. No error, no warning, nothing obviously wrong.
It is almost always one specific thing, which is good news, because it means there is a reliable fix rather than a mystery.
The confusing part is that two completely different limits get blamed for this and only one of them is usually responsible. Worth separating them before you try anything.
Which one are you seeing?
The reply stops mid sentence and everything looks otherwise normal
The response length limit. Say “continue” and it carries on. Fix 1 below.
The reply stops and Claude then says the conversation is too long, or you cannot send another message
Different problem. That is the conversation filling up rather than the reply running long. Skip to the section on long conversations.
The reply stops and you get an error, or the text vanishes entirely
Not a length limit at all. That is a network or server fault, and the fixes live on our network error page instead.
You have hit one of two limits, and they are not the same
People use "limit" for both, which is why the fixes get mixed up.
A usage limit governs how much you can use Claude across all of your conversations. It resets on a schedule. When you hit it you are stopped from sending, and the message says so.
A length limit governs how long a single conversation can become. It is set by the model’s context window, which is 200K, 500K or 1M tokens depending on the model and plan. Part of that window is always reserved for the reply, so the longest usable conversation is always smaller than the headline figure. That is everything in the chat so far, your messages and Claude’s, plus any files you have attached. When that fills up you get told about it explicitly, and the answer is a new chat rather than a nudge to continue.
Two limits that get confused
Usage limit
- Scope
- Across every chat
- Governs
- How much you use
- Resets
- On a schedule
- Symptom
- You are stopped
Length limit
- Scope
- Inside one chat
- Governs
- How long it gets
- Set by
- 200K, 500K or 1M
- Symptom
- The reply runs short
That reservation is the answer to the cut-off question. As a conversation grows, the room left for the response shrinks. The reply that would have been complete in a fresh chat gets truncated in a long one. The fix is to start a new conversation and carry across only what is needed, not to re-ask the same question in the same thread.
One reply stopping short does not mean the whole conversation is full. Claude was still writing, ran out of room for that one message, and stopped where it was. The conversation is fine. You can carry straight on.
Fix 1: say continue
Type “continue” and send it. Claude picks up from where it stopped, usually mid sentence, and finishes.
Some interfaces show a Continue button instead. Same thing, and it is worth clicking when it appears. When it does not appear, typing the word does the job.
Two things make this work better. Asking Claude to “continue from where you stopped” rather than just “continue” avoids it restarting the section, and if what got cut off was a long code block or a table, asking it to continue from a specific line or row gets you a clean join rather than a repeated chunk you have to edit out.
Fix 2: ask for less at a time
The real fix is to stay under the limit rather than fight it.
If you asked for ten sections, ask for three. If you asked for a full script, ask for one function, then ask for the next one. The work arrives complete each time instead of arriving truncated and needing to be stitched.
This sounds like more effort and is usually less, because a stitched-together answer has seams in it and you end up checking the joins.
Fix 3: tell it the shape you want up front
Claude does not know how long your request is going to be until it is writing it. You do.
Saying “give me the outline first, then I will ask for each section” or “keep this under 800 words” changes what it produces rather than how it gets cut off. So does naming the format: a table, a bulleted list, a summary, all of which are naturally shorter than prose on the same topic.
Fix 4: for code, ask function by function
Code gets cut off more than prose because it is longer per unit of meaning. It is worse to have truncated, because a half-written function does not run.
Ask for the file structure first, then each function or component as its own request. You get working pieces instead of a plausible-looking file that fails on the line where it stopped.
If you are working on something large, this is what Claude Code exists for. It writes to your file system in steps rather than producing everything as chat output, so the reply length limit stops being the constraint.
Running it unattended for hours raises a different question: not whether one reply gets cut short, but whether the rules you gave it hold for the whole run. Why a CLAUDE.md file is not a control covers that.
Fix 5: when the conversation is what is full
If Claude tells you the conversation is too long, no amount of continuing will help. The chat itself is out of room.
Start a new one, and bring the context with you deliberately. Ask Claude in the old chat to summarise where things got to, then paste that summary as the first message in the new chat. You lose the detail and keep the thread, which is usually the right trade.
If you find yourself doing this often, put the durable context somewhere it does not need repeating. A Project holds files and instructions across every chat inside it, so the background does not eat the conversation every time.
When it is not a length limit at all
Two things look like a cutoff and are not.
A server fault stops the response and usually leaves an error, or leaves the reply visibly incomplete with no way to continue it. If continuing does nothing, or the text disappeared rather than stopping, that is what happened. Retry the message.
The other is a response that finished but ended awkwardly, which happens when Claude was near the limit and wrapped up faster than it should have. That one is compression, and truncation is a different problem. The fix is asking for the section again on its own with room to do it properly.
How to avoid it next time
Ask for one thing at a time, in the shape you want it.
Say how long you want the answer to be. It is the single most effective instruction most people never give.
And for anything genuinely long, get the outline first. You will spot what is missing before Claude has written five sections of it.
Written by the team at Lead Source, whose actual job is lead attribution, but who have asked Claude for one more section more times than is reasonable.