Billing

Usage counts the text you send for synthesis as written, including spaces, punctuation and any tags in it, such as steering, pause or language tags. Most characters count as one; emoji and other characters outside the Basic Multilingual Plane count as two (UTF-16 code units). A voice design prompt sent with a synthesis request counts once per request.

Not counted:

• Conversation context (synthesisContext).
• Input that produces no audio, such as punctuation alone.

On the WebSocket API, text is counted when its synthesis starts, which happens as soon as it is flushed or the context is closed. closeContext synthesizes and counts any text still buffered. Assume everything you send is counted: the window between sending text and the start of its synthesis is very short.

Examples:

• Hello, world! counts as 13 characters: the letters, the comma, the space and the exclamation mark.
• [whisper] Hello, world! counts as 23. The steering tag and the space after it are counted even though they are not spoken.
• Thanks 😊 counts as 9: six letters, a space and two for the emoji. はじめまして！ counts as 7, one per character.
• A voice agent that puts a 130-character instruction in front of every 120-character sentence counts 250 characters per sentence, so the instruction is more than half of its usage. In a WebSocket context a tag stays in force until you change it, so send it once per context rather than once per sentence.
• A 200-character voice design prompt sent with a 500-character request counts as 700. Sending the same prompt with the next request counts it again.
• Audio you do not play is still counted. If your app stops playback halfway through a reply, the whole reply was synthesized and counted.
• You send three sentences to a WebSocket context and disconnect while the second is being synthesized. All three are normally counted, because synthesis of the third starts as soon as it is flushed. Do not rely on disconnecting to avoid a charge.

Usage counts the audio you send, per second, from the first chunk to the last, and each stream is rounded up to the next whole second. A sync or async request counts the full length of the audio track. Stereo audio is mixed to mono first, so a five-minute stereo file counts as five minutes.

Counted:

• A file or stream that produces an empty transcript.
• A stream that disconnects or fails, for the audio sent before it ended.
• Speaker diarization and Voice Profile, as separate per-second add-ons on the audio they analyze, when you enable them. They are counted even when the add-on returns no result.
• Third-party models count the duration the provider reports. groq/whisper-large-v3 has a ten-second minimum per request.

Not counted:

• Time the connection is open with no audio sent.
• Audio sent after you close the stream.
• A stream that sends no audio.
• A sync request that fails.
• Word timestamps.

Examples:

• One hundred streams of 2.3 seconds each round up to 3 seconds apiece, so they count as 300 seconds, not 230.
• A sixty-second stream with speaker diarization enabled counts as 60 seconds of STT plus 60 seconds of the diarization add-on.
• A stream that drops at 45 seconds counts as 45 seconds, and you keep the transcripts produced up to that point.

Check usage.transcribedAudioMs and usage.modelId in a sync response, or in the final usage message on a stream, to see what was counted. The stream message reports milliseconds before rounding, so the billed amount can be up to one second higher per stream. If the model you requested was remapped to a newer one, modelId names the model billed.

Duration is measured on the audio you send rather than on detected speech, so a stream with an open microphone is counted for as long as audio keeps arriving.

Usage counts tokens as the model provider reports them, in four parts: input, output, cached input read and cached input write. Providers tokenize the same text differently, so counts are not comparable across models.

Input is everything in the request, on every call: the system prompt, all messages, tool definitions, tool results and any images. Chat completions are stateless, so the history you send again each turn is counted again each turn. Output is everything the model generates, including reasoning tokens, whether or not the reasoning text is returned to you.

Counted:

• A response the model refuses on safety grounds, for the input it processed.
• Each search step in a web search loop, plus the search engine fee.
• Each model in a fallback chain that generated output, at that model's rate.
• A bring-your-own-key request whose key the provider rejects. Inworld retries it on its own key and counts it as Inworld usage.
• Moderation requests, as input and output tokens on the moderation model.

Not counted:

• A request the provider rejects before generating, such as a rate limit, an invalid request or a provider outage.
• The count tokens endpoint.

Cache reads and writes appear on their own lines when the provider reports them. Explicit caching is opt-in with cache_control; some providers cache automatically.

Examples:

• A chat has a 2,000-token system prompt, and each exchange adds about 400 tokens of history. Turn ten sends the prompt plus nine earlier exchanges, about 5,600 input tokens, not only the new message.
• A reasoning model answers a 50-token question with 300 visible tokens after 1,200 tokens of reasoning. Output counts as 1,500 tokens.
• A request lists two models and the first fails before generating. The second serves and is billed at its rate, and model in the response names it.
• A 10,000-token prompt with explicit caching counts a 10,000-token cache write on the first call and 10,000 cached-read tokens on later calls, at the cheaper cached rate.

Check usage in the response to see what was counted: prompt_tokens, completion_tokens, prompt_tokens_details.cached_tokens, prompt_tokens_details.cache_write_tokens and completion_tokens_details.reasoning_tokens. In streaming, usage arrives in a chunk near the end whenever the provider reports it. model names the model that served the request.

A streamed response you cancel is counted for the tokens generated before the cancel. If the connection drops before the provider reports a count, the count is estimated from the text.

A session counts the STT, LLM and TTS it uses, each under the rules above. STT inside a session is billed as its own STT line item, on inworld/inworld-stt-1 unless you choose another model, and the agent's speech is billed as TTS.

STT. Audio you send is counted per second for as long as it keeps arriving. Each STT stream is rounded up to the whole second on its own. A session normally has one stream, and changing STT settings mid-session starts a new one.

LLM. Every agent response is one chat request that carries your system prompt, your tool definitions and the recent conversation, up to the last 100 items by default. Input tokens grow as the conversation does. Explicit prompt caching of the system prompt and tools is opt-in; providers that cache implicitly do so automatically.

TTS. The model's text is split into segments, one sentence each by default (see segmenter strategies). Each segment is sent to TTS as its own request and is counted when its synthesis starts. An interruption stops segments that have not been sent to TTS yet. Segments already sent are synthesized and counted even if the user never hears them. A steering tag such as [cheerful] is repeated on every segment by default and counted each time. Set steering_handling to emit_once to send it once per response.

Counted:

• Agent speech generated but cut off by an interruption.
• The system prompt, tool definitions and history on every turn.
• Optional features that make their own LLM or TTS calls when they run: memory summarization, responsiveness fillers and back-channel responses. Each counts only when it fires. All are off by default.

Not counted:

• Turn detection.
• Time with no audio sent, such as a muted microphone.
• Segments not yet sent to TTS when an interruption arrived.

Examples:

• The agent's answer is split into twelve segments totalling 1,500 characters with the tag [cheerful]. That counts 1,500 characters plus twelve copies of the tag. With emit_once it counts 1,500 plus one.
• The user interrupts the agent partway through an answer. Segments already sent to TTS are counted, even after the interruption. Only segments still waiting in the session are not sent and not counted.
• A twenty-turn conversation with a 1,500-token system prompt sends that prompt on every turn, 30,000 input tokens across the session before counting the history, which grows every turn.

Every response.done event carries a usage block. Treat it as an estimate. An interrupted response shows zero LLM tokens but is counted for what was generated. tts.characters leaves out repeated steering tags, stt.audio_seconds is not rounded, and calls from optional features are not included. The Usage page in the Portal is the record you are billed on.

STT in a session counts the audio you send rather than detected speech, so an open microphone is counted for as long as audio flows. Mute or stop sending audio when nobody is speaking.