What is corespeechd / corespeechd_system on macOS?

Last updated: 2026-08-08

What it is

corespeechd / corespeechd_system are two Apple system daemons belonging to macOS’s private CoreSpeech framework. The user-level corespeechd runs in a user session, while corespeechd_system is launched under the dedicated _corespeechd system account. Both executables are installed inside CoreSpeech.framework and are signed by Apple.

Current macOS system files show that corespeechd / corespeechd_system participate in coordinating several parts of the speech stack: Siri voice-trigger detection, speaker recognition, speech endpoint detection, speech configuration, and on-device speech-recognition models. Endpoint detection in this context helps the speech system determine where spoken input begins or ends; it does not, by itself, establish what happens to the resulting audio.

Apple has not published a complete division of responsibilities between the two daemons. It is therefore reasonable to describe them as components of the CoreSpeech system, but not to assign every Siri, Dictation, or speech-networking operation to either process. A running corespeechd / corespeechd_system instance is also not evidence that macOS is continuously sending microphone content elsewhere.

Why it talks to the network

Verified network-related trigger categories for corespeechd / corespeechd_system include subscriptions, downloads, and updates for Siri or Dictation speech models, voice-trigger models, speaker-recognition models, and speech-endpoint models. Inspection of the current binaries shows that they are authorized to access the relevant Apple MobileAsset and Unified Asset Framework resources.

A larger transfer can therefore be associated with obtaining or updating speech assets even when the user is not in the middle of a spoken request. Conversely, seeing traffic during a Siri or Dictation session does not prove that the connection is a model download.

When a user starts Siri or Dictation, Apple says that speech, transcripts, request data, and necessary context may be sent to Apple’s Siri processing services if the applicable language and feature are not identified in System Settings as being processed entirely on the device. Whether processing stays on the device depends on the device, language, and feature. The descriptions shown in Siri and Keyboard settings are the appropriate source for that distinction.

Apple does not publicly establish that every relevant request or asset download is connected directly by corespeechd / corespeechd_system. Some traffic may instead be carried by assistantd, nsurlsessiond, MobileAsset components, or another supporting service. Specific remote hosts and exact per-process ownership are therefore unverified; a connection attributed elsewhere does not necessarily mean CoreSpeech was uninvolved, and activity recorded against corespeechd / corespeechd_system does not reveal its purpose by itself.

How much traffic is normal

There is no published, reliable process-level traffic baseline for corespeechd / corespeechd_system. Apple does not provide a normal daily total, a dependable size range for speech models, or a documented update frequency. It is not responsible to attach a specific megabyte figure to these processes.

Based only on their verified tasks, idle behavior would normally be expected to involve no traffic or occasional small state or asset checks. A Siri or Dictation session that uses cloud processing produces interactive traffic that varies with the length of the spoken input and request. The first acquisition or a later update of a speech model can produce a noticeably larger download burst.

A model download would generally be much larger than one short spoken request, but its size, frequency, and accounting process remain unverified. This distinction matters when investigating a spike: one isolated burst may have a different explanation from repeated transfers that closely follow spoken sessions, but volume alone cannot identify the cause.

Can you turn it off

The practical recommendation is to keep corespeechd / corespeechd_system available. Apple does not provide a System Settings switch that disables either daemon itself, and it does not document a side-effect-free method for terminating, deleting, or firewall-blocking this shared system component.

If you do not use the related user-facing features, disable those features through their official controls:

• For Siri, open Apple menu > System Settings > Apple Intelligence & Siri. On some macOS versions, the panel is named Siri. Turn off Siri there.

• For standard Dictation, open Apple menu > System Settings > Keyboard > Dictation and turn Dictation off.

• If you only want to stop voice activation, open Siri settings and set Listen for to Off.

These changes remove the corresponding Siri, voice-activation, or standard Dictation capability. They do not guarantee that corespeechd / corespeechd_system will never launch again, because Apple has not published the daemons’ complete responsibilities across all system speech features. Blocking the processes directly may also interfere with speech-model management or related system speech services, and Apple provides no assurance that doing so is harmless.

What people get wrong

• “If corespeechd / corespeechd_system is running or connected, Apple must be continuously uploading ambient audio.” That conclusion does not follow from the evidence. Apple describes Siri voice-trigger detection as an on-device system. Process presence or a small amount of traffic cannot prove that audio is being uploaded.

• “‘Hey Siri’ detection requires an internet connection.” That is not an accurate description of the modern voice-trigger system. Apple describes the trigger itself as operating on the device. A connection may still be used for processing the request after activation or for updating the models involved.

• “Every Siri and Dictation recording is sent to Apple.” Processing varies by device, language, and feature. Apple directs users to the descriptions in Siri and Keyboard settings to see whether a particular configuration is handled entirely on the device. A universal claim in either direction goes beyond the available evidence.

• “If I do not use Siri or Dictation, I can safely firewall-block corespeechd / corespeechd_system without affecting anything else.” Apple offers no process-level off switch and has not documented the complete role of these daemons in every system speech feature. There is no reliable basis for promising that direct blocking has no side effects.

• “Turning off Improve Siri & Dictation stops normal Siri networking.” That setting controls voluntary samples used for improvement and human review. It does not prevent the networking required for ordinary cloud request processing or speech-resource updates.

• “corespeechd_system is a suspicious duplicate of corespeechd.” Current macOS installations include both Apple-signed components. corespeechd is the user-level daemon, while launchd runs corespeechd_system under the dedicated _corespeechd account. Apple has not published their full internal division of work, but the existence of both is expected.

Seeing what it actually used

To investigate the next spike, use Bytetally’s per-process history to check when traffic was attributed to corespeechd / corespeechd_system, how long it lasted, and whether it coincided with Siri, Dictation, or a possible asset update. Compare it with nearby activity from assistantd, nsurlsessiond, and MobileAsset-related services, because Apple does not guarantee direct process attribution. Treat the result as observed accounting rather than proof of what audio or model data a connection contained.

Related processes

Common questions