Reducing CPU use and battery drain¶

Dictation feels instant, and that hides the cost. A decode that takes one second of your time can spend five seconds of CPU, because the work is spread across cores. On mains power that is the right trade. On battery it is the thing draining it.

What it actually costs¶

Measured with time.process_time() around the decode itself — this is CPU seconds, not wall-clock:

Model choice is the biggest lever. Moving from small.en to base.en roughly halves the CPU cost of every utterance. See choosing a model for what that costs in accuracy.

[stt]
model = "base.en"   # or tiny.en on a small battery

Capping the cores: [stt] cpu_threads¶

By default the decoder uses whatever ctranslate2 chooses, which is effectively all of them. [stt] cpu_threads caps it:

[stt]
cpu_threads = 2   # 0 (default) leaves it to the library

Measured on base.en, three runs per setting, same 11-second clip:

Read this table honestly. Capping at 4 on a 20-core machine changed nothing measurable — the library was not using 20 cores' worth in the first place, so the "limit the threads" advice you will find for other Whisper tools does not automatically apply here. The real trade starts below that: 2 buys about 17 % less CPU for about 35 % more latency, and 1 about 26 % less for roughly double the latency.

Whether that is worth it is a judgement about your own tolerance for waiting. It is a smaller lever than the model, and this page would be selling you something if it pretended otherwise.

Things that cost nothing when idle¶

YazSes is event-driven: between bursts it holds the model in memory and does no work. There is no background transcription and no polling of your microphone. The idle cost is the resident model, which is the "Peak RSS" column above.

Two components do poll, both cheaply and both switchable:

The tray polls faster (about every 0.15 s) while you are recording, so the colour tracks a short hold. That is bounded by how long you hold the key.

Features worth turning off on battery¶

Each of these adds work per utterance. All are off by default unless noted — check with yazses features:

• Streaming ([streaming] enabled) decodes overlapping windows during the hold, so it does substantially more decoding than one pass at the end. It buys perceived latency; on battery it is the first thing to turn off.
• LLM cleanup ([filters.disfluency] llm_enabled) runs a second model over every dictation.
• Gaze ([gaze] enabled) runs a camera and a face-landmark model during each hold.
• Cocktail Filter ([cocktail] enabled) embeds every 0.5 s window.

yazses features            # what is on, and its recommendation tier
yazses features disable streaming
yazses restart

Measuring it on your own machine¶

Do not take this page's numbers for your hardware:

yazses status     # p50/p95 decode latency per model, from your own dictation

That is wall-clock, which is what you feel. For CPU seconds, the script that produced the tables above is a dozen lines around time.process_time() — see benchmarks for the method.

What is not measured here¶

• Actual battery drain in watt-hours. CPU seconds are a proxy. Turning them into battery life depends on your CPU's power curve, and nothing on this page measured a battery.
• GPU. [stt] device = "cuda" exists and is untested for power.
• Anything but Linux. The numbers above are one Linux laptop.