[Feature]: Read AI responses aloud via built-in TTS (per-message "read aloud" action)

[JardarIversen]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Use case

Add an optional text-to-speech action that reads the assistant's chat output aloud, on a per-message basis.

Problem

Today there is no way to have T3 Code read its own responses out loud while I'm away from the screen or looking at the code. This makes it harder to concentrate and read output on longer coding sessions.

Related issues:

• #653 — Voice support covered voice input / prompting (STT) and was closed as not planned ("out of scope, there are apps that do this already").
• #376 — Lifecycle hooks / notification integration (peon-ping) is about completion/error cues for state changes, not about reading the content of a response.

Neither of these addresses the use case of having the model's content itself read aloud, message by message, on demand.

Proposed solution

A per-message "Read aloud" / "Speak" action on the assistant message UI (next to copy button), with a small set of built-in voices and the option to auto-read new streaming responses.

Two implementation paths, either or both:

1. Browser SpeechSynthesisUtterance — zero-cost, no model download, works offline, uses the OS-provided voices. Good baseline, available everywhere the UI runs.
2. Optional cloud TTS (OpenAI, ElevenLabs, etc.) via the same providerhook surface the app already uses — better quality, natural voices, streaming audio. Opt-in, BYO-key.

Suggested shape

• A 🔊 button on each assistant message bubble
• Optional setting: "Auto-read streaming assistant responses when complete" (off by default)
• Optional setting: pick TTS engine (System / OpenAI / ElevenLabs / ...) and voice.
• Respect streaming boundaries — only enqueue a chunk once it forms a complete sentence / code block boundary so narration stays coherent.
• Stop/pause controls while speaking.

Open questions

• Should reading also cover code blocks verbatim, skip them, or summarize ("30-line TS function")? My vote: skip fenced code by default, read prose.
• Should there be a keyboard shortcut to read the latest assistant message?

Why this matters

• Hands-free during long turns. While the agent is generating/running, I can keep my eyes on the editor and have the response delivered as audio.
• Accessibility. Users with low vision, dyslexia, or who simply skim better by ear benefit from spoken output.
• Outdoing Claude Code and Codex on this. Even though their chats have a "read aloud" control on assistant messages, their coding agents don't.

Smallest useful scope

A single button under each message that read out the message it's under, with a pause function. Smallest useful scope would not need more advanced controls, or model selection.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[fasuizu-br]

Disclosure: BRAINIALL operates Brainiall TTS, so this is a vendor opt-in offer, not a neutral recommendation.

The system SpeechSynthesisUtterance baseline in the issue looks like the right first implementation. If maintainers want a provider comparison after that, BRAINIALL can prepare a deliberately small, provider-agnostic spike for one completed message at a time:

• prose only → TTS request → buffered WAV playback;
• play/stop controls, with no claim of streaming or auto-read support;
• synthetic English and PT-BR fixtures;
• measured payload, latency, listed cost and explicit data-handling assumptions;
• BYO key and a clean fallback to the system voice.

We would keep code blocks, sentence-boundary streaming and background auto-read out of the first spike. If that scope would help, please reply with the preferred provider interface / audio format; otherwise we will not follow up.

[sigvardt]

+1. Would love read-aloud on both desktop and mobile, as a per-message action and as an optional auto-read for new answers (skipping code blocks). My goal is to talk with my agents while driving, so background playback on mobile matters alot, see #14394 and #12622. A bring-your-own-key option (OpenAI/ElevenLabs) next to the system voice would be great.

[saostad]

This is a very valid and important feature Especially when I want to read a long response while I'm planning with my AI agent or doing an investigation. If somebody put the requirements together, I can do the implementation.

[Kaiantics]

Adding my support for this, especially in the mobile app. Text-to-speech is the feature I most want in T3 Code. My main use case is listening to my agents' responses hands-free while driving, or while doing chores.

Optional auto-read and background audio playback on mobile would be especially useful, so I wouldn't need to tap each response to hear it.

[hans-peter123]

I would love this feature

[lukelabonte]

I'd like to help move this toward an agreed scope, including native iOS and Android support from #12622.

T3 is my daily workflow. I have dyslexia, and hearing long responses makes them much easier for me to follow. I'd like a discoverable way to read a selected passage or a completed assistant response without leaving the app. This would make a real difference to how I use T3.

On macOS, Edit → Speech → Start Speaking and the Speak Selection shortcut are available as workarounds, but they're not ideal for this workflow. Reading the intended passage seems sensitive to how content is rendered in T3; I've had a request to read a selection read the whole window instead.

Proposed behavior

• Read selection: add a Read action alongside Cite in the existing text-selection popover, with an equivalent native selection action on mobile. Capture the highlighted passage before activating the control loses focus or selection. Read only that passage. If the selection is empty, stale, or unsupported, disable the action or explain why; never fall back to the whole response.
• Read paragraph (optional): show a small Play button to the left of a paragraph on hover or keyboard focus, so I can read that paragraph without selecting it first. It would speak only that paragraph and only when activated, never just from hovering. Any mobile equivalent should be touch-accessible rather than depend on hover.
• Read response: a separate action beside existing message actions, reading only that completed assistant response, without adjacent messages or hidden tool output.
• Playback controls: an obvious Stop action and accurate starting/reading/error feedback. Starting another passage replaces the current reading. Pause/resume should only be offered where its behavior is reliable, with platform limitations made clear.
• Voice settings: choose a voice available to the local speech engine, preview it with a short sample, and adjust the rate. Keep those preferences local to the device.
• Response reading modes: Full text would include code content without reading Markdown formatting characters. Sanitized would skip fenced code with a short marker and use defined handling for tables and links, while preserving useful inline identifiers. These settings wouldn't change Read selection, which should remain verbatim.

OpenChamber is useful inspiration for voice setup and reading-mode choices, but I'm proposing a T3-native implementation rather than copying its code or provider setup.

My preferred direction is local, on-device synthesis using a speech model that T3 bundles or offers to download when the user enables the feature. By on-device, I mean the device playing the audio, including the phone when it connects to a remote T3 environment. After setup, reading should work without sending response text to an external service or requiring API credentials.

Kokoro is one candidate to evaluate, not a settled dependency. We'd need to check model and voice licensing, download size, startup latency, memory use, and battery impact across desktop, iOS, and Android before choosing a runtime. A model download should show its size and require an explicit user action, with a way to remove it. Installed system voices could remain an alternative where useful, but there should be no silent fallback to network synthesis. Playback itself would always start through an explicit user action.

A separately selected Summarized mode would also be useful eventually. I'd keep that outside the initial implementation because generating a summary introduces a separate model, privacy, and cost decision. It shouldn't be confused with deterministic Markdown cleanup.

Native mobile scope

Desktop-only wouldn't complete this proposal. Both iOS and Android need native selection handling, audio interruption handling, and playback validation.

The background/locked-phone workflow in #12622 is also important. A foreground-only first version would address my immediate use case, but it wouldn't fulfill that discussion's minimum. That boundary needs agreement before implementation. Pause/resume and interruption handling also need validation against the chosen playback engine on each platform.

Existing work and approval

I've looked through #2356, #3630, and #3631. They contain useful ideas about local models and playback, but their separate speech services and broader voice-mode scope differ from synthesis integrated into each listening device. The open Codex voice-conversation PR #14865 also seems complementary rather than a replacement for reading an existing response independently of its provider.

@juliusmarminge, before starting another implementation, I'd like your guidance on whether this direction fits T3 and which scope would be appropriate:

1. A focused cross-platform contribution with the controls above, foreground mobile first, and background playback explicitly left for a later agreed stage.
2. The same direction, with background/locked mobile playback required in the first contribution.
3. Coordinate with an existing effort instead, if there's a preferred implementation or owner.

Validation would need to cover exact selection, selection loss during activation, repeated starts and cancellation, stale callbacks, navigation, interruptions, and audible playback on the supported platforms. Unit tests alone wouldn't establish that the speech experience works.

[gruckion]

I really want this. And with a highlight the paragraph and follow each word feature (similar to the NaturalReader chrome extension see image).

I'm building this now, currently planning to use Elevanlabs (as I have a monthly subscription for it already - I have my AI make e2e narrated walkthrough videos of what it's built). Will share it here once it's built in case anyone else is interested.

PS my solution will also be extendable. I find it reads hashes char for char which is hella annoying so I have a few TypeSafe AI based checkers that quickly run on the text and forces the reader to read them in a way that's easier to follow. My speech cleaner solution is currently a patch on Claude desktop and can be found here. https://github.com/gruckion/claude-speech-cleaner

What my speech cleaner does;

---AI-slop line---

1. code-blocks — Reads prose inside code fences directly; uses AI to explain actual code.
2. markdown-tables — Uses AI to convert tables into understandable spoken prose.
3. urls — Replaces long URLs with “GitHub attachment” or “link to [hostname].” Keeps meaningful link labels.
4. migration-files — Uses Jev to confirm migration filenames; reads them as “migration ending c6da.”
5. hashes — Uses Jev to identify hashes; reads only “hash ending” and the last four characters.
6. file-paths — Converts path separators into spaces, avoiding pronunciations such as “research per pedro.”
7. separators — Replaces underscores and hyphens in inline references with spaces; pronounces identifier id segments as “I D.”
8. blockquotes — Removes Markdown quote markers from speech while preserving actual comparison operators.

All changes apply only to speech; displayed text stays unchanged.

[rhinoandre]

I'd love this feature!

[jorgeluiso]

I'm frequent user of of read out loud on Codex. Coding while taking long walks it's awesome both for my health and to keep paying attention to the thread.

[jan-stegeman]

Written and posted by Claude (Anthropic's AI assistant) on behalf of this account's owner, at their request.

+1, on Windows 11 desktop. A per-message "Read aloud" button next to Copy would help people who find reading long answers hard, and pairs well with dictation for a hands-free workflow. Skipping code blocks and supporting more than one language (for example Dutch and English) would make it useful for non-native speakers too.

[Isaac-b-ux]

I have a working read-aloud on web and Android in my fork, if it helps.