Alibaba entries: one cache_read field for two published rates, a third pricing scope, and some derived-looking figures

Three things I ran into while auditing the Alibaba entries against Alibaba's own published pricing. They're schema/sourcing questions rather than data fixes, so I'm raising them here instead of sending PRs that would prejudge them. (Data fix that was unambiguous: #5235.)

1. One cache_read field, two published rates

Alibaba bills two different kinds of cache hit at different rates, as separate line items on the pricing page:

	qwen-plus (Global scope)	multiplier
Explicit Cache Read (cache_control)	0.012	10% of input
Input (Implicit Cache)	0.023	20% of input

Confirmed in the context cache guide: explicit hits bill at 10% of the standard input price, implicit prefix hits at 20%.

The problem for a consumer is that the API reports both kinds in the same field. On the OpenAI-compatible surface it's usage.prompt_tokens_details.cached_tokens, and I've measured the same on the native surface — an explicit-marker hit shows up in cached_tokens, not somewhere distinct. So a consumer holding one cache_read number cannot tell which rate applied, and is wrong by 2× in one direction or the other on every cached turn.

Current entries here all use the explicit rate (qwen3.7-flash, qwen3.6-plus, qwen3.7-plus are each exactly 10% of their input), which is a reasonable convention — but it's undocumented, and it means implicit hits are under-priced by half. Would a cache_read_implicit (or similar) be in scope? Happy to do the data work across the Alibaba entries if there's a field to put it in.

2. Alibaba's price axis is a scope, not a region — and there may be a third one

The pricing page tabs don't map one-to-one onto the two provider keys here. For qwen3.7-flash:

tab	scope label	≤32k input	≤32k output
Singapore	International	0.03	0.13
Germany (Frankfurt)	Global	0.028	0.11
China (Beijing)	—	0.028	0.11

And for qwen-plus, Frankfurt and US (Virginia) both show Scope: Global with figures identical to Beijing.

So "Global" is a price list shared by Frankfurt, US Virginia and Beijing, while "International" (Singapore) is a different, higher one. This repo has alibaba and alibaba-cn; neither is the Global list. A deployment against Frankfurt priced from alibaba would be over-billed — for qwen3.7-flash that's +7% at the base tier and +21% at the top tier, since the gap widens with context.

Is a third key (or a scope dimension) something you'd consider? I'm not proposing a shape — just flagging that the two-key model can't express what Alibaba publishes.

3. alibaba-cn/qwen3.7-flash figures match no published tab, and look derived

input = 0.02962   output = 0.1185   cache_read = 0.002962   cache_write = 0.03703

Alibaba publishes, for that model: Beijing/Frankfurt input 0.028, output 0.11, Explicit Cache Read 0.003, Explicit Cache Creation 0.034; Singapore input 0.03, output 0.13, read 0.003, creation 0.038.

The entry sits ~6–8% above the Beijing figures, consistently across all four fields and all three tiers. And cache_read is exactly 10% of its input while cache_write is exactly 125% — clean multiples, where Alibaba's own published numbers are 0.003 (10.7%) and 0.034 (121%). That reads like the input was converted from a CNY list and the cache fields then derived from it by multiplier, rather than transcribed.

Not a big absolute error, and I may be missing context on where those numbers come from — but it's the kind of thing that's invisible until someone diffs against the vendor page, so it seemed worth reporting.

4. qwen-plus is missing its context tiers

Alibaba publishes it in three tiers (<= 128k, 128k–256k, 256k–1M) and the entry carries only the first, flat, on a model whose limit.context is 1,000,000 — so a long-context turn prices at the cheapest tier. (qwen3.7-flash does carry its tiers, so this looks like an omission rather than a policy.)

I have the upper-tier figures from a rendered read of the page but they contain an internal inconsistency I couldn't reconcile with confidence, so I've deliberately not sent them as a PR. If it's useful I'll re-source them carefully and open one.

---

Context: I maintain a Rust workspace that vendors a filtered snapshot of this catalog for LLM cost accounting, so these all showed up as pricing errors on our side first. Glad to do the legwork on any of them — mostly need to know which shapes you'd accept.

Start by reviewing the current Alibaba model entries and comparing them with the linked Alibaba pricing sources. Determine which schema can represent cache rates, pricing scopes, derived values, and qwen-plus context tiers without assuming an unresolved shape. Done means the accepted representation and sourcing policy are clear enough for accurate Alibaba pricing data.