Streamed Calls vs Buffered Calls on the Aggregator: Does stream:true Change What You're Billed Under the 1.3x Rule?

The short answer

stream: true does not change what you are billed. The billable quantity is the tokens the model processes and produces, priced at the provider's official rate and multiplied by 1.3. Streaming only changes when those tokens reach your client — one event at a time instead of a single response body. The USDC deduction reflects the same token counts either way.

How token accounting works

Billing is driven by usage, not by transport. Two components matter:

• Input tokens — the prompt, system instructions, tool definitions, and any conversation history you send.
• Output tokens — everything the model generates, including text delivered in stream events.

In a buffered call, you typically receive a usage object alongside the final content. In a streamed call, usage is usually reported in a terminal event (often the last chunk or a dedicated usage event). Providers that report usage in streams report the same totals as the buffered path for the same generation.

A practical consequence: if you generate the same content with the same prompt under either mode, the token totals are the same, so the USD-equivalent cost is the same, and the multiplier applies identically.

What actually changes when you stream

Streaming alters the delivery shape, not the meter:

• Latency to first token drops, because you receive partial output as it is produced.
• Response framing changes from one JSON object to a sequence of server-sent events, each carrying a delta.
• Client complexity rises: you must accumulate deltas, handle termination events, and capture usage from the final event.
• Failure behavior differs: a connection drop mid-stream may leave you with partial output, but tokens already generated are still part of the request's usage.

None of these are billing levers by themselves.

Where cost actually moves

Because the multiplier is fixed, cost control comes from reducing token counts and avoiding wasted generations:

• Prompts: trim system messages, avoid re-sending large histories you do not need, and keep tool schemas lean.
• Outputs: set an appropriate max_tokens, and stop generation when you have what you need. A stream lets you cancel earlier in wall-clock time, but any tokens already produced are still counted.
• Retries: a failed or abandoned request that already generated output is not free. Streaming makes early cancellation easier, which can reduce unnecessary output tokens in practice — that is an operational benefit, not a change in the billing rule.
• Model choice: different models have different official prices; the 1.3 multiplier applies to whichever you pick.

Buffered vs streamed: when to prefer each

Prefer buffered calls when:

• You need the full response before doing anything (parsing structured JSON, validating a schema, running a downstream step).
• The output is short and first-token latency is not user-visible.
• You want simpler error handling and a single usage object.
• You are batching background jobs where throughput matters more than perceived latency.

Prefer streamed calls when:

• A human is waiting on the output and perceived responsiveness matters (chat UIs, long-form generation, code assistants).
• Outputs can be long and you may want to cancel once sufficient content arrives.
• You want to surface partial progress or begin rendering before completion.

Deduction behavior in practice

Your balance is held in USDC on Base. Each request is priced from the provider's official rate for the tokens used, times 1.3, and deducted in USDC. The delivery mode does not enter that calculation. What you should watch instead:

• Usage reported in streams: always read the terminal usage event; do not estimate from delta counts.
• Cancelled streams: treat them as billable for tokens already generated.
• Retry loops: each attempt is a separate billable request.
• Contributor credits: if you contribute keys, credits accrue at official price × 1.1 (or × 1.2 for premium) in USDC, independent of how callers stream.

A simple decision rule

Ask one question: does anything downstream need the complete response before it can proceed?

• If yes, buffer.
• If no, and a user or UI benefits from incremental output, stream.

Then optimize cost where it actually lives — prompt size, output length, model selection, and avoiding redundant requests — rather than by switching delivery modes.