Measured performance

Figures from an on-prem installation, measured on 2026-09-17 from a lab notebook with OpenCode 1.18 against two models from the model catalog: Qwen3.8 27B (FP8), a reasoning and code model, and Qwen3.6 35B A3B (FP8), the fast one. In your installation the product aliases may point to other models: GET /v1/models/aliases tells you which.

They serve two purposes: choosing the limits of a tool like OpenCode (Choose the limits) and knowing what is normal before you report a problem. They are not a service guarantee.

How long a response takes by size

The output rate of the reasoning model is steady, about 46 tokens per second, so the time grows linearly with the tokens requested. The node aborts the request after about 300 seconds, and that cutoff is what sets the limit.

max_tokens requested	Tokens returned	Time	Result
4 000	4 000	87 s	Complete
8 000	8 000	175 s	Complete
16 000	0	303 s	504 with provider_timeout, the request is aborted

The third row is not a slow model: it is the node's cutoff. At 46 tokens per second the practical ceiling is about 13 800 response tokens, and the prefill of a large prompt also uses part of that budget. That is why you should request 8 192 at most and not the max_output_tokens that the model catalog advertises.

What a long prompt costs

Retrieval of a fact hidden in prompts of different sizes, with the fact at the start, in the middle and at the end. The three models found it in all nine combinations; what changes is the time it takes to read the prompt.

Prompt	Fact at the start	In the middle	At the end	Hits
32 492 tokens	5.9 s	4.8 s	2.6 s	3 of 3
91 292 tokens	17.7 s	14.3 s	12.8 s	3 of 3
123 692 tokens	26.6 s	26.5 s	17.7 s	3 of 3

There is no loss of accuracy in the middle part of the context, which is where it usually appears. The cost is time: each turn of a long session pays that prefill again.

Several people at once

Simultaneous requests of about 600 response tokens, on the reasoning model.

Parallel requests	Completed	Median latency	Maximum latency
1	1 of 1	2.9 s	2.9 s
4	4 of 4	2.8 s	3.9 s
8	8 of 8	3.4 s	3.7 s

Eight requests at once do not degrade latency noticeably. In a series of 25 back-to-back requests none failed, with a median of 3.2 s and a maximum of 8.8 s.

The two models, side by side

	Qwen3.8 27B (FP8)	Qwen3.6 35B A3B (FP8)
First token	0.15 s	0.11 s
Output rate	46 chunks/s	206 chunks/s
Response of about 400 words	15.4 s	3.5 s
Reasoning tokens on a simple riddle	106	560
Empty content with max_tokens: 256	No	Yes
Follows "reply only: OK"	Yes	No, it adds text

The fast one delivers tokens four times faster and is the right one for classifying, summarizing or renaming. The reasoning one spends fewer tokens thinking, follows the format and does not run out of budget, so it is the one to use as the main model of a coding tool. This is why you put the fast one in small_model and the other one in model.

How to measure it again

The figures change with each model catalog update and with the load on the installation. To repeat the measurement:

1. Request the catalog with GET /v1/models and note the context_window and max_output_tokens of each model.
2. Measure the output rate with a streaming request and a fixed max_tokens: tokens returned divided by elapsed seconds.
3. Find the node's cutoff by raising max_tokens until the response is 504 with provider_timeout.
4. For the long prompt, build a filler text with a single hidden fact and ask for it in three positions.
5. For concurrency, send N identical requests in parallel and compare the median latency against that of a single request.

Write down the date, the tool version and the model next to each number. Without that, one performance figure cannot be compared with the next.