Long assistant responses truncated mid-generation with thinking model opencode-go/hy3 (no local config knob)

[RuszLi]

Summary

When the orchestrator model is a "thinking" model served by the opencode-go provider (e.g. opencode-go/hy3), long assistant responses — including long internal reasoning — are truncated mid-generation. The message simply stops, often mid-sentence, with no error. This makes it impossible to complete multi-step tasks that require long output; the agent appears to "hang" or "interrupt."

Environment

• OpenCode client (Go build, model reported as opencode-go/hy3)
• OS: Windows
• The opencode-go provider is enabled via the oh-my-opencode-slim preset ("preset": "opencode-go" in ~/.config/opencode/oh-my-opencode-slim.json)

Reproduction

1. Set the orchestrator to a thinking model such as opencode-go/hy3.
2. Give it a task that requires a long reasoning trace or a long response (e.g. analyzing a ~970-line script, counting struct fields, etc.).
3. The assistant response is cut off partway through, repeatedly, even when the intended output is not that large.

Key observation

The model ID opencode-go/hy3 is not present in any local config file:

• ~/.config/opencode/opencode.jsonc — no hy3
• ~/.config/opencode/opencode.json — no hy3
• ~/.config/opencode/oh-my-opencode-slim.json — preset defines opencode-go/minimax-m3 (orchestrator, variant: "thinking"), opencode-go/qwen3.7-max, opencode-go/deepseek-v4-flash, opencode-go/kimi-k2.7-code, opencode-go/mimo-v2.5 — but no hy3.

So there is no obvious local knob (e.g. max_tokens / reasoning budget) to raise the output/thinking token limit for this model. Users cannot easily work around the truncation.

Impact

• Multi-step coding tasks that need long outputs cannot be completed.
• The agent looks broken ("thinking interrupted") to the user.
• Switching models is the only apparent workaround, but the desired model (hy3) is not even configurable locally.

Request

1. Make the output / thinking token limit configurable for provider models (e.g. a max_tokens or reasoning-budget field in the model/preset config), or raise the default so long responses are not hard-truncated.
2. Document where opencode-go/hy3 (and other opencode-go/* models) parameters are defined, since they are absent from the local config files.
3. Ideally, avoid silently truncating mid-generation — stream the full output or emit a clear warning/error instead of cutting off.

Additional notes

• gh is authenticated (confirmed gh auth status → logged in to github.com as RuszLi with repo scope), so this can be reproduced/verified by maintainers if needed.
• This report describes the observed symptom; the exact root cause (client-side output cap vs. provider-side thinking budget) is not yet confirmed.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Bug: limit.output in config is silently capped at 32k; OPENCODE_EXPERIMENTAL_OUTPUT_TOKEN_MAX is a poor workaround #29363: Same root cause — the 32k per-step output cap silently overrides limit.output config, causing reasoning models to exhaust the budget with 0 visible output and no error. Extensive discussion and analysis already there.
• Go: hy3 stream returns empty event-stream (non-stream 200 OK) #43851: Related — same opencode-go/hy3 model, empty event-stream / non-stream 200 OK response, reported the same day.
• [FEATURE]: Auto-continue when model hits output token limit (finish_reason: "length") #17471: Feature request for auto-continue when finish_reason: "length" is hit — the loop-break behavior described here.
• DeepSeek V4 Flash Free: output truncated mid-sentence without warning #39582: Same symptom (truncated mid-sentence, no warning) on a different provider.

If your issue adds new context specific to opencode-go/hy3 (e.g. the model not being locally configurable at all), it may be worth keeping open — but please coordinate with maintainers to avoid duplicate effort, and consider adding a comment to #29363 linking your findings.