Repository navigation
Zen GLM 5.3 Flash: intermittent ~600s pre-generation delays and unknown finishes #50675
Description
Description
Re-submission of #50628 using the Bug Report fields. The previous issue was automatically closed for template compliance; the technical issue remains unresolved.
Native OpenCode with opencode/glm-5.3-flash, reasoning max, intermittently took about 600 seconds before its first recorded reasoning event. Separately, 18 preserved native invocations ended with finish=unknown and no visible answer. These may be different problems; we do not assume a shared cause.
Please correlate the following sessions with Zen routing, upstream retries, queueing and stream termination. All timestamps are UTC.
| Session | Assistant record, 2026-09-22 | First reasoning event | Interval |
|---|---|---|---|
ses_f37d79ef9ffelEzl7A5IVqwuMA |
08:08:05.113 | 08:18:10.846 | 605.733s |
ses_f37dbfd60ffeSm2TVnZ8jAwl0q |
08:03:39.629 | 08:13:42.433 | 602.804s |
ses_f37dbfd60ffeSm2TVnZ8jAwl0q |
08:15:22.252 | 08:25:26.677 | 604.425s |
The first session subsequently completed. These client-side intervals are not proof of provider queue time. Wrapper receipts show no wrapper retries; internal SDK/gateway retries cannot be excluded. Available memory was ample and the task daemon did not restart during these intervals.
Examples of the separate incomplete-response symptom, 2026-09-21:
| Session | Start UTC | Elapsed |
|---|---|---|
ses_f3c0adab2ffei7vd3V2Y2ygphQ |
12:33:35.508801 | 102.511s |
ses_f3be5d646ffeSfQyAE6aAXcOHS |
13:14:01.533272 | 381.634s |
ses_f3b8a48dcffe0J6NAEHJtzYWYU |
14:54:01.567863 | 269.783s |
Each recorded one native invocation and no wrapper retry. Usage was unavailable, not proven zero. Our wrapper killed the native process after recording the incomplete response; that cleanup signal is not evidence of an OOM or the original cause. Remaining metadata is in #50628.
Expected: a completed visible answer or an explicit actionable provider/transport error. Actual: long unexplained pre-generation intervals, or an incomplete native finish with no answer.
Is there an approximately 600-second boundary in this route? Which request ID is reliable for future correlation? Earlier Bun response-header diagnostics returned no headers, so HTTP status/request IDs cannot be reconstructed for these sessions. We now collect metadata-only stream milestones for subsequent normally scheduled runs and can provide those when available.
Plugins
No plugins on the reported historical invocations (plugin: []). Subsequent instrumentation adds a local metadata-only observer; it was not present during the incidents above.
OpenCode version
1.18.23, native Linux amd64 binary.
Steps to reproduce
- Use the native CLI with the Zen model
opencode/glm-5.3-flash, variantmax, and JSON event output. - Submit a prepared JSON classification/evidence-review task with one system instruction and one user input. The affected inner sessions had tools denied, project/external instructions disabled, no step limit, provider capacity 131072, and provider
timeout/headerTimeoutdisabled. - Compare assistant-record and event timestamps, and check the final visible answer and
step_finishrather than exit status alone.
Intermittent; no deterministic client-side or public minimal reproduction is currently available. We are not attaching private business inputs, prompts or reasoning. We have not made additional paid calls merely to reproduce this report. The supplied session IDs are intended to enable server-side correlation; we can supply safe metadata on request.
Screenshot and/or share link
No shared sessions, because they contain private inputs. Prior metadata-only report: #50628. No credentials, customer data, prompts or reasoning are included here.
Operating System
Ubuntu 26.04 LTS, Linux amd64, 8 GB RAM.
Terminal
Headless native CLI subprocess, JSON stdout, no interactive terminal.
Activity
andreaslodahll commentedon Sep 22, 2026
New metadata from an already authorized native run, not a dedicated reproduction.
Same OpenCode 1.18.23 / Ubuntu 26.04 /
opencode/glm-5.3-flash, max.This run includes the local metadata-only fetch observer described above.
Session:
ses_f362f61aaffehYiA8pcxSQnVnS. All timestamps are 2026-09-22 UTC.cf-ray: a3f278a4ce3ca9c0-CMHThe observer counted 17,016 SSE data frames, but no visible-answer event and no
[DONE]frame before EOF. Elapsed request time was 1,801.625 seconds. The nativeprocess then started a second HTTP request at 16:21:32.255; our wrapper did not
restart it or request a continuation. Its headers arrived at 16:21:43.280, HTTP
200,
cf-ray: a3f2a4ad0a05a9c0-CMH; first reasoning was 16:21:43.282.At 16:24 UTC the second request was still in progress. There is no terminal usage
receipt for the first request. The wrapper has no total/generation deadline; the
observer's first-byte silence timer was disarmed when body bytes arrived. The host
had over 6 GiB available RAM and low CPU load during the first request.
Can you correlate the two request IDs and check whether any upstream 30-minute
boundary explains the incomplete stream? We cannot establish the cause from
client milestones. This differs from the earlier ten-minute startup delays:
reasoning began promptly, and the failure occurred after the stream had started.
No prompts, customer data, raw SSE payloads or reasoning text are included.
Update: the second request completed with
[DONE]at 16:30:02.143, after509.888 seconds; its first visible answer was 16:29:31.394. The native process
exited successfully at 16:30:02.391, 2,320.493 seconds after invocation start.
It emitted one terminal usage record (66,021 reasoning and 5,571 visible output
tokens), while the observer saw two HTTP requests. Our receipt therefore marks
total usage as partial/unknown. No further experimental invocations were started.
andreaslodahll commentedon Sep 22, 2026
A second already-authorized native invocation reproduced an approximately 30-minute stream failure. No new dedicated reproduction was launched. Same OpenCode1.18.23, Ubuntu26.04,
opencode/glm-5.3-flash, max, and the same local metadata-only observer.Session:
ses_f35d99b2affekLdKPJWJ3pedTL. Times below are 2026-09-22 UTC.stream_error)cf-ray: a3f301e2483f9934-JAXThe observer counted21,890 SSE data frames. No visible-answer event or terminal
[DONE]was recorded. Elapsed request time was1,801.509s. The prior occurrence ended after1,801.625s, although that observer outcome was clean EOF rather than a reader failure. This similarity suggests a boundary worth investigating; it does not establish which component imposed it.The native process then began HTTP request2 at17:55:13.759. Headers arrived17:55:26.356, HTTP200,
cf-ray: a3f32decb94c665a-PHL; first reasoning17:55:28.943. It was still running at17:56UTC. Our wrapper did not restart the native process or ask for a continuation and has no generation timeout. Its first-byte silence timer had disarmed when the first body bytes arrived.A host check at17:42UTC showed6.1GiB available RAM,13GiB free disk, load averages0.17/0.26/0.31. This is not evidence of memory pressure. No prompts, customer data, raw SSE bodies or reasoning text are included. Terminal usage for request1 is unavailable.
Update after invocation termination:
[DONE], or terminal usage.cf-ray: a3f35a14ae79665a-PHL.[DONE].step_finishwithreason=unknown. No usable terminal cost/tokens were available. The existing wrapper then stopped further native continuation because of that explicit incomplete finish; this was not a generation timeout. Process cleanup used SIGKILL, recorded separately from the triggering finish error.provider_finish_unknownand unavailable/partial usage.The two full-length requests within this invocation ended near1,800s, matching the earlier invocation's first request. The third ended sooner with unknown finish, so we do not claim a single established root cause for all failures. No further pilot invocations are running.
jorismak-infi commentedon Sep 26, 2026
I hit this problem - also with GLM 5.3 flash. I tried it with Cloudflare Workers AI and worked, I tried it with Z.AI api directly, it works. I tried it with Opencode Go: cut off at 600s each time.
This is without a harness, raw API access, so it's not harness related. It's also not stalled - data is still flowing in every second.
Ends with
{"type":"server_error","message":"Streaming response failed: [server_error] upstream service timeout"}Comment Pi generated for posting here:
Additional data point — glm-5.3-flash, Go plan (
/zen/go/v1),reasoning_effort: max, long-reasoning agentic workload (single large-artifact implementation). Reproduced without any client harness (plain streaming HTTPS call,x-opencode-sessionpresent):{"type":"server_error","message":"Streaming response failed: [server_error] upstream service timeout"}reasoning_contentreceived, 0 content chars emitted yetRequest: raise/remove the ~600s upstream time budget for the Go gateway, or expose it per-request. Long-reasoning agentic turns (the stated target workload for Go) routinely need >10 min of
continuous generation. Related: #44148.
andreaslodahll commentedon Sep 30, 2026
Follow-up from existing runs on 2026-09-28; no new reproduction was started for this update.
Our retained metadata-only observer receipts contain 14 native invocations and 14 HTTP streams using
glm-5.3-flashwith requestedreasoning_effort: low. These are a different workload/effort from the original max-reasoning report, so they cannot establish that the original issue is fixed.[DONE]; no native HTTP retry was observed in these receipts.finish_reason: length(131,072 reported reasoning tokens, zero visible output tokens). This is distinct from a truncated stream: its[DONE]was observed.Correlation for that longest request, all UTC on 2026-09-28:
[DONE]: 12:12:21.219cf-ray: a4229450ee9a43c9-EWRThe new Go-endpoint report above is useful independent evidence, but its 600s boundary and endpoint differ from our original approximately 1,800s observations. We are not treating these as the same established cause. The original incomplete-stream issue remains unresolved from our side. No prompts, customer data, credentials, raw SSE payloads or reasoning text are included.
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
jorismak-infi commentedon Oct 12, 2026