Repository navigation
Zen Go: deepseek-v4.1-flash decode throughput down to ~119 tok/s median (254 at launch, 183 when reported in #51010) #55579
Description
Description
Follow-up to #51010, my report on this route three weeks ago. Throughput for deepseek-v4.1-flash on the Go endpoint has roughly halved again since then, and it is now erratic as well as slow.
Measured from my client's own session records (output tokens ÷ the message's own stream window, the same method as #51010), same machine, Go plan:
| period | steps | median tok/s | p10 |
|---|---|---|---|
| 09-17 – 09-18 (launch week) | 4,258 | 254 | 183 |
| 09-24 (the #51010 report) | 1,184 | 183 | 110 |
| 10-13 – 10-14 | 5,223 | 119 | 70 |
End to end — what the user actually waits for, TTFT included — a step now medians 80 tok/s (p10 42) against 124 at launch, and about a quarter of recent steps land under 60 tok/s.
The peer routes on the same machine over 10-12 – 10-14 are unchanged: Command Code 177 median (n=2,972) and DeepSeek's own API 194 (n=27). So this looks specific to the Go gateway rather than the model or my connection.
A controlled probe today (same prompt, 600 output tokens, no context) gave 132 / 143 / 186 tok/s — and one run at 44 tok/s with a 16.2s TTFT, so the route also stalls rather than just decoding slowly.
Could you confirm whether Go-route requests are served on different capacity from the pay-as-you-go Zen endpoint? Happy to run a controlled A/B with the identical prompt against both endpoints if that helps.
Steps to reproduce
- Stream a request to
https://opencode.ai/zen/go/v1/chat/completionswithmodel: deepseek-v4.1-flashandstream_options: { include_usage: true }. - Compute output tokens ÷ (last chunk time − first chunk time).
- Repeat against DeepSeek's own API and Command Code with the same prompt and compare.
OpenCode version
Not the OpenCode client — a third-party OpenAI-compatible harness, which the Zen docs describe as supported. Requests carry x-opencode-session.
Operating System
macOS, Apple Silicon, wired connection.
Activity
opencode-agent commentedon Oct 15, 2026
Thanks for the detailed follow-up and the new measurements. I think this is a duplicate of #51010, your earlier report on this route, which is still open. It's the same problem: low decode throughput for
deepseek-v4.1-flashon the Zen Go endpoint compared with the same model on other routes. The new data shows it has got worse since then.Possible duplicates and related issues, ordered by likelihood:
It would help to add the new numbers (the 10-13 – 10-14 median of 119 tok/s and the probe run with a 16.2s TTFT) as a comment on #51010, so everything is tracked in one place.
The bot will close this issue as a duplicate in 1 day unless you reply explaining how it's a different problem.
tigerwho1888 commentedon Oct 15, 2026
Agreed — closing this as a duplicate. The new numbers are now in #51010 (comment: #51010 (comment)), so everything stays in one thread.
opencode-agent commentedon Oct 15, 2026
Thanks for moving the new measurements to #51010. Updates on this route will now be tracked there, and the bot will close this issue as a duplicate.
opencode-agent commentedon Oct 16, 2026
Closing as a duplicate of #51010, as agreed above. Thanks for adding the new throughput numbers there. Please follow #51010 for updates on
deepseek-v4.1-flashon the Zen Go route.