Pricing and budget · 2026-09-22
Lowering repeated system-instruction cost on Ling 3.0 Flash with prompt cache
Covers that inclusionai/ling-3.0-flash's cache-read price through the LLMTR gateway is one fifth of its input price, and the cases where that difference still translates into meaningful savings on an already low-priced model.
Three existing articles were on the self-hosting axis; this one looks at the LLMTR API
The three previous articles about this model focused on running Ling 3.0 Flash on your own infrastructure: local trials with Ollama/MLX, production-scale deployment with vLLM, and reasoning_effort/tool-calling behavior mechanics. This article looks at a different question: if you're calling the model directly through the LLMTR gateway rather than your own infrastructure, how does the pricing card's cache-read line affect total cost?
The model is a 124-billion-parameter Mixture-of-Experts architecture activating roughly 5.1 billion parameters per token; through LLMTR, input is billed at $0.06 per million tokens and output at $0.18. That's one of the lowest unit prices in the catalog — which might raise the question 'who cares about cache when it's already this cheap' — the next section answers that with numbers.
Cache reads cost one fifth of the input price
The pricing card shows input tokens served from cache are billed at $0.012 per million — exactly one fifth of the normal input price ($0.06). That ratio means that even though the model itself is already cheap, a high-volume flow carrying a repeated system instruction or a fixed context prefix still sees meaningful savings.
For example, in an agent flow sending a fixed 2,000-token system instruction on every request, once that prefix is served from cache, the per-request cost for that portion drops from about $0.00012 to $0.000024; that difference looks small per request, but in a product sending hundreds of thousands of requests a day it leaves a measurable dent in the total bill.
- Cache-read price: $0.012 per million tokens (one fifth of normal input).
- The cache kicks in when a fixed system instruction or document prefix is resent repeatedly.
- Even on an already low-priced model, this ratio adds up meaningfully at high volume.
When the cache doesn't kick in
The cache requires a prefix that overlaps with a previous request; if every request's content differs from start to end (a completely different user question and a different context document each time, for example), there's no repetition to benefit from, and the entire input is billed at the normal price. In that case, the cache's price advantage stays theoretical and delivers no practical gain.
The model's reasoning behavior, on by default, is a separate cost line too; reasoning tokens are billed as output and fall outside the cache's scope. On requests needing a short, direct answer, sending `reasoning_effort: "none"` (the only level with effect on this model) lowers total cost independently of your cache strategy.
Frequently asked questions
Does the cache-read price also apply to output tokens?
No, the pricing card's cache-read line applies only to the repeated prefix on the input side; output tokens (including reasoning) are always billed at the normal output price.
Is it worth building a cache strategy when this model is already so cheap?
For low-volume use, the difference can be negligible; but in a production flow resending a fixed instruction/document prefix at high volume, the one-fifth ratio turns into a measurable saving on the total bill.