Why parallel coding agents can make your Mac work harder

A coding agent can change hundreds of files while you are reading its last message. Run several agents, install dependencies in several folders, and start a development server in each one, and your Mac has plenty of work beyond answering model requests.

Some of that work comes from the tools you started. Some comes from macOS noticing the files they changed.

Before changing system settings, find out which process is busy. A hot laptop alone doesn’t tell you whether the problem is Spotlight, a test runner, a compiler, or five development servers watching the same generated files.

This is a diagnostic workflow based on Apple’s documentation and the macOS command manuals. I haven’t run a performance comparison of different disk layouts, so there are no claimed speedups here.

Start with one repeatable task

Open Activity Monitor, select the CPU tab, and sort by CPU usage. Watch it while the agents are idle, then while one agent runs a normal task.

Look at the Disk tab too. A dependency installation can be busy writing files even when the model itself is waiting for a response.

Write down the process names you see. A Node process could be your development server, an agent, or a build tool. Expand that investigation before deciding that every busy process belongs to macOS.

Repeat the same kind of task with your usual number of agents. Keep the project and commands similar. Comparing a quiet editing task with four dependency installations won’t tell you much about agent concurrency.

You are looking for an explanation you can test. For example: “Every time this build recreates its output directory, the development server restarts and indexing activity rises.” That gives you something specific to change.

File events and search indexing do different jobs

The macOS file event system lets applications learn that directories have changed. Backup software is one consumer of that information. Apple’s File System Events guide describes how applications use events to decide what needs another look.

Spotlight builds a searchable index. Processes such as mds and mdworker_shared are useful clues when investigating indexing activity. fseventsd belongs to the file event machinery.

Turning off Spotlight indexing for a volume doesn’t turn off file events. It also doesn’t stop your editor, language server, test runner, or development server from watching files.

This distinction matters because several consumers can react to the same write. Removing one consumer may help, but the original stream of writes still exists.

A .gitignore file controls what Git considers untracked content. Don’t assume it also excludes that directory from every search indexer and file watcher.

Take a short trace when you need one

If Activity Monitor leaves you unsure, macOS includes fs_usage. Its manual documents a filesystem filter, process filters, and a duration limit.

This command observes filesystem activity from the named processes for ten seconds:

sudo fs_usage -w -f filesys -t 10 fseventsd mds mdworker_shared

It requires administrator access. The output can contain private file paths, so inspect it locally. Don’t paste a raw trace into a public issue or an agent prompt.

You may need to adjust the process names to match Activity Monitor on your Mac. A quiet trace only means those processes were quiet during that window.

Read man fs_usage on your machine before using it. Keep the observation brief; collecting endless diagnostic output adds work of its own.

Reduce the writes and watchers first

Look for generated content that one tool writes and another tool treats as source input.

A development server watching its own output directory can rebuild repeatedly. A test runner can watch a directory full of temporary reports. Several agents can each launch a development server and leave it running after their task ends.

Check the actual watcher settings in those tools. Exclude build output and caches where the tool supports it, and stop servers you aren’t using. Don’t exclude source files just to make a graph look better.

Ask agents to reuse an existing development server when that fits the task. Run a dependency installation only when dependencies changed. Give concurrent tasks clear ownership so they don’t keep regenerating the same files.

These changes reduce work at the source. They also make the setup easier to understand the next time a process becomes busy.

Exclude a specific folder from Spotlight

If indexing is the activity you identified, try the smallest useful exclusion.

Apple documents this in Spotlight Search Privacy. Open System Settings, find Spotlight, then open Search Privacy and add the folder you want excluded. Settings names can vary with your macOS release.

The files in that location won’t appear in Spotlight results. Remove the folder from the privacy list to include it again.

Start with a disposable build or dependency directory rather than your entire home folder. Consider whether you rely on Finder search for those files before excluding them.

Keep Time Machine’s special handling in mind too: Apple’s documentation says excluding a Time Machine backup disk does not stop the indexing needed for Time Machine.

When a dedicated APFS volume helps

A separate APFS volume can give disposable agent work a clear boundary. You can apply an indexing choice to that volume without applying it to your normal documents.

It takes some housekeeping. Existing absolute paths can break when you move projects. Your editor, backup tool, synchronization software, and agent configuration may need new paths. Verify what is backed up before storing anything important there.

APFS volumes in the same container share available storage. They also use the same underlying device. Adding a volume doesn’t give your agents an independent SSD or guarantee lower CPU usage. Apple’s APFS volume guide explains space sharing, quotas, and reserve sizes.

If you already have a dedicated volume mounted at /Volumes/AgentWork, inspect it first:

diskutil info /Volumes/AgentWork
mdutil -s /Volumes/AgentWork

Confirm that the path identifies the intended volume. Record its current indexing status before changing anything.

For that specific volume, the mdutil manual documents:

sudo mdutil -i off /Volumes/AgentWork

If indexing was enabled before and you want to restore it:

sudo mdutil -i on /Volumes/AgentWork
mdutil -s /Volumes/AgentWork

Re-enabling indexing can itself cause work while the index catches up. Retest your original workload after activity settles.

I would leave file event services alone. Watchers and backup tools depend on change notifications, and disabling that machinery has consequences beyond the directory you were trying to quiet down. A smaller watcher scope, a specific search exclusion, or fewer simultaneous builds is a much easier change to understand and reverse.

Want me to talk about your product? You can sponsor this site.