DeepSeek API vs OpenCode Go:
same model, different latency
There is a persistent claim that the OpenCode Go relay serves a worse DeepSeek than the direct API. I tested it: 1,176 requests, deterministic graders, identical prompts. The model behind both endpoints is the same one. What you actually feel is the wire.
What was measured
Two endpoints, one model family: api.deepseek.com/v1 with deepseek-flash and
opencode.ai/zen/go/v1 with deepseek-v4.1-flash. Same prompts, same max_tokens,
temperature=0, run eight times per task. Grading is programmatic — numeric answers, parsed JSON,
generated code executed against test cases, tool-call arguments inspected — so no model judges another model.
72 tasks across seven categories, plus two probes: a 58K-token needle and a 20-tool selection test.
A separate logprob probe (one token, top_logprobs=10) fingerprints the engine itself.
Quality
| Category | Direct | OpenCode Go | Δ points |
|---|---|---|---|
| Arithmetic | 99.4% | 100.0% | +0.6 |
| Logic | 100.0% | 100.0% | +0.0 |
| Instruction following | 100.0% | 100.0% | +0.0 |
| JSON schema | 100.0% | 100.0% | +0.0 |
| Code generation | 90.6% | 92.2% | +1.6 |
| Tool calling | 100.0% | 98.8% | -1.2 |
| 64K context | 96.9% | 96.9% | +0.0 |
| All | 98.6% | 98.8% | +0.2 |
95% confidence intervals overlap across every category. The difference is inside the noise.
The model is the same model
Asking both endpoints for one token with logprobs shows the identical top-1 token on 8 of 9 prompts, a median |Δlogprob| around 1e-5, and 4 of 5 shared tokens in the top-5. Different weights, a different quantization or a different tokenizer would show up here immediately. It does not.
What does differ is sampling bookkeeping: neither endpoint is deterministic at temperature=0
(31% and 32% of tasks varied across eight repetitions), so anyone comparing single responses is comparing noise.
Latency
Median of all graded calls, plus the streaming probe. Throughput follows the same pattern: 140 tok/s direct vs 97 tok/s through the relay.
The penalty grows with the prompt. On short chats it is a few hundred milliseconds; at 58K tokens it is three seconds per call. In a long agent session — dozens of calls per task — that is the difference the user actually perceives as "the model got worse".
Cost
Both endpoints bill the same internal rate: $0.15 per million input tokens (cache miss),
$0.003 (cache hit) and $0.60 per million output tokens. The relay's own
list_cost field reproduces DeepSeek's off-peak price to the cent. Direct billing doubles during
DeepSeek's peak hours; the Go plan is a flat subscription whose usage is deducted at 0.6× that list price.
| Scenario (typical agent turn: 69K in, 98% cached, 600 out) | USD / turn | USD / 1,000 turns |
|---|---|---|
| Direct, off-peak | $0.00081 | $0.81 |
| Direct, peak (2×) | $0.00162 | $1.62 |
| Go plan, list cost | $0.00081 | $0.81 |
| Go plan, deducted from quota (0.6×) | $0.00049 | $0.49 |
A $10/month plan breaks even against off-peak pay-as-you-go at roughly 12,322 turns per month for this workload.
Where the relay really differs
- Prefix cache is tied to the session id. With a fresh id per request,
cached_tokensstays at zero; with a stable one it caches normally (measured: 4,608 of 4,720 tokens). Clients that generate a new session id per call pay full input price every time. - Reasoning tokens disappear on
/responses. The relay reportsreasoning_tokens: 0while the model clearly reasons;/chat/completionsreports them correctly. Answers are identical, accounting is not. - Logprobs are partially supported. Some requests land on a backend that answers
400 logprobs are not supported by the cell router yet, and only content logprobs come back. - It trims reasoning. With the same
reasoning_effort, Go spends 10–15% fewer reasoning tokens than the direct API — invisible on these tasks, relevant if you rely on deep thinking.
What this does not prove
It does not measure long agentic runs (50+ tool calls, 150K+ context), where relays are known to drop streams or return opaque 400s. That is reliability, not model quality, and it needs its own test. It also does not measure subjective long-form writing: the suite is deliberately deterministic so the result can be checked by anyone.
Verdict
If the complaint is "the answers are worse", the data says no: it is the same model with the same accuracy. If the complaint is "it feels slower", that is real and measurable — +28% on short prompts, 2.6× on 58K-token ones. Choose on latency and cost, not on quality.