AWS adds usage-based software billing for live speech AI on SageMaker
Deepgram is the launch partner. Providers define what counts as usage, while customers still pay separately for the infrastructure hosting their models.
Loading page…
Deepgram is the launch partner. Providers define what counts as usage, while customers still pay separately for the infrastructure hosting their models.
Announced November 11, 2026, SageMaker AI’s new metering path lets AWS Marketplace speech vendors report consumption through a second WebSocket while a live inference stream is running. This supports usage-priced speech products without waiting for a session to end. Deepgram is the launch partner for speech-to-text and text-to-speech. The software charge is separate from SageMaker endpoint infrastructure costs, and Marketplace labels the unit price “per request” even when the metered unit represents audio time.
Each metering message contains one usage record; the channel allows one message per second and caps messages at 512 bytes.
By default, inference continues if the metering connection fails, though providers can instead require the live stream to stop.
Providers define what counts as usage: 12 minutes of billable audio could equal 720 units, but session duration alone does not establish billable audio.
AWS is giving speech-model providers a way to bill for usage while a live conversation is still running. Announced November 11, 2026, the new Amazon SageMaker AI metering feature lets AWS Marketplace sellers report consumption during two-way streaming sessions. Deepgram is the launch partner, with speech-to-text and text-to-speech billing.
The change addresses a mismatch between conventional request billing and a running audio session. For ordinary request-response inference—using a model to produce a result—providers can put a billable quantity in the response’s HTTP header. A live stream keeps accumulating usage, and its final total is unknown until it ends. That header cannot deliver periodic usage updates throughout the conversation.
SageMaker’s solution is a second WebSocket connection, a companion channel dedicated to metering rather than model inputs and outputs. Model servers opt in through a response header. SageMaker then opens the companion connection, and both channels carry the same request identifier so the provider can match usage records to the right session.
Providers send usage records as JSON, a structured text format, as consumption builds. AWS recommends incremental reporting rather than waiting for the end, reducing unreported usage if a session breaks unexpectedly. Each message contains one record; the channel allows one message per second, with a maximum size of 512 bytes.
The billing field is named inference.count, but that does not mean every request counts as one unit. The provider defines the consumption being measured, and the Marketplace offer maps that unit to a price. For a product charging by audio second, 12 minutes of metered audio would be reported as 720 units.
Keeping a connection open for 12 minutes does not, by itself, establish 12 minutes of billable audio. The provider’s counting rules decide that. Buyers also face a labeling wrinkle: Marketplace displays the unit price as “per request,” even when the underlying unit represents something else, such as a second of audio.
This changes the software bill, not the entire cost of running the model. SageMaker endpoint infrastructure charges remain separate and continue while the endpoint—the hosted service running the model—is provisioned. Unlike hourly software pricing, which can charge through quiet periods, the new software metering follows reported consumption.
Customers receive the software charges through their AWS bill rather than managing a separate billing relationship with the model provider. Marketplace private offers can support negotiated per-unit rates or fixed-price contracts.
The two-channel design creates a choice for providers. By default, inference continues if the metering connection cannot open or drops mid-session. Providers can instead require the data stream to stop when the metering channel becomes unavailable. That prioritizes metering continuity over keeping the live interaction running.
Neither setting guarantees that every submitted record becomes a charge. Malformed records can still be dropped while the metadata connection stays open. AWS’s billing validation instructions therefore call for checking the full path from model-server records to seller reports and buyer charges before release:
Loading discussion...
Join the conversation
Explain whether uninterrupted service or reliable usage tracking should take priority.
Be the first to share a perspective or an experience.
Reader comments
Newest comments first. Replies stay oldest first.