One allotment, many models, a published conversion between them. Every performance number here carries the date it was measured, and the ones that have not been measured say so.
Live status per model on /status
Send the slug as the model field. It is the same string on every surface: activity rows, response headers, and your config file.
DeepSeek V4 Flash · DeepSeek
DeepSeek V4 Pro · DeepSeek
GLM-5.2 · Z.ai
Kimi K3 · Moonshot
Models cost materially different amounts to serve, so one allotment is converted into each of them at a published rate. A cheaper model makes your allotment go further; that is a real benefit, not a footnote.
WT = (in × W_IN + cached × W_CACHED + out × W_OUT) × M_model| Model | M | W_CACHED | W_OUT | 1M WT buys, in output tokens |
|---|---|---|---|---|
| deepseek-v4-flash | ×0.20 | ×0.02 | ×2 | 2,500,000 |
| deepseek-v4-pro | ×0.62 | ×0.008333 | ×2 | 804,597 |
| glm-5.2 · reference | ×1.0 | ×0.185714 | ×3.142857 | 318,182 |
| kimi-k3 | ×2.1 | ×0.1 | ×5 | 93,333 |
The last column is pure output, which no real workload is. It is there as a common yardstick between rows, not as a quota estimate. W_IN is ×1.0 on every model by definition; the multiplier carries the difference between them.
A worked request on glm-5.2. Your own requests show this same arithmetic, with your real numbers, in the activity detail.
12,400 in, of which 3,180 were cached
9,220 uncached in × 1.0 = 9,220.00
3,180 cached × 0.185714 = 590.57
8,920 out × 3.142857 = 28,034.28
────────────────────────────────────────────
subtotal = 37,844.85
× 1.0 (glm-5.2) = 37,845 WTCached tokens are counted as part of the input, not on top of it, so the input line bills the uncached remainder: the cache discount is real, not a discount on a number we inflated first. Rounding to whole weighted tokens happens once, on the final line; that is why the lines above carry decimals.