AWS adds usage metering for voice streams: 12 minutes of audio equals 720 units

A voice agent's conversation lasts twenty minutes, but the customer spends part of that time staying silent, listening to a response or looking for an order number. What exactly ends up on the model bill? AWS has added a mechanism to SageMaker AI that lets streaming model providers report actual usage to AWS Marketplace during a session. If a product counts seconds of processed audio, 12 minutes of that audio translates into 720 billable units.

This is a useful change for teams selling or deploying speech recognition and synthesis through Marketplace. It allows software charges to track consumption. SageMaker infrastructure costs remain a separate line item: an active endpoint continues to cost money.

Why a single server response is not enough

With a conventional API, things are relatively straightforward: send a request, receive a result, and the server reports usage in a response header. By that point, the work is complete and the usage is known.

In a voice interface, the connection stays open longer. The client continuously sends audio and receives a transcript; a session may last half a minute or half an hour. A header sent when the connection is established cannot provide regular usage updates. And hourly software pricing can include periods when the model is available but processing nothing.

AWS addressed this with a second WebSocket connection between SageMaker and the model server. The first carries input data and results; the second carries small billing messages. A shared request identifier links both connections to the same conversation.

The provider defines what a billable unit means. Messages use the name inference.count, but that does not require each request to count as a separate unit: units could be seconds of audio, for example. The counting rules and price must match the Marketplace offering.

How to meter usage during a conversation

Imagine a call transcription service that charges per second of audio. The server accumulates another 30 seconds of processing and sends a message reporting 30 units used. It then processes another 30 seconds and reports another 30 units. Each record contains the increase since the previous report, so repeatedly sending a cumulative total would overstate usage.

AWS recommends reporting usage incrementally and sending the final record immediately after the session ends. This reduces the amount of processed audio left unmetered if the connection drops unexpectedly. An open connection does not, by itself, mean billable audio: that depends on the rules of the specific product.

The channel has limits: one message per second per connection, a maximum of 512 bytes, and exactly one record in each text frame. Multiple accumulated units can be sent in a single record. ClientToken provides protection against duplicates: a duplicate with the same token is discarded within the same connection.

The first partner is Deepgram, which uses the mechanism to bill for speech recognition and synthesis. In its integration, the server calculates usage automatically; the client application needs no additional metering configuration.

Where metering can fail

The main choice for a provider is what happens when the billing channel fails. By default, processing continues even if that channel fails to open or disconnects. The conversation continues, but usage reporting stops. Providers can make the channel mandatory: losing it then stops processing.

That decision needs to reflect the product. For a contact center, interrupting a conversation may cost more than a few unmetered seconds. A mandatory channel still does not guarantee accurate charges: malformed messages can still be discarded. Delivery over TCP also does not confirm that usage has made it onto the bill.

Before release, AWS recommends testing with a known volume: send 12 minutes of metered audio, obtain a total of 720 units, and reconcile server records against seller reports and buyer charges. Test disconnections and malformed messages separately. The practical takeaway for buyers is to establish how a unit is defined and calculate infrastructure costs separately. For providers, it is to make charge reconciliation part of release preparation.