Suspected incorrect metering and pricing for FW-Kimi-K3 Data Zone Standard — Billing SR #2608160050000546

I need a technical investigation of the metering for my FW-Kimi-K3 Data Zone Standard deployment in Microsoft Foundry.

I already have a Billing Support case open: SR #2608160050000546. Billing Support advised that validating token classification, cached-input detection, meter mapping, and effective unit prices requires investigation by the Microsoft Foundry technical team.

For August 15, 2026, Foundry Monitor reports approximately:

• Input tokens: 6.19M

Output tokens: 73.99K

Total tokens: 6.26M

Requests: 181

Azure Sponsorship usage shows:

Model 15 Inp DZ Tokens: $55.70

Model 14 Inp glbl Tokens: $6.18

Model 12 Inp glbl Tokens: $0.74

Total: $62.62

These charges correspond almost exactly to a flat rate of $10 per 1M tokens:

$55.70 ≈ 5.570M tokens × $10/M

$6.18 ≈ 0.618M tokens × $10/M

$0.74 ≈ 0.074M tokens × $10/M

The combined quantity is approximately 6.262M tokens, which closely matches the 6.26M total tokens reported by Foundry Monitor.

This appears inconsistent with FW-Kimi-K3 pricing, which differentiates between input, cached input, and output tokens.

Could you please confirm:

What Model 12, Model 14, and Model 15 represent.

The effective unit price applied to each meter.

Whether input, cached-input, and output tokens are being mapped to the correct meters.

Whether cached input is being detected and billed correctly.

Whether my deployment is being incorrectly billed at approximately $10/M across all token types.

The deployment itself is working correctly. The issue is specifically the metering and pricing configuration.

Please escalate this to the Microsoft Foundry service team if service-level telemetry is required, and coordinate the findings with Billing Support under SR #2608160050000546 so that any incorrect charges can be recalculated and credited.

I can provide screenshots from Foundry Monitor and Azure Sponsorship Usage.Suspected incorrect metering and pricing for FW-Kimi-K3 Data Zone Standard — Billing SR #2608160050000546

I need a technical investigation of the metering for my FW-Kimi-K3 Data Zone Standard deployment in Microsoft Foundry.

I already have a Billing Support case open: SR #2608160050000546. Billing Support advised that validating token classification, cached-input detection, meter mapping, and effective unit prices requires investigation by the Microsoft Foundry technical team.

For August 15, 2026, Foundry Monitor reports approximately:

Input tokens: 6.19M

Output tokens: 73.99K

Total tokens: 6.26M

Requests: 181

Azure Sponsorship usage shows:

Model 15 Inp DZ Tokens: $55.70

Model 14 Inp glbl Tokens: $6.18

Model 12 Inp glbl Tokens: $0.74

Total: $62.62

These charges correspond almost exactly to a flat rate of $10 per 1M tokens:

$55.70 ≈ 5.570M tokens × $10/M

$6.18 ≈ 0.618M tokens × $10/M

$0.74 ≈ 0.074M tokens × $10/M

The combined quantity is approximately 6.262M tokens, which closely matches the 6.26M total tokens reported by Foundry Monitor.

This appears inconsistent with FW-Kimi-K3 pricing, which differentiates between input, cached input, and output tokens.

Could you please confirm:

What Model 12, Model 14, and Model 15 represent.

The effective unit price applied to each meter.

Whether input, cached-input, and output tokens are being mapped to the correct meters.

Whether cached input is being detected and billed correctly.

Whether my deployment is being incorrectly billed at approximately $10/M across all token types.

The deployment itself is working correctly. The issue is specifically the metering and pricing configuration.

Please escalate this to the Microsoft Foundry service team if service-level telemetry is required, and coordinate the findings with Billing Support under SR #2608160050000546 so that any incorrect charges can be recalculated and credited.

I can provide screenshots from Foundry Monitor and Azure Sponsorship Usage.