Concept renderOn three published Claude price rows as of October 31, 2026, output tokens cost five times input tokens, and OpenAI's guide says halving output tokens may roughly halve latency. A shorter reply also keeps the radio and speaker on for less time. Control length in the prompt, use max_tokens as a backstop, and measure current on your own board.
A voice device speaks every token it pays for. A long answer costs more per call, takes longer to finish and keeps the radio and the speaker amplifier powered. This guide puts the published prices, one published latency rule and one chip datasheet into a formula you can rerun with your own numbers. It lists the length controls that exist and what each one cannot do. It contains no Duobay price and no measured result from our lab.
What does a reply cost, and how much of it is output?
The cost of one reply is the input side plus the output side. Output tokens carry the higher price on every row below. All prices are official list prices per million tokens, read on October 31, 2026. Prices change, so re-read each page before you decide.
cost_per_reply = (T_in × p_in + T_out × p_out) / 1,000,000 (dollars)
output_cost_per_1000_replies = T_out × 1,000 × p_out / 1,000,000Units: T_in and T_out are tokens, p_in and p_out are dollars per million tokens. The table shows only the output side so that the effect of reply length stays visible. The two example lengths, 150 and 40 output tokens, are placeholders for the worked example. No device produced them, and you replace them with your own logged lengths.
| Model | Input, per million tokens | Output, per million tokens | Output price divided by input price | Output cost per 1,000 replies at 150 tokens | Output cost per 1,000 replies at 40 tokens | Source |
|---|---|---|---|---|---|---|
| Claude Sonnet 5.5 | $2 | $10 | 5 | $1.50 | $0.40 | Anthropic pricing page, as of October 31, 2026 |
| Claude Haiku 5.5, prompts up to 100,000 tokens | $0.1 | $0.5 | 5 | $0.075 | $0.02 | Anthropic pricing page, as of October 31, 2026 |
| Claude Haiku 4.5 | $1 | $5 | 5 | $0.75 | $0.20 | Anthropic pricing page, as of October 31, 2026 |
| Gemini 3.5 Flash-Lite | $0.3 | $2.5 | 8.3 | $0.375 | $0.10 | Google pricing page, as of October 31, 2026 |
| Gemini 2.5 Flash | $0.3 | $2.5 | 8.3 | $0.375 | $0.10 | Google pricing page, as of October 31, 2026 |
| Gemini 3.1 Flash-Lite | $0.25 | $1.5 | 6 | $0.225 | $0.06 | Google pricing page, as of October 31, 2026 |
Computed by us from the listed prices. For Claude Sonnet 5.5 the output side is 150 × 1,000 × $10 / 1,000,000 = $1.50 against 40 × 1,000 × $10 / 1,000,000 = $0.40. The Gemini rows bill thinking tokens inside the output price, so a model that thinks before it speaks has a larger T_out than the spoken text suggests. The pricing pages list dated price changes for some models, so check the row you plan to use for an end date.
Read the table by the ratio column. When output costs five times input per token, as on the three Claude rows, shortening the reply saves more than shortening the prompt by the same number of tokens. A full per-reply figure also needs T_in, which depends on your system prompt and any history you resend. Add that term from your own logs.
Inputs, and which are yours to replace
| Variable | Meaning | Status | What to do |
|---|---|---|---|
| T_in | Input tokens per turn, including system prompt and any history you resend | Your assumption | Replace after you log real turns on a prototype and count them with the provider tokenizer. |
| T_out | Output tokens per reply, including thinking tokens where the provider bills them as output | Your assumption | The 150 and 40 in the example are placeholders. Replace with the median and 95th percentile of your own logged replies. |
| p_in, p_out | Price per million input and output tokens | Published price | Take from the table above and re-read the page on the day you decide. |
| n | Replies per device per day | Your assumption | Replace with your usage plan, then with prototype logs. |
| r | Output speed in tokens per second for your chosen model and region | Your assumption | The sources here give no figure. Measure it over the network your device will actually use. |
| t_first | Time from end of the user turn to the first output token | Your assumption | Measure it. It does not shrink when the reply gets shorter. |
| I_x | Current drawn in each state (radio receive, radio transmit, speaker amplifier on, idle) | Datasheet for the radio, your board for the rest | The radio figures in this article come from one chip datasheet. Speaker amplifier and whole-board current are not published anywhere we cite. Measure them. |
| V | Rail voltage at the point you measure | Your board | The datasheet figures below are at 3.3 V. |
| t_speak | Seconds of speech for a reply | Your assumption | Equals reply words divided by the speaking rate of your text-to-speech voice. We cite no speaking rate, so measure it on your voice and language. |
How does reply length change the wait?
OpenAI's latency guide states that generating tokens is almost always the highest latency step when using an LLM, and that as a general heuristic, cutting 50% of your output tokens may cut about 50% of your latency (OpenAI latency optimization guide, accessed 2026-10-31). This is one provider's rule of thumb with no guarantee attached, and we have not tested it on a device.
time_to_last_token ≈ t_first + T_out / r (seconds)
saving from a shorter reply ≈ (T_out_long − T_out_short) / rUnits: t_first in seconds, T_out in tokens, r in tokens per second. A shorter reply reduces only the second term. The first term, and the time to start speech synthesis, stay where they are. For a voice product the number that matters to the user is time to first audio, so a streamed design can hide part of the generation time and a design that waits for the full text cannot. We give no worked number for r, because none of the sources we cite publishes a speed for your model on your network. Measure r and t_first, then compute the saving.
What does a longer reply cost in battery?
Battery cost needs energy, which is current times voltage times time. The only published electrical figures we cite come from the Espressif ESP32-S3 datasheet. They are for one chip, and your design may use a different one. The datasheet gives the transmit and receive currents at 3.3 V and 25 °C, and the sleep currents in Tables 5-7 and 5-10 (ESP32-S3 datasheet, accessed 2026-10-31).
| State | Datasheet current | Current × 3.3 V | Source |
|---|---|---|---|
| Wi-Fi transmit, 802.11n HT20 MCS7 at 18.5 dBm (peak) | 283 mA | 0.93 W | Espressif datasheet, as of October 31, 2026 |
| Wi-Fi receive, 802.11b/g/n HT20 | 88 mA | 0.29 W | Espressif datasheet, as of October 31, 2026 |
| Light-sleep, Wi-Fi powered down (typical) | 240 µA | 0.8 mW | Espressif datasheet, as of October 31, 2026 |
| Deep-sleep, RTC memory on, RTC peripherals off (typical) | 7 µA | 0.023 mW | Espressif datasheet, as of October 31, 2026 |
E_radio_upper_bound = I × V × t (joules, with I in amps, V in volts, t in seconds)
charge_extra = I × t / 3600 (milliamp-hours, with I in milliamps, t in seconds)Worked example from the table. Each extra second with the radio in receive at 88 mA is at most 88 × 1 / 3600, about 0.024 mAh, or 0.29 W × 1 s, about 0.29 joules, at 3.3 V. The same second in transmit at the 283 mA peak is at most about 0.93 joules. Light-sleep at 240 µA is about 0.8 mW. By the datasheet figures, receive draws about 370 times and the transmit peak about 1,180 times the light-sleep current. The figures are for the chip with the radio active. They are upper bounds and say nothing about your average, because your duty cycle and your power-save mode set how much of a reply the radio is actually on.
The datasheet does not cover the speaker. Time with the amplifier on is t_speak, and the amplifier current at your volume is yours to measure. A reply twice as long needs about twice the t_speak at a fixed speaking rate, which is plain arithmetic with no measurement behind it. What it costs in milliamp-hours is unknown until you run the test below. We therefore state no battery-life improvement for shorter replies.
Which controls shorten a reply, and what does each one miss?
| Control | What the source says | Limit to plan for | Source |
|---|---|---|---|
| Prompt instruction for brevity | Tells the model to answer in a short form. OpenAI lists asking for concise output as one way to generate fewer tokens, along with few-shot examples and fine-tuning. | A prompt lowers the chance of a long answer. It gives no guarantee, so test it on your own question set. | OpenAI latency guide, accessed 2026-10-31 |
| max_tokens | A hard ceiling on generated tokens. Anthropic describes it as the absolute maximum number of tokens to generate, and says the model may stop before reaching it. | The model does not plan its sentence around the cap, so a reply can be cut off partway. Use it as a safety net against runaway length. | Anthropic Messages API reference, accessed 2026-10-31 |
| Stop sequences | OpenAI lists stop and max_tokens as ways to end generation early. | Useful when your format has a clear end marker. You need to design and test the marker. | OpenAI latency guide, accessed 2026-10-31 |
| Effort setting | Anthropic states that for Claude Opus 5, raising or lowering effort does not reliably change visible response length. | Do not treat an effort setting as a length control. State the length in the prompt. | Anthropic prompting guide, accessed 2026-10-31 |
The practical order is prompt first, backstop second. Ask for the length you want in words or sentences, and set max_tokens above that length so the cap fires only on a runaway reply.
What are the common traps?
These follow from the published prices, documentation and datasheet figures above. They are engineering reasoning about how the numbers behave. None describes an incident at any company.
- Cutting the reply with max_tokens. Anthropic says max_tokens is an absolute maximum and the model is not told to finish inside it. A reply that hits the cap ends where the cap falls. If the text goes to a speaker, the user hears a sentence stop in the middle. Keep length control in the prompt and keep the cap as the backstop.
- Choosing a model by its default style. Anthropic states that Claude Opus 5 defaults to longer user-facing replies than earlier models and that effort does not fix it. A model swap can change reply length with no change to your prompt, so re-measure tokens per reply after every model change.
- Forgetting thinking tokens. Google lists the output price as including thinking tokens for the Gemini rows above. If a model thinks before it answers, the billed output is larger than the words you speak. Count thinking in T_out and in latency.
- Expecting latency to halve exactly. OpenAI calls its 50 percent figure a general heuristic. It applies to the generation step. The time before the first token, the network and the speech synthesis start-up are separate terms in the latency sum.
- Pricing only the input side. On the three Anthropic rows, output costs five times input per token. A short prompt with a long reply is dominated by the reply.
- Using a radio peak as an average. The 283 mA transmit figure is a peak at a stated output power. Your average depends on how often the radio is on, which depends on your power-save mode and traffic. The product of current, voltage and time gives an upper bound and no battery estimate.
- Ignoring the speaker. A longer reply keeps the speaker amplifier on longer. No source cited here gives amplifier or speaker current for any product, so this cost is unknown until you measure it.
- Sizing the battery from the sleep figure. The 240 µA and 7 µA datasheet figures are for the chip alone in a stated sleep state. They exclude microphone, amplifier, codec, display and regulator losses on your board.
What should you measure on your own board?
No source we cite gives whole-device power, speaker current, speech rate or end-to-end latency for your product. We have not measured these for you, and no result appears in this article. Fix every pass line before you run the test, because a threshold chosen after you see the result tends to land just under the result.
| What to measure | How | How to set the pass line |
|---|---|---|
| Tokens per reply | Log every reply from prototype sessions. Count output tokens with the provider tokenizer, including thinking tokens when billed. Report the median and 95th percentile per use case. | Set the maximum acceptable 95th percentile from your cost model and from the longest reply a user will sit through. Write it down before you run the test. |
| Spoken duration per reply | Play each logged reply through your real text-to-speech path and time the audio from first sample to last sample. Divide words by seconds to get the speaking rate. | Set a maximum seconds of speech per answer from your use case, for example a user glancing away from a screen. Choose it before you run. |
| Time to first audio and time to last audio | Toggle a spare GPIO at four events: request sent, first token received, first audio sample out, last audio sample out. Capture with a logic analyzer. Run the same question set with a long style and a short style, at least 30 questions each, and report median and 95th percentile of each interval. | Set a pass line on time to first audio from your product requirement. Compare the difference between styles with the OpenAI heuristic and note any gap. |
| Whole-device current per reply | Put a current meter or power analyzer on the battery rail. Record the current trace while the device handles a fixed question set with long and short replies. Integrate current over each reply window to get charge per reply in mAh. Repeat each case at least 10 times and report mean and spread. | Convert charge per reply into battery hours at your planned replies per day. Compare with your runtime promise, and set the pass line from that promise. |
| Speaker amplifier current | Measure amplifier supply current at your real listening volume with speech material instead of a test tone, and again at maximum volume. | Set the pass line from your battery budget. The published sources give no amplifier figure. |
| Radio duty cycle | Trace radio current during a reply, with your real power-save mode, for a streamed reply and for a reply delivered in one piece. Record the share of time in transmit, receive and sleep. | Compare the measured average with the datasheet upper bound in this article and keep the measured value. |
| Truncation rate | With max_tokens set to your chosen backstop, count replies that end because they hit the cap, out of a set of at least 200 logged questions. | Set the acceptable rate in advance. Any rate above zero needs a decision on what the device says when a reply is cut. |
| Answer quality at short length | Score short-style and long-style answers to the same questions with a rubric written before scoring. Include hard questions. | Set the minimum score and the largest acceptable gap to the long style in advance. |
What should you ask before you commit?
Take this list to your firmware team, your model vendor and any team building the voice path for you, including us.
- What is our target reply length in words and in spoken seconds, and where did it come from?
- Which exact model and tier does the firmware call, and on what date was the price read?
- Is the length controlled in the prompt, and is max_tokens only the backstop?
- What does the device say or do when a reply is cut at the cap?
- Do we bill thinking tokens, and are they counted in our output budget and our latency?
- What are the median and 95th percentile reply lengths in our logs for each use case?
- Did we re-measure reply length after the last model change?
- Who measured whole-device current per reply, on which board revision, at what volume?
- Which numbers in our power budget come from a datasheet, and which from our own board?
- How does a longer reply change the battery size and the amplifier choice in the bill of materials?
Questions about reply length, cost and power
Does a shorter reply always cut the bill in half?
Only the output part, and only if your output is what you shorten. The cost of a reply is input tokens times the input price plus output tokens times the output price. On the Anthropic rows output costs five times input per token, so output usually dominates a short question with a long answer. Run the formula with your own T_in and T_out. Prices as of October 31, 2026 on the Anthropic pricing page.
Will a shorter reply halve my latency?
OpenAI's guide gives a general heuristic that cutting 50% of output tokens may cut about 50% of latency, and calls generating tokens almost always the highest latency step (OpenAI latency guide, accessed 2026-10-31). It is a heuristic for the generation step. Measure time to first audio and time to last audio on your own device.
Can I just set max_tokens low?
You can, as a backstop. Anthropic describes max_tokens as the absolute maximum number of tokens to generate and says the model may stop before reaching it (Messages API reference). The cap does not make the model finish its sentence inside the limit, so a reply can end mid-thought. Put the length request in the prompt and test the truncation rate.
How much battery will shorter replies save?
We cannot say, and no source we cite gives a whole-device figure. The datasheet numbers in this article are chip-level upper bounds. The saving depends on your radio duty cycle, speaker amplifier, text-to-speech path and battery. Measure charge per reply on your own board with a long and a short style.
Can Duobay tell me the cost and power budget for my device?
We do not publish prices. A Gate 0 Feasibility study covers architecture, a costed bill of materials and the certification path. Power measurements need a prototype, which comes at a later gate. Tell us about your device and we will explain how it works.
If you want to talk through architecture and a costed bill of materials for your voice device, tell us about your device. For the product category this applies to, see audio and voice hardware development.
Sources
All pages accessed October 31, 2026. Prices, model lists and datasheet revisions change, so re-read them before you decide.
- Anthropic, Claude API pricing: https://platform.claude.com/docs/en/about-claude/pricing (accessed 2026-10-31)
- Anthropic, Messages API reference: https://platform.claude.com/docs/en/api/messages (accessed 2026-10-31)
- Anthropic, Prompting best practices: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices (accessed 2026-10-31)
- Google, Gemini API pricing: https://ai.google.dev/gemini-api/docs/pricing (accessed 2026-10-31)
- OpenAI, Latency optimization guide: https://developers.openai.com/api/docs/guides/latency-optimization.md (accessed 2026-10-31)
- Espressif, ESP32-S3 datasheet: https://documentation.espressif.com/esp32-s3_datasheet_en.pdf (accessed 2026-10-31)
Planning a voice or audio device? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →