I noticed something odd in OpenCodeâs model metadata:
opencode/deepseek-v4.1-flash-free:Â 200k contextopencode-go/deepseek-v4.1-flash:Â 1M context
Both point to the same canonical model, deepseek/deepseek-v4.1-flash, so I wanted to find out whether the 200k limit on the free version was actually enforced by the inference backend or was just OpenCode catalog metadata.
It looks like itâs just metadata.
What I tested
I temporarily overrode the free modelâs local context limit in opencode.json so OpenCode itself wouldnât compact at 200k, then sent increasingly large generated text files through both models.
The override only changes OpenCodeâs local budgeting/compaction. It does not change whatever limit the server actually enforces.
Boundary results:
| Approx. message size |
Free |
Paid Go |
| ~982k tokens |
â
OK |
â
OK |
| ~1.037M tokens |
â
OK |
â
OK |
| ~1.107M tokens |
â HTTP 400 |
â HTTP 400 |
So both versions crossed the supposed 200k free-tier limit by a huge margin and then hit essentially the same wall.
The OpenCode gateway unfortunately returns an empty 400 body at the limit, so I also sent an oversized request through the direct DeepSeek API.
That returned the useful part:
This model's maximum context length is 1048576 tokens.
So the actual model ceiling is 1,048,576 tokens (2²â°).
That lines up almost perfectly with OpenCode calling the paid model â1Mâ.
Free vs paid performance
Since I already had the test setup running, I also compared the two tiers.
Large-context latency:
| Input |
Free |
Paid |
| ~982k |
26.0s |
25.2s |
| ~1.037M |
37.1s |
32.6s |
These are single samples, so I wouldnât read anything into the small difference. Both were in roughly the same ~30â40k tok/s prefill class.
For decode throughput, using temperature 0 and fixed ~800-token outputs:
- Free:Â ~113â121 tok/s across 4 samples
- Paid:Â ~102â120 tok/s across 2 clean samples
Again, effectively indistinguishable in this small test.
I also ran a deterministic five-question battery plus âfirst 100 decimals of piâ through both tiers at temperature 0.
The outputs were byte-for-byte identical. Token accounting was also effectively identical apart from prompt-cache hit distribution.
Reasoning variants work normally on the free model too. On the same multiplication task:
#low: 70 reasoning tokens- default: 228
#max: 719
All three returned the correct answer.
The config override
For testing I used:
{
"providers": {
"opencode": {
"models": {
"deepseek-v4.1-flash-free": {
"limit": {
"context": 1000000,
"output": 384000
}
}
}
}
}
}
Important: this does not magically increase the providerâs context window. It just tells OpenCode not to treat 200k as the local ceiling.
Also, I did not independently boundary-test a 384k generated output, so Iâm specifically claiming the ~1M contextfinding here, not that every piece of the paid modelâs metadata necessarily applies to the free endpoint.
My conclusion
As far as I can tell, the 200000 context value on deepseek-v4.1-flash-free is stale/conservative catalog metadata rather than an actual free-tier serving restriction.
Everything I could measure black-box points to the free and paid endpoints exposing the same DeepSeek V4.1 Flash context capability:
- same ~1M context boundary
- same failure point
- same performance class
- same deterministic outputs
- same reasoning behavior
What this doesn't prove is that they use literally identical weights, quantization, hardware, or routing internally. Youâd need information OpenCode doesnât expose, such as useful logprobs or backend details, to establish that.
And obviously the free model is advertised as free for a limited time, so I wouldnât build anything critical around its continued availability.
But if youâre using the free DeepSeek V4.1 Flash model in OpenCode and wondering why it says 200k: based on these tests, the backend itself appears capable of the full ~1M context window.
Would be interested if anyone else can reproduce the same boundary on their account.
