What Is spotlightknowledged? It Embedded My Deleted Items

spotlightknowledged is the macOS daemon that turns things apps donate to Spotlight into search "knowledge": keyphrases and text embeddings, the vectors behind the newer semantic search. It belongs to Core Spotlight, the per-app index, not to the file index that mds_stores keeps. On my Mac mini it is three launchd jobs, and two of them get killed by the kernel for going over a 25 MB memory limit, which happened four times in the last 23 hours.

I didn't plan to write about it today. At 12:02 I added 110,000 test items to a Core Spotlight index for my corespotlightd post, and at 12:05 I deleted all of them. A search for them returned 0 results. Three hours later, spotlightknowledged was still generating embeddings for those items at about 330 a minute, and mediaanalysisd, which does the actual model work, was using 2.2 CPU cores to keep up.

The rig is a Mac16,10 (M4, 16 GB) on macOS 26.4.1, headless, with no Apple Account mail or Photos library in use. Everything below was read on 2026-10-24 as an admin user without sudo.

What spotlightknowledged is

$ ps -axo pid,etime,time,command | grep spotlightknowledge
68334       43:25   0:40.57 /usr/libexec/spotlightknowledged.updater -u
80643 04-20:57:07   0:33.86 /System/Library/Frameworks/CoreSpotlight.framework/spotlightknowledged -x

There are three LaunchAgents in /System/Library/LaunchAgents, all running as you, not as root (the LaunchAgent vs LaunchDaemon split explains why that matters):

launchd label	Binary and flag	Job	Runs (26 days)
com.apple.spotlightknowledged	spotlightknowledged	Scheduled maintenance: 8 daily background tasks (inference, journals, processing, cascade verification, report), most needing external power	135
com.apple.spotlightknowledged.importer	spotlightknowledged -x	On demand, when corespotlightd calls it over XPC	10
com.apple.spotlightknowledged.updater	spotlightknowledged.updater -u	Works through the donation journal: keyphrases and embeddings	15

The importer had CoreNLP language-ID weights and a 3 MB SystemSearch model file open. The updater had the embedding store open, and lsof shows file sizes even where the folder itself is blocked to my shell by privacy controls:

~/Library/Metadata/CoreSpotlight/SpotlightKnowledgeEvents/index.V2/embedding_cache/9/4/
  cs_pc_c/embedding_store.db     140,775,424 bytes
  cs_pc_c/.embedding_store.db    161,484,800 bytes  (15:04)
                                 164,794,368 bytes  (15:10)
  cs_mail/embedding_store.db          20,480 bytes

The hidden store grew 3.3 MB in six minutes while I watched. The Mail store is 20 KB because this Mac has no mail.

What 110,000 deleted items cost

The unified log is the clearest record. From 09:00 to 12:00 spotlightknowledged wrote 30,594 log lines. A scheduled reindex at 09:03 produced 380 embeddings, and then it went quiet: from 10:50 to 11:59 it wrote 146 to 166 lines per ten minutes and generated no embeddings at all. Between 12:00 and 15:01 it wrote 954,322 lines.

Here is what the log says it did with my test items. Each donation batch names its source as a masked hash. One source hash covers every donation after 12:00 in the updater process, and the item hashes line up with my test exactly:

• The keyphrase job rejected all of them. It logged "Not eliglible for pipeline. Skipping processing." (Apple's spelling) for 110,010 records: 10 at 12:01 and 110,000 at 12:06. My test added 10,000 items and then 100,000 items that reused the first 10,000 IDs. The rejected records carry exactly 100,000 distinct item hashes.
• The embedding job accepted them. For the same items it logged "Record passed checks. Continuing processing." and then a primary and a secondary embedding for each. All 40,554 distinct items it embedded in the first updater process are among those 100,000.
• It embeds the overwritten copies too. In that process it handled 50,574 records for 40,554 distinct items. The extra 10,000 or so are the first batch, which my second batch had already replaced.
• The deletion did not cancel anything. I removed every item at 12:05 with deleteAllSearchableItems, and a query afterwards found 0. The embedding work ran on for the next three hours.

It isn't spotlightknowledged that burns the CPU. The updater used about 1 CPU second a minute. Each item goes out as a "text processing request" to mediaanalysisd, which in a ten-minute window ran 3,299 MADServiceTextProcessingTasks, each logged as a "foreground task" at QoS 21, the default class, not background. I sampled CPU time with proc_pid_rusage for two minutes at 15:07:

Process	CPU in 120 s	Cores
mediaanalysisd	+265.2 s	2.21
spotlightknowledged.updater	+1.9 s	0.02
corespotlightd	+0.1 s	0.00

I have three readings of mediaanalysisd's total CPU time. It was 8,816 seconds after 19 days of uptime and 12,786 seconds in a snapshot taken around noon today, shortly before the test, so it was averaging about 24 seconds an hour. At 15:12 it was 35,517 seconds. In three hours it used 22,731 CPU seconds, about two cores on average. At its normal rate that is roughly 39 days of work, and 64% of everything it has used since boot 26 days ago. Some of those three hours could be other work, but the updater's text requests rise and fall with the embeddings, and in a ten-minute sample of mediaanalysisd's log nearly every entry was a text task.

The 15:01 to 15:13 count was 3,993 embeddings, about 330 a minute. About 57,000 of the 110,010 records were done. If the rate holds, the rest takes about 2 hours 40 minutes more, nearly six hours in total for items that stopped existing three minutes after I made them.

Why the processes keep dying

launchctl print gives both the importer and the updater a jetsam memory limit of 25 MB, "active, soft" and "inactive, hard". In practice that means: while the process is busy holding a transaction it may go over 25 MB, and the kernel only notes it; once it goes idle above 25 MB, it is killed. The kernel log for the last 23 hours, which is all this Mac keeps:

02:38:17  spotlightknowledged.updater [33468]  InactiveHard 25 MB (fatal)  46,785 KB
09:05:50  spotlightknowledged.updater [47863]  ActiveSoft 25 MB (non-fatal)
09:06:05  spotlightknowledged.updater [47863]  InactiveHard 25 MB (fatal)  25,697 KB
12:11:26  spotlightknowledged.updater [32610]  ActiveSoft 25 MB (non-fatal)
14:16:55  spotlightknowledged.updater [32610]  InactiveHard 25 MB (fatal)  34,897 KB
14:27:34  spotlightknowledged.updater [68334]  ActiveSoft 25 MB (non-fatal)
15:01:37  spotlightknowledged [80643]          InactiveHard 25 MB (fatal)  30,321 KB
15:02:45  spotlightknowledged [1057]           ActiveSoft 25 MB (non-fatal)

Both launchctl print entries record JETSAM_REASON_MEMORY_PERPROCESSLIMIT as the last exit reason, so this is the normal way these processes end, not a crash, although the 14:16 kill did set off ReportCrash's memory exception handler. The work isn't lost: at 14:16:55 the updater died at donation batch 51676, at 14:17:11 launchd started a new one, and it began with batch 51677.

The peaks are well above 25 MB. The importer that had been running for 4.9 days had a lifetime peak footprint of 889 MB when I read it at 15:00 (it was 103 MB at noon). It was killed at 15:01:37, during my measurements. Its replacement reached a 1,035 MB peak within its first two minutes, then settled at 10 MB. These are peaks, and the processes sit around 10 MB most of the time. But it means a daemon with a 25 MB limit can briefly take 1 GB of RAM.

What other people report

There is very little written about this daemon. Searching for it turned up one direct report: a 2024 Apple Community thread about recurring high CPU from spotlightknowledged on a Mac mini, where the replies suggest waiting for indexing to finish or rebuilding the Spotlight index. Nobody in it measured anything.

The folder is better documented than the process. In an Apple Community thread from December 2024 with 76 "me too" votes, people on macOS Sequoia reported SpotlightKnowledgeEvents at 150 GB, 120 GB on a 250 GB drive, and 550 to 580 GB on two Intel Macs. One admin found it on 43 of about 200 managed Macs, all Intel, all on 15.1 or later. Apple Support told at least two posters to delete the folder or its contents. Spotlight kept working, and the folder grew back in a few weeks. SuperDuper's developer found 6,166,838 files in one SpotlightKnowledgeEvents journal folder inside a user's Photos library, and listing them took more than 24 hours.

Those are disk reports, mine is a CPU one, and they share a cause: the knowledge index is a journal that apps write to and a background process works through later. Whatever an app donates gets processed, and per item it can cost far more than the donation did. Adding my 100,000 items took 7.7 seconds. Embedding them takes hours.

What to do if it is busy

1. Check whether it is a backlog. This counts embeddings in the last ten minutes. Run it twice a few minutes apart; if the donation numbers keep rising, it is working through a queue and will stop when it reaches the end:

   log show --last 10m --style compact \
     --predicate 'process == "spotlightknowledged.updater" AND eventMessage CONTAINS "Embedding.Backlog"' \
     | grep -oE 'Donation [0-9]+' | sort | uniq -c | tail -3

2. Look at mediaanalysisd, not just spotlightknowledged. In Activity Monitor the cost shows up under mediaanalysisd. If both are busy together, it is text embedding, not photo analysis.
3. Killing it does nothing useful. The kernel already kills it several times a day and launchd restarts it within seconds. The new process resumes the backlog.
4. Find the app that donated. The log masks bundle IDs, so the practical test is what you did recently: a mail import, a large Pages or notes library, an app that syncs thousands of records. On Sequoia, posters pointed to Mail, DEVONthink and large Pages files, and one shrank the folder after excluding the Mail library in Spotlight's privacy list (they weren't sure which step helped). I haven't tested whether turning off result categories in System Settings > Spotlight stops the processing.
5. Deleting the folder is the community fix for disk use. It worked for posters in the Apple thread and came back later. I didn't try it. My shell can't read ~/Library/Metadata/CoreSpotlight, and it would not have stopped the queue already in flight.

For the file index side of Spotlight, see mds_stores high CPU. For the other Apple Intelligence background jobs that wake up on their own, see knowledge-agent.

FAQ

What is spotlightknowledged on Mac?

spotlightknowledged is a macOS background process that belongs to Core Spotlight. It processes the items apps donate to Spotlight into keyphrases and text embeddings for semantic search, and stores them under ~/Library/Metadata/CoreSpotlight/SpotlightKnowledgeEvents. It runs as three LaunchAgents in your user session: a scheduled maintenance job, an importer (spotlightknowledged -x) and an updater (spotlightknowledged.updater -u). The heavy model work is handed to mediaanalysisd.

Why is spotlightknowledged using so much CPU?

Usually it is working through a backlog of items an app donated to Spotlight. In a test on a Mac mini, adding 110,000 items to a Core Spotlight index started about six hours of embedding work at roughly 330 items a minute, and mediaanalysisd used about two CPU cores the whole time. Deleting the items three minutes later did not stop it. The work ends when the backlog is processed.

Can I quit or delete spotlightknowledged?

You can quit it, but launchd restarts it within seconds and it resumes the same work. The kernel already kills it several times a day for going over its 25 MB memory limit. The binary is part of the sealed system volume and cannot be removed. People with a very large SpotlightKnowledgeEvents folder have deleted its contents on Apple Support's advice; it rebuilds over time.

Everything about my Mac comes from one Mac16,10 on macOS 26.4.1, read without sudo on 2026-10-24: the three launchd plists and launchctl print output, lsof on the two running processes, proc_pid_rusage CPU and memory readings, about 985,000 lines of spotlightknowledged unified log from 09:03 to 15:01, the kernel jetsam log for the previous 23 hours, and mediaanalysisd's CPU time from snapshots taken for earlier posts on this blog. The 110,000 items were my own test donations from a script with no app bundle, which is not how a real app donates, so a real app's items may be filtered differently. The link between my test and the work is from matching counts and item hashes in the log. I could not read the bundle IDs, which macOS masks. The finish-time estimate is my arithmetic and the work was still running when I published. The folder sizes and fixes in the community section are other people's reports, not mine.