Does anybody also encounter "Output token limit reached" error while using dsh?

[Biogod2020]

[manhtt2309]

I met same issue.

[dynamo-llc]

me too!

[bevinkatti]

I checked the current dsh flow, and this looks different from a context-window overflow.

dsh-agent-loop treats a max-tokens finish as a completed model request, while automatic compaction is primarily triggered by token pressure before a step or by a provider-confirmed context-window overflow. So hitting the output cap does not necessarily trigger compaction/recovery automatically.

For the built-in DeepSeek adapter, the current default conversation maxTokens is 256,000, and it can be overridden by the adapter config, a model-specific cap, or an explicit agent/request value. The adapter also intentionally doesn't clamp that value against the context window.

If you're seeing this regularly, could you share:

• which provider/model you're using,
• whether you're using the default llm-deepseek adapter or llm-pi-ai,
• and the effective maxTokens configuration?

That would help distinguish an intentionally configured output cap from the model actually exhausting its available generation budget. If the expectation is that dsh should automatically resume after a max-tokens finish, that looks like a separate agent-loop behavior/feature rather than the existing compaction path.

[adwaithadwaith]

@bevinkatti Hi I'm currently using qwen3.8 27b running on ollama server and the adapter is llm-pi-ai. The max-token configuration I have set is 8192.

[adwaithadwaith]

I have the same issue

[bevinkatti]

Thanks, that helps narrow it down. With qwen3.2:7b running through Ollama and llm-pi-ai configured with max-token = 8192, the message is consistent with the generation hitting the configured output limit rather than dsh losing the connection.

Before increasing it, could you check whether the Ollama response reports done_reason: "length" when this happens? That would confirm the response is being terminated by the generation limit.

If it does, the next thing I'd check is whether llm-pi-ai is forwarding the configured max-token value directly to Ollama. If it is, then 8192 is simply the effective generation ceiling for that request.

If you can paste the relevant Ollama/dsh debug output for one occurrence (with any API keys removed), we can determine whether the limit is coming from dsh, the Pi adapter, or Ollama itself.
@adwaithadwaith

[LeonidasTMT]

Same problem running Qwen 3.8 27b

This is after a 1hour 30minute run, I end up with only 320 tokens headroom, but the prompt should be nowhere close to 65K tokens

2026-08-19 22:33:18 [DEBUG]
I slot print_timing: id 3 | task 0 | prompt eval time = 61628.73 ms / 65216 tokens ( 0.94 ms per token, 1058.21 tokens per second)
1.39.732.171 I slot print_timing: id 3 | task 0 | eval time = 31574.96 ms / 320 tokens ( 98.67 ms per token, 10.13 tokens per second)
1.39.732.172 I slot print_timing: id 3 | task 0 | total time = 93203.69 ms / 65536 tokens
1.39.732.173 I slot print_timing: id 3 | task 0 | graphs reused = 318
2026-08-19 22:33:18 [DEBUG]
1.39.733.721 I slot release: id 3 | task 0 | stop processing: n_tokens = 65535, truncated = 1

[bevinkatti]

That log actually makes the cause much clearer. The 320 isn't the configured 8192 output limit being reached — it's the amount of output that could fit after the prompt had already consumed almost the entire Ollama context.

65216 prompt tokens + 320 eval tokens = 65536, and the final n_tokens = 65535, truncated = 1 is the strongest indication that Ollama is hitting its 65,536-token context ceiling.

So when you say the prompt shouldn't be anywhere near 65K, I'd check the serialized request rather than the visible conversation. With dsh this includes the system prompt, tool definitions, session history, and tool results, not just the text you typed.

The next thing I'd check is the model's contextWindow in your dsh llm-pi-ai configuration. dsh uses that metadata for its context/compaction handling, so if dsh thinks the model has a larger window than the Ollama server actually has, compaction can happen too late and Ollama will hit its hard 65,536 limit first.

If your Ollama server is intentionally configured for 65,536 context, try declaring the same value for the model in settings.yaml and see whether auto-compaction starts before the backend reaches 65,536. If you paste that model's llm-pi-ai entry, we can check the exact configuration.

[LeonidasTMT]

Yep, you're right about my LM Studio server being configured for 65,536 context and also same is reflected in DSH

Oddly not reflecting in chat though

Side is that surprisingly it managed to run for over 90 minutes since yesterday before hitting the cap.

New chats do inherit the lower context size, but not this chat, branching doesn't help either

[LeonidasTMT]

So trying continue again, somehow it could run a little and the context size got updated but its basically stuck at 100%, no way to salvage the chat unless I use a larger model to compact? Since compacting fails too. Do correct me if I'm wrong

[bevinkatti]

That helps narrow it down further. If both LM Studio and dsh are configured for 65,536, then the mismatch I suspected earlier probably isn't between the configured context-window values.

The interesting part is that the existing conversation still gets stuck at ~65.5K and compaction repeatedly fails, while a new chat apparently inherits the lower context settings correctly.

That makes me wonder whether the context-window value is being captured/cached when the session is created, and changing the model configuration doesn't retroactively update the existing session.

If you can reproduce it, it would be useful to compare the effective contextWindow/max_tokens values for the old session versus a newly created session using the same model. That could tell us whether this is a stale session configuration issue or something in the compaction path itself.

[denial123789]

This is an output-generation ceiling, not necessarily an input context-overflow error. Harness maps the provider stop reason length to the durable max-tokens turn reason, retains the partial assistant message, and does not dispatch tool calls from that truncated step.

For the llama.cpp trace here, 65,216 prompt + 320 generated = 65,536 total shows that remaining context headroom is the binding limit. An 8,192 request maxTokens cannot fit into the 320 tokens left in the context window. The effective budget is the minimum of the request cap, the provider/model output capability, and context window - prompt - reserve.

I wrote a source-linked diagnostic and bounded recovery checklist here: https://sandbaseai.github.io/deepseek-harness-handbook/output-token-limit.html

The safest recovery is to preserve the partial artifact, start a bounded continuation (for example, only the missing sections), and measure prompt/output usage plus the final stop reason before raising any cap.

[davidmacmillan]

This error makes long runs - supposedly a Deepseek Harness strong point - impossible to execute. SIgnificantly I was unable to 'continue' without slamming right back into the same error.

Problem: I am getting the same error on long runs: 'Output token limit reachedThe reply was cut off; earlier output is preserved in the conversation. Send "continue" to let the model resume.'
I am running llama-server locally with model: "unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL" with "--ctx-size 200000".
That n_ctx conext length limit is clearly shown in the return string from http://<ip>:<port>/v1/models in parameter n_ctx but DeepSeek Harness ("DSH") is not triggering a compaction early enough to avoid hitting the limit.

There appear to be two bugs here:

1. The first bug is DeepSeek Harness is looking for 'max_tokens', which is not output by llama-server. llama-server outputs 'n_ctx' to indicate the context window maximum size, for example in response to http://<ip>:<port>/v1/models. The fix is for deepseek harness to watch for 'n_ctx' and to respect that limit. Be careful here, because llama-server also outputs 'n_ctx_train' - that is a different parameter, may have a different value, and is not what you want to use. (Openclaw made the mistake of using 'n_ctx_train')

2. The second bug appears to be a deliberate design decision. Discovery of the maximum context length is wired only to the "fetch available models" button on the Models page. Nothing calls it at request time. resolveModel() in adapter.ts:256 uses the catalog config, installed catalog, or the default. So even a perfectly fixed readListing() would only pre-fill a form field that you then have to save. If you restart llama-server with a different --ctx-size during a DSH run, the DSH harness never notices. So how do other harnesses handle this? None appear to check n_ctx on every conversational request becasue that is too high an overhead. Instead:

oh-my-pi (issue #3310, closed by PR #3311) probes once at discovery and caches it in SQLite. Restarting the server with a different n_ctx would ignore it for a day. Apparently there is a fix that does the following:

• Read per-model meta.n_ctx from /v1/models, falling back to /props because /props is server-level and llama-swap-style forks give each model its own --ctx-size.
• Lazy re-resolution on model select. Re-query when the user picks a model, since meta.n_ctx only appears once the model is actually loaded (unloaded models show no n_ctx; /props returns n_ctx: 0).
• Fingerprint the cache key on build_info + model_path + n_ctx so a restart invalidates immediately.

Openclaw (issue #73664 openclaw/openclaw#73664) has the same problem as DSH. It reads the wrong field n_ctx_train rather than n_ctx.

OpenHarness (issue #199 HKUDS/OpenHarness#199) has the same problem as DSH. Their fix is to widen the error matcher to catch exceed_context, exceeds the available context size, and exceed_context_size_error, plus a documented env override.

I am not proposing a specific fix for DSH because I am still not up to speed on the design philosophy behind the architecture. It seems bug 1 can be addressed simply using the n_ctx setting during model selection. Bug 1 is essential to fix immediately - it is critical. Bug 2 perhaps needs both the cache fingerprinting and error recovery approaches to be robust during long runs. In particular, the longer the agentic run, the more likely the LLM server will restart with a different n_ctx limit. As agentic harnesses extend into days and weeks long runs, Bug 2 becomes increasingly important to fix.

[DarkFlowSignals]

This might help you all. #3685

[luisecastro]

I kept having this problem, I had in Ollama context length 64K, but the DeepSeek harness had the published amount of 256K, whenever it reach to 64K the error appeared (so around the 25% mark)

I had to modify the context window in the config and open a new session within the workspace for it to take the 64K value (if I restart the harness it overwrites it to 256K).

Have not had the problem again.

[bevinkatti]

That’s a useful data point. It makes the configuration/session mismatch look more likely.

The fact that changing the Harness context window to 64K and starting a new session fixes it suggests the existing conversation may have been created with a different context-window value and continued using that metadata, rather than the current model/provider limit.

It would be interesting to confirm whether restarting the server alone (without creating a new session) also fixes it, or whether the session has to be recreated. If the latter, that would point more strongly to the context configuration being captured/stored at session creation time.

This also fits the earlier 65,535 n_tokens case: the model itself wasn't necessarily trying to generate 65K tokens; the request appears to have exhausted the effective context budget after accounting for the prompt/history.

I think the next useful thing to inspect is the serialized request/debug output for the affected session - specifically the effective context_window and max_tokens values actually sent to the provider.

[sjdevries]

I ran into the same issue when running LM Studio with Ornith 1.5 35b A3B. Also setting 65535 for context length. Setting the contextWindow seems to have fixed the issue on new sessions. Old sessions are still broken though. Cannot compact and cannot continue.

To be clear I initially set max context length because I was hoping the MoE model would handle it. Unfortunately LMStudio has a 5 minute timeout that closes the sessions while its churning prefill. I had to drop to 65535 context to make sure LMStudio received a token before the 5 minute timeout.

I have not tried changing the model in an older session to see if I can fix it.

It might be possible to fix using a different back end. Something that does not suffer the 5 minute timeout might let me up the context to the maximum allowed and then successfully compact.

[weijiafu14]

Datapoint from a reproducible harness, since this thread keeps collecting cases where the declared limits and the runtime's real limits disagree (Ollama/LM Studio context mismatches above):

We ran stock @deepseek-ai/dsh@0.1.1-rc.2 with pi2dsh 0.23.0, declaring a provider model with a deliberately tiny maxTokens: 24, against the real DeepSeek API behind a transparent recording proxy (requests forwarded verbatim; the proxy only writes down what was sent). What we observed, all recorded:

• the declared cap reaches the wire: the request body carried max_tokens: 24 (so whatever you declare in the model entry is what the backend actually enforces against);
• when the model hits it, the truncation is surfaced honestly: the session log closes the turn with reason: {kind: "max-tokens"}, the partial text is kept, and the CLI exits nonzero — no crash, no silent loss.

Evidence: case token-limit in provider-threads-e2e.json, harness in verify-provider-threads-e2e.mjs.

Practical consequence for the local-runtime cases here: this error family is usually the declaration disagreeing with the runtime (e.g. catalog says 256K context while Ollama is configured at 64K, as @luisecastro found). If you route through a provider declaration you control, set contextWindow/maxTokens to what your runtime is actually configured for, and the harness above is a way to verify what's really being sent.

Scope note: our run is against api.deepseek.com, not Ollama/LM Studio — it demonstrates the declaration→wire→surfaced-stop chain, not your specific local runtime's behavior.

[PerryLink]

TL;DR: this is the output ceiling, not input-context overflow - and the fix is the configured context window, applied to a new session.

1. Mechanism: the harness maps the provider stop reason length to the durable max-tokens turn reason (see @bevinkatti and @denial123789 above). Your request was cut at the output limit, not by a full context window - that is why the prompt can be nowhere near 65K tokens yet still hit it.
2. Checklist (each confirmed in this thread):
   • Set contextWindow (or your endpoint's context length) to what the endpoint actually supports - e.g. Ollama: the model's num_ctx; LM Studio: its context slider; DeepSeek API: V4 models support up to 1M.
   • Start a new session after changing the config - old sessions keep the stale window (several users above verified this).
   • Check the output-side limit too: maxTokens / provider max_tokens (e.g. 8192 in one repro above).
   • Long runs: compact the session before continuing instead of pressing on.
3. If you want to see where each request hits its ceiling, my dsh-budget plugin tracks per-session token usage, latency and cost (dsh plugin --profile web add dsh-budget; disclosure: I maintain it).

If this resolves it for you, marking it as the answer helps future readers find the fix.

[krypt-lx]

Ok, I hit the same issue in the first use of this harness, but I recognise the symptoms:

• all those logs looks like lm studio logs;
• dsh does parallel queries to llm server it uses (multiple concurrent agents);
• lm studio does support parallel queries and runs them in parallel, BUT apparently total size of context must not exceed the context size set in LM Studio gui.
• if this combined context size exceeds context size set in LM Studio - it throws exception on all running inference.

So, somehow we need to tell dsh to run only a single inference at the time

My case is solved by using dsh-concurrency-guard plugin. It is in Chinese, though. In gui it adds "并发监控" tab next to "Trajectory", in that tab use "上限−"/"上限+" buttons (top right) to set number of concurrent agents to 1.

Edit: dsh-concurrency-guard just throttles concurrent requests, not stops them. There is a timeout need to be changed in ~/.dsh/profiles/web/cordis.patch.yml:

- id: concurrency-guard
  config:
    maxQueueWaitMs: 3000000   # 50 min; 0 = wait forever

[bevinkatti]

That’s an interesting finding. It could explain some of the LM Studio cases that don't seem to match the single-request context limit.

If DSH is sending multiple concurrent inferences, it would be useful to know whether the LM Studio context limit is effectively shared across those requests. That would also explain why limiting concurrency to 1 fixes it even when the individual conversation is below the configured context size.

I’ll keep this in mind as a separate factor from the stale context-window issue.

[sjdevries]

That explains why I ran into this again today even with the contexts set to 65536 on both LM-Studio and dsh. It was working fairly well until I gave it a more complex task to handle. I'll have to try the plugin or otherwise limiting to single inference.

[rktvr]

i'm running into this now since the latest update. i could let it run for hours on end but now on the same config it just fails on that:

Output token limit reachedThe reply was cut off; earlier output is preserved in the conversation. Send "continue" to let the model resume.

that "continue" is also a lie, the message is never handed to the llm and it just starts over again.

[sjdevries]

I keep hitting this as well. Haven't found anything that really fixes it.

[krypt-lx]

AI says this issue happens than LLM server generated an error message saying model ran out of context.
It seems to be happening if this error happens during thinking phase

[krypt-lx]

I want to say, you can ask AI to do tasks managing, configuring, and patching the harness. I do it with Qwen 3.8 27b, it does this quite well.

[americanjeff]

I hit a similar problem with qwen3.8-27b, not sure if it's exactly the same tho. For me the problem was a combination of auto-compaction firing too late and the token limit for compaction being too small for how much thinking the model wanted to do (see https://github.com/Yunado/dsh-compaction-fix).

I fixed the max-output setting and applied a modified version of the compaction fix, but even that wasn't enough because I was using the model via the stock Add Custom Provider setup and it doesn't discover reasoning effort settings for local models at all.

my reaction to that was to go overboard and create a plugin to manage local model config with proper capability discovery: modelspoke but I think it could also be accomplished by manually editing ~/.dsh/settings.yaml. As a side-effect of creating the plugin tho I also had the chance to fix read_image functionality to make use of qwen's image input capability so it wasn't a complete waste of time.

My minimal version of the compaction patch is in minimal-compaction-patch.sh.

[sjdevries]

In my ~.dsh/setings.yaml I ended up setting the following:

  models:
    - id: qwen/qwen3.8-27b
      name: qwen3.8-27b
      contextLength: 65536
      contextWindow: 65536
      maxTokens: 8192

contextLength may not be required, but was part of trying to fix it previously.
Note: when maxTokens set to 4096 I would still run into this issue sometimes.

In LMStudio > Local Server > Inference (Tab)
Reasoning Budget [x] 1024

So far that seems to be working for me. Have gone a whole day at least without the error. Hopefully this information helps.