Preserve the evidence: do not call every stop “the model broke”
When an OpeClaw response is truncated or interrupted, preserve the visible message, stop time, and final paragraph first. Avoid repeated retries because new requests can blur what happened in the original run.
Ask four questions: did you stop it manually; was there a timeout or connection message; was there a length-related message; and was the request passing through a corporate proxy, gateway, or unstable network? Exact token counts, model limits, and client control names must follow the current model documentation and client-visible messages.
If the client clearly shows 401 or 429, use the API key and quota guide. If it shows proxy, certificate, gateway, or model-address connection failure, use the proxy and model-connection guide. This page is only for content that started generating and then stopped. If the chat continues but earlier turns seem forgotten, switch to the context and session-management guide.
- Record the stop time and exact visible wording.
- Copy the last complete paragraph and mark the break point.
- Confirm whether you clicked stop, closed the window, or switched chats.
- Split out clear 401/429 and proxy-connection errors first.
- Same-chat memory drift or new-chat with no prior memory: use context & sessions.
User stop: rule out clicks, shortcuts, and chat switching
If you just clicked a stop control, used a shortcut that may cancel generation, closed a window, or switched chats during output, treat user stop as the first explanation. Do not label a short answer as a token limit immediately after an active interruption.
How the current build marks a stopped response, whether it offers a continuation control, and what that control is called all depend on the client you can see. This site does not invent a fixed button name.
For a check, resend one short question in the same setup. If short responses finish reliably and the original run stopped after your action, retain user stop as the likely cause; do not repeatedly submit a long job just to prove it.
Timeout and proxy interruption: use connection evidence, not length
Timeouts, proxy interruptions, and upstream gateway disconnects can all leave an answer in mid-sentence, but the unfinished sentence does not identify the cause. Look for timeout, connection reset, gateway, TLS, or request-failure wording aligned with the stop time.
If it reproduces only on a corporate network, VPN, or proxy—or logs show certificate and proxy clues—use the proxy and model-connection guide first. When the visible error is unclear, use the log-diagnosis guide to capture the first relevant error around the reproduction time.
Clear 401, invalid key, 429, or quota messages are not generic timeouts. Move to the API key and quota guide instead of changing networks while ignoring authentication or account limits.
Length limits and model truncation: follow current documentation
A long answer that stops may relate to context or output-length limits, but its character count cannot prove a fixed token ceiling. Models, service configuration, and client versions differ; use the current model documentation and client-visible message.
Reduce the job: request one section at a time, process only part of the source material, or ask for an outline before completing sections individually. This lowers per-request context pressure and tests whether the stop is specific to long output.
Only prioritize a length limit when short jobs finish and long jobs repeatedly stop with length-related evidence. If similar-sized jobs sometimes finish and sometimes show connection errors, return to timeout, proxy, and log evidence.
Before continuing: check code fences, lists, and unfinished steps
Find the final complete sentence, step, or code unit before asking for more. Check Markdown code fences, brackets, quotes, JSON structure, and commands carefully. If truncation happened inside a code block, never run the incomplete output.
In the follow-up message, name the sentence or step where output should resume and ask not to repeat completed material. Whether a dedicated continuation control exists, and what it is called, follows your current client; a normal follow-up message should still set a precise boundary.
For code, ask to close the unfinished structure first, then compare it manually with the preceding context. For prose or numbered lists, verify numbering so the continuation does not restart from the wrong item.
- Check code fences and brackets are closed.
- Never execute a partial final command.
- Verify list numbering and heading levels.
- Name the resume point and request no repetition.
Four stop types: choose the next guide from evidence
Use this table for routing only. It does not replace current model documentation, client-visible messages, or time-aligned logs.
| Symptom | First classification | Next step |
|---|---|---|
| Stopped after you clicked stop or switched chats | User stop | Retest one short prompt; check current client message |
| timeout, gateway, TLS, or connection failure | Timeout / proxy interruption | Proxy guide; check logs if needed |
| Long job plus an explicit length-related message | Context or output-length limit | Split the job using current model documentation |
| 401, invalid key, 429, quota | Authentication or quota | API key and quota guide |
| No clear message; only a mid-sentence stop | Insufficient evidence | Record time and use log diagnosis |
Do not infer a fixed token count from output length; follow the current model documentation and client-visible message.
Truncated & interrupted output FAQ
What should I do first when an OpeClaw answer stops halfway?
Do not immediately retry several times. Record the visible message, stop time, and final text; confirm whether you clicked stop; then check whether the answer ends inside a sentence, list, or code block. Use that evidence to separate user stop, timeout, length limit, and proxy interruption.
How can I tell a token limit from a network interruption?
Do not decide from answer length alone. Treat a length limit as likely only when the current model documentation or client-visible message supports it. A timeout or proxy interruption is more likely to include connection, gateway, TLS, or request-failure evidence. If no message is clear, preserve the time and use the log-diagnosis guide.
Can I ask OpeClaw to continue after a truncated answer?
You can send a new message naming where to continue, but control names and availability depend on the current client. First verify the last complete paragraph—especially whether truncation happened inside a code block—so the continuation does not duplicate content, omit brackets, or treat unfinished code as prose.
Should I use this guide for 401, 429, or proxy errors?
Keep those paths separate. Clear 401/429 belongs in the API key and quota guide; proxy, certificate, or model-address failures belong in the proxy and model-connection guide. Use the log-diagnosis guide when you need evidence aligned to the failure time. If the issue is forgetting earlier turns or a new chat with no prior memory—not a mid-answer stop—use the context and session-management guide.
Use this with an OpeClaw workflow
Check the current OpeClaw download status first, then save this guide as part of your setup, review, or troubleshooting workflow.