macos on Saurabh Kumar

Wispr Flow

Thu, 08 Oct 2026 12:00:00 +0000

Back on Wispr Flow after six months on local speech-to-text (FluidVoice with Parakeet, plus Whisper). Local transcription is fine. The cleanup is what’s missing: fixing misheard jargon ate the time dictation saved. Flow’s correction pass, OS-level integration and phone keyboard win. It matters more now because models follow high-level intent well: I speak the intent plus constraints in one go and let the LLM structure it. Whisper mode works even when you speak softly. Want to try it? My referral link gets you a free month of Pro, and I get one once you’ve dictated 2,000 words.

Recordly

Mon, 13 Jul 2026 12:00:00 +0000

Recordly does video recording, screenshots, and demo editing in one open-source Electron app. Not in Homebrew core, but easy to ship via a personal tap: brew install --cask theskumar/tap/recordly. Replacing my previous screenshot/recording workflow with this as the single default (see Default Apps 2025).

Moshi

Mon, 15 Jun 2026 12:00:00 +0000

Moshi is the best SSH client I’ve found for iPhone — connects to your laptop’s tmux sessions over Mosh, making it rock-solid on mobile networks with roaming support. Perfect for an agent view on the go; I use it to monitor and interact with running pi/Claude sessions from my iPhone without losing the session on network switches.

My Local LLM On A 32 GB M1 Pro

Sun, 14 Jun 2026 00:00:00 +0000

My pi setup has a fast mode: a slot I wired into my own config for the small, high-volume questions, pointed at Bedrock’s Haiku 4.5. It is a good model. Cheap, responsive, and it answers the kind of small, contained question I throw at it twenty times a day without complaining. It runs on third-party hardware, and those questions send code to a third party. I wanted to try running that slot locally.

None of that is a crisis. Bedrock is fast and it works. But the machine that could do the same job is sitting on my desk, and when Kyle Howells got Gemma 4 26B-A4B running locally on an M1 Max at 72 tokens per second and the Hacker News thread filled up with people on smaller Macs reporting the same setup was workable, I wanted to know whether my own laptop could host that slot.

The catch is that my laptop is an M1 Pro with 32 GB of unified memory: half the RAM and roughly half the memory bandwidth of the machine in Kyle’s post. Copying his commands verbatim was never going to work. I needed to know what to change, in what order, and what to give up. So I did not copy the commands. I gave pi the article and asked it to build me a plan for my machine, and to interrogate me before it wrote a line.

I Handed The Guide To An LLM And Made It Grill Me

The whole thing started with one message. Typos and all, this is what I actually sent:

Act local AI setup expert working on M1 silicon with 32GB ram. Read though [the article] and also pull all the comments on this article on news.ycombinator.com article id 48507020. I’ve ollama and muse already installed there are models installed as well. Prep and action plan to set this up in the most performant and maintaibale way. Not sure quite sure if i need to uninstall previous ollama app and it’s modetls. Create and write a plan after analysing things. /grill-me

The /grill-me at the end is a small skill in my pi setup. It is two paragraphs of instructions that tell the model to walk down the decision tree one node at a time, recommend an answer at each step, and wait for my reply before moving on. It is not magic. It is a way of forcing the conversation I would otherwise have with myself in a notebook, except the model will not let me skip a step.

The interview was mostly the model proposing and me confirming in monosyllables. My replies, verbatim, were things like:

A

i would prefer ~/code/localLLM

A, also note i’ve “llm” cli already installed, and alias would be nice.

let’s go with recommendation, write the plan.

That is the entire texture of it. A simple opening prompt that points at an existing guide and names my constraints, then a handful of one-word answers steering the branches. The model did the reading (the article and the full HN thread) and the arithmetic. I made the calls.

And it pushed back, which is the point. When I leaned toward the 65 K context window from the article, it did the memory math and showed me I would be swapping inside the first generation on 32 GB, so we settled on 32 K. When I waffled on keeping Ollama “just in case,” it pointed out I was at 89 % disk with a thirteen-gigabyte Ollama models directory I was not using. When I asked for an alias, it caught that llm was already taken by Simon Willison’s tool and proposed lcl instead. None of these are insights I lacked. They are checks I would have skipped because I was already mentally on the next step.

By the end there was a written record of every decision and its reason, in the repo, not in my head. That is where it should be.

The Decisions That Fell Out

The interview converged on a short list, and the reasoning behind each one is worth more than the choice itself.

Model: Gemma 4 26B-A4B, the MoE, not a dense model. The single most important fact about local inference on a Mac is not how much RAM you have, it is how fast it can be read. Generation is bottlenecked on memory bandwidth. The M1 Max in Kyle’s article runs at 400 GB/s; my M1 Pro at roughly 200. Everything else being equal, I should expect about half his throughput. His 72 tokens per second becomes my 36. That is still faster than I read. It is also why a mixture-of-experts model is the right answer here: Gemma 4 26B-A4B holds 26 billion parameters but activates only four billion per token. The full weights sit in RAM, but each forward pass streams a fraction of them. The dense 27B sibling has the same disk footprint and meaningfully worse generation rate. It is probably smarter. It does not matter, because it is too slow for the slot I am filling.

Speculative decoding, on. Gemma 4 ships an MTP draft head, a tiny network that predicts the next several tokens cheaply, which the main model accepts or rejects in one pass. When acceptance is high, you get most of those tokens almost for free. Kyle measured +24 % on his machine. The HN thread is full of caveats about acceptance rates and MoE models benefiting less. None of it changes the decision: turn it on, measure, keep what you get.

Context: 32 K, not 65 K. The arithmetic the model made me do. A 65 K KV cache plus 16 GB of weights plus a draft model does not leave enough headroom on 32 GB once Chrome and an IDE are open.

mise, not a shell script. The article uses huggingface-cli to fetch the GGUFs and a hand-written tmux script to launch the server. Both work. Both are also infrastructure you now own and will forget you configured. llama.cpp’s -hf flag does the download without a Python virtualenv. mise’s github: backend installs the prebuilt Metal binary and rolls it forward with mise upgrade. The tmux script becomes a few named tasks in a .mise.toml. The choice is not about elegance, it is about which moving piece you are willing to own. I already own mise.

Ollama goes. I had it from earlier experiments, with gemma4:latest and a couple of other models taking 13 GB, plus the app idling in the background on port 11434. Ollama is a wrapper around llama.cpp. Once you run llama-server directly, the wrapper is in the way. So the app, the models directory, and the port all go, and the 13 GB comes back on a disk that was at 89 %.

The Setup, Start To Finish

This is the reproducible part. You can follow it by hand, or point an LLM at this section and let it do the work. That is roughly how it got built in the first place. The numbers below are the actual results on my M1 Pro, not estimates.

1. Decommission Ollama (skip if you never had it):

osascript -e 'tell application "Ollama" to quit' 2>/dev/null
pkill -f Ollama
rm -rf ~/.ollama /Applications/Ollama.app # reclaimed 13 GB

2. Install llama.cpp via mise. The prebuilt arm64 binary has Metal and Accelerate baked in:

mise use --global 'github:ggml-org/llama.cpp@latest'
llama-server --help | grep -E -- '--spec-type|-hf' # confirm MTP + HF download support

The one thing worth verifying is that --spec-type draft-mtp is present, since MTP support landed only recently. On my install (build b9631) it was there. If it ever is not, a source build with -DGGML_METAL=ON is the five-minute fallback.

3. A project with mise tasks at ~/code/localLLM/.mise.toml. The [env] block makes the model cache live with the project; the tasks replace the shell script:

[env]
LLAMA_CACHE = "{{ config_root }}/models"

[tools]
"github:ggml-org/llama.cpp" = "latest"

[tasks.start]
description = "Start llama-server (Gemma 4 26B-A4B + MTP) in tmux"
run = """
tmux has-session -t llama 2>/dev/null && { echo running; exit 0; }
tmux new-session -d -s llama -c "$PWD" \\
 "llama-server \\
 -hf unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL \\
 -hfd unsloth/gemma-4-26B-A4B-it-GGUF:Q8_0-MTP \\
 --spec-type draft-mtp --spec-draft-n-max 3 \\
 -ngl 999 -fa on -c 32768 --parallel 1 \\
 --reasoning off --reasoning-budget 0 \\
 --temp 0.7 --repeat-penalty 1.1 --repeat-last-n 256 \\
 --host 127.0.0.1 --port 8082 \\
 2>&1 | tee -a logs/llama-server.log"
"""

[tasks.stop]
run = "tmux kill-session -t llama 2>/dev/null && echo stopped || echo 'not running'"

[tasks.status]
run = "curl -fsS http://127.0.0.1:8082/v1/models >/dev/null && echo up || echo down"

A note on the port. The article uses 8080. On my machine 8080 and 8081 were already taken by Google cloud-run processes, so the server silently answered on a port that was not mine until I noticed the responses carried a Server: Google Frontend header. I moved everything to 8082. Check lsof -i :8080 before you assume a port is free.

4. A one-key alias in ~/.zshrc. llm was taken, so lcl for “local”:

lcl() { mise -C "$HOME/code/localLLM" run "$@"; }

lcl start # boot the server (first run downloads the model)
lcl status # is it up?
lcl stop # free the ~22 GB of RAM

5. First boot and download. lcl start triggers the download through llama.cpp’s -hf. The real footprint came in smaller than the article’s “~21 GB” estimate. The total was 18 GB: 16 GB for the Q4_K_XL main model, 1.2 GB for the MTP head (an auxiliary head, not a full second model), and a 441 MB multimodal projector that gets pulled automatically even though I do not need images. Add --no-mmproj if you want to skip it.

6. Point pi at it. A local provider in ~/.pi/agent/models.json:

{
 "providers": {
 "local": {
 "name": "Local llama.cpp",
 "baseUrl": "http://127.0.0.1:8082/v1",
 "api": "openai-completions",
 "apiKey": "local",
 "models": [{
 "id": "gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf",
 "name": "Gemma 4 26B-A4B Q4 + MTP",
 "reasoning": false,
 "input": ["text"],
 "contextWindow": 32768,
 "maxTokens": 8192,
 "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }
 }]
 }
 }
}

And a local mode in modes.json pointing at it. The benchmark answers came back clean, so I gave it real work, and that is where it broke.

The Thinking Spiral

The first real task I handed Gemma was trivial: rewrite a Hugo template so a list of tags renders as “tagged A, B and C” instead of “A B C”. A ten-line edit. Haiku does it in one tool call. Gemma read the file, started thinking, and never stopped. The session export shows a single reasoning block of 32,000 characters: it derived the correct off-by-one logic, then re-derived it, then second-guessed the whitespace, then re-read its own conclusion and started over. It never emitted the edit. I aborted it. I told it “you are going in loop.” It thought about that, too, and aborted again.

This is the failure mode the chat-window benchmarks hide. Gemma 4 IT ships with thinking on, and llama.cpp’s default reasoning budget is unlimited (-1). In a chat that is fine; the model thinks, then answers. Inside an agent loop, where the next move is supposed to be a tool call, an unbounded thinking budget on a small model is a trap. There is nothing forcing the transition from reasoning to acting, and a 4B-active MoE is not big enough to find the exit on its own. The default sampling makes it worse: --repeat-penalty defaults to 1.0, which is to say off, so nothing discourages the model from looping on its own reasoning.

My first instinct was the biggest hammer: turn thinking off entirely. It worked. But “it worked” is where most debugging stops and most of the understanding gets lost, so I made the model prove which flag was actually doing the work. I had pi reconstruct the exact failing scenario from the session export, same system prompt, same tools, same file, same prompt, and replay it against two server configs:

--reasoning off --reasoning-budget 0 # A: no thinking
--reasoning auto --reasoning-budget 1024 --repeat-penalty 1.1 # B: bounded thinking

Same prompt, same machine, here is what came back:

Config	Reasoning emitted	Outcome
Original (unbounded, no repeat penalty)	32,000 chars	spiral, aborted, no edit
A — reasoning off	0 chars	clean `read` → `edit`
B — bounded to 1024	518 chars	clean `read` → `edit`

The lesson is in the third row. Capping the budget alone stopped the spiral: the model thought for 518 characters, decided, and acted. So the bug was never “thinking is bad.” It was “unbounded thinking is bad,” and --reasoning off is just the most aggressive way to bound it to zero. Both configs produced the same edit, the same slightly-clumsy Hugo logic. The extra reasoning in config B bought nothing on this task; that is a 4B-active model hitting its ceiling, not a budget I can tune my way around.

Two more things I only learned by testing. --repeat-penalty is an orthogonal fix and worth keeping regardless: at 1.0 it is off, and it guards the content against loops, not just the thinking. And --reasoning off does not lobotomise the model the way the name suggests. I gave it a reasoning trap with thinking off, and it still worked the problem out, step by step, in its visible answer, and got it right. What the flag removes is the separate, hidden, budget-less thinking phase, not the model’s ability to reason. For an agent loop that is the right trade: when reasoning happens it is visible in the content and bounded by the task, instead of a hidden phase that can run away.

So for the fast slot I keep it off. The whole point of the slot is a quick, direct tool call; the test showed bounded thinking adds latency with no quality gain here, and if I want real reasoning I switch to a cloud mode. That is also why "reasoning" is false in the model config above, with thinking disabled at the server there is nothing for pi to render. The middle ground is real and now proven, though: if I ever stand up a local-deep mode for harder offline work, --reasoning auto --reasoning-budget 1024 is a configuration I have watched stay out of the ditch. It just wants its own server on its own port, because --reasoning off is a hard gate you cannot toggle back on per request.

What it actually does, measured on the M1 Pro:

Metric	Result
Generation	34–36 tok/s (predicted half of Kyle’s 72, got it)
Prompt ingestion	77 tok/s
Time to first token	~376 ms
MTP acceptance	~65 % (e.g. 1350 of 2090 drafted tokens accepted)

Half the bandwidth, half the tokens, just as predicted. The MTP acceptance beat what I feared. The article saw +24 % on a dense workload; here, two thirds of the drafted tokens landed.

How I Actually Use A Fast Model

A fast model in pi is not the thing I have a conversation with. It is the model that does the small, high-volume, latency-sensitive jobs around the edges of the real work, where Opus is overkill and the round-trip cost is what matters. Those are the jobs I would rather keep on my own machine, and the place where 36 tokens per second is plenty.

In my setup, that means:

/answer and Ctrl+. — a small pi extension I run that grabs the last assistant message when it ends on a batch of clarifying questions, extracts them into structured JSON via a side LLM call, and opens a TUI so I can answer them one at a time. The extraction is a contained, schema-shaped task, the sort of thing a fast model handles well. It defaults to claude-bridge/claude-haiku-4-5 and is configurable at ~/.pi/agent/extensions/answer.config.json, the line I now point at local.
Branch summaries and compaction. When I navigate away from a branch on /tree, or a session outgrows its context window, pi summarizes the work to carry forward. By default those calls run on the active session model, which means a /tree hop can cost an Opus summary. A small extension I run reroutes both to whatever the fast mode points at, so the throwaway housekeeping never touches the expensive model.
/mode fast for the genuinely small questions, the “what’s the flag for X” and “rename this” and quick grep-and-explain ones, where I switch the whole session to the fast slot and switch back.

None of these need a frontier model. They need something that responds now and gets the structure right. That is the bar Gemma 4 has to clear to take the slot from Haiku.

So I gave it the slot. I went back and forth here. The cautious move was to add a separate local mode, keep fast on Haiku, and switch into the local one when I felt like testing it. I know how that goes: I would never remember to switch, and a week later I would have no data. So fast now points at Gemma 4 and the Haiku mode moved to lcl, there if I want to compare. Local models can be brilliant in a chat window and brittle inside an agent loop, as the thinking spiral already showed, and the only way I learn which one Gemma 4 is here is by living with it in the slot that fires twenty times a day. If it holds up, on tool calling, on diff quality, on the ten-line edits that fill my day, it stays. If it does not, the rollback is one line in modes.json.

What I Am Not Doing Yet

I am not putting the server behind launchd. At ~22 GB resident on a 32 GB machine, leaving it running alongside Chrome and an IDE is asking for swap. On-demand lcl start / lcl stop is honest about the cost in a way always-on is not.

I am not running a second model on a second port. Maybe Qwen 3.6 35B-A3B earns a slot for the cases where Gemma is too weak. Maybe one model is enough. I will know in a week.

What the Planning Helped With

The model researched the options; I chose the setup. The conversation made me write down why I chose each part, so I can refer back to it later.

I still need to see how the local model handles everyday work. If it does not hold up, I can switch the slot back.

How I Optimized My Zsh Startup Time

Mon, 11 May 2026 00:00:00 +0000

My zsh prompt was taking close to a second to appear on a fresh terminal. Not catastrophic. But you feel it every time tmux spawns a new pane, and for me that is constantly. The config had grown for years, one eval and one plugin at a time, and nobody had been auditing it, least of all me.

What follows is the audit, and the eight things I changed. The numbers are estimates, not measurements, and I will say so again at the end.

Measure first

Before I touched anything, I measured. Two tools did the work:

# Cold-start benchmark (run a few times, watch the variance):
for i in {1..5}; do time zsh -i -c exit; done

# In-shell flamegraph:
# 1. Uncomment `zmodload zsh/zprof` at the top of .zshrc
# 2. Add `zprof` at the bottom
# 3. Open a new shell
zprof | head -40

zprof is the one that helped most. It prints which function calls and evals are burning time, sorted by self-time and call count. That is enough to stop guessing.

1. Stop forking `brew --prefix` five times per shell

My macOS config had this:

export PATH=$(brew --prefix coreutils)/libexec/gnubin:$PATH
export PATH=$(brew --prefix findutils)/libexec/gnubin:$PATH
export PATH=$(brew --prefix gnu-sed)/libexec/gnubin:$PATH
export PATH=$(brew --prefix grep)/libexec/gnubin:$PATH
export PATH=$(brew --prefix curl)/bin:$PATH

Five forks of brew, which is a Ruby program, on every shell, just to resolve paths that always end up under ${HOMEBREW_PREFIX}/opt/<formula> anyway. Each fork is about 35 ms on Apple Silicon, so that is roughly 180 ms gone before I have typed a single character.

Fix:

_brew_opt="${HOMEBREW_PREFIX:-/opt/homebrew}/opt"
[ -d "$_brew_opt" ] || _brew_opt="/usr/local/opt"
export PATH="$_brew_opt/coreutils/libexec/gnubin:$_brew_opt/findutils/libexec/gnubin:$_brew_opt/gnu-sed/libexec/gnubin:$_brew_opt/grep/libexec/gnubin:$_brew_opt/curl/bin:$PATH"
unset _brew_opt

A path-prefix lookup costs nothing. The /usr/local/opt fallback is there for Intel macOS, where HOMEBREW_PREFIX may be unset, for example in bash without brew shellenv.

Saves about 180 ms.

2. Defer plugins with zinit’s `wait` ice

If you use a plugin manager, this is probably the biggest single win on the table. Syntax highlighting, autosuggestions, history-substring-search, completion add-ons: none of these need to load before the first prompt renders. They only need to be there by the time you type something.

With zinit’s wait ice, you defer them until after the first prompt:

zinit wait lucid light-mode for \
 atinit"ZINIT[COMPINIT_OPTS]=-C; zicompinit; zicdreplay" \
 zdharma-continuum/fast-syntax-highlighting \
 atload"_zsh_autosuggest_start" \
 zsh-users/zsh-autosuggestions \
 blockf atpull'zinit creinstall -q .' \
 zsh-users/zsh-completions \
 atload"bindkey '^[[A' history-substring-search-up; bindkey '^[[B' history-substring-search-down" \
 zsh-users/zsh-history-substring-search \
 wfxr/forgit

The atinit ice on the first plugin runs compinit once and replays cached completions via zicdreplay. One compinit covers every turbo-loaded plugin. The atload"_zsh_autosuggest_start" line re-initializes autosuggestions after deferred loading. Without it the plugin silently no-ops, which took me an embarrassing amount of time to work out.

Saves 100-300 ms.

3. Compile `.zcompdump` to bytecode

compinit parses thousands of completion functions on every startup. Compiling its dump file to bytecode means subsequent shells skip the parser:

zcompdump="${ZDOTDIR:-$HOME}/.zcompdump"
[[ -s "$zcompdump" && (! -s "${zcompdump}.zwc" || "$zcompdump" -nt "${zcompdump}.zwc") ]] \
 && zcompile "$zcompdump"

It recompiles only when the source is newer than the cached .zwc. Saves 30-80 ms.

4. Pick one version manager

I had both fnm and mise active, which is one more than anyone needs. Mise manages everything I actually use, Node, Python, Go; fnm env in .zshrc was a leftover that nothing depended on. Deleting it saved another 30-80 ms per shell.

Mise itself has a second optimization, --shims mode:

eval "$(~/.local/bin/mise activate zsh --shims)"

Default mise activate installs a precmd hook that runs on every prompt to keep tool versions in sync with .mise.toml. Shim mode replaces that hook with symlinks on PATH that resolve the right version the first time you call each tool. That is about 17 ms saved at startup, paid back as 10-30 ms on the first invocation per shell. For interactive use it is a fine trade.

5. Cache the slow `eval`s

A lot of tools want you to run eval "$(tool init zsh)" at startup. Each one forks the tool, runs its setup, and pipes the result back. You pay that cost every shell, even though the output rarely changes between runs.

A small helper fixes it:

_cache_eval() {
 local name=$1; shift
 local cache=~/.zsh/cache/$name.zsh
 [[ -s $cache && $cache -nt ${commands[$1]:-/dev/null} ]] \
 || { mkdir -p ~/.zsh/cache; "$@" > $cache; }
 source $cache
}
_cache_eval zoxide zoxide init zsh --cmd j
_cache_eval uv uv generate-shell-completion zsh

The $cache -nt ${commands[$1]:-/dev/null} test compares mtimes. When brew or mise upgrades the binary, the cache invalidates on its own. No stale-cache surprises after a brew upgrade.

Keep starship init zsh eager. You need it for the prompt anyway, and it is already fast.

Saves 50-100 ms.

6. Audit plugins; cut what you don’t use

I was loading the Oh My Zsh git plugin via zinit’s snippet feature. The plugin ships roughly 150 aliases.

So I grepped my last few months of shell history against its alias list. Five OMZ-only aliases came back: gsw, glo, gf, gclean, gss. Everything else I either did not use or had already redefined to my own taste. I copied those five into shell/.aliases and dropped the OMZP::git snippet from zinit.

There is a second reason to do this, and it has nothing to do with startup time. Because the OMZ plugin loaded in turbo mode, after my eager shell/.aliases, it was quietly overwriting aliases I had defined myself. My gc='git commit -m' was getting clobbered to git commit --verbose, and gg='lazygit' to git gui. The plugin “worked” because turbo-loaded aliases land before you type, but the behavior was not the one I had configured. Dropping the plugin put my own aliases back in charge.

While I was at it I found zsh/.zsh/plugins/git/git.plugin.zsh in my dotfiles, 150 lines of git aliases, sourced from nowhere. Years of dead code I had been carrying around. Gone.

7. Move PATH and env to `.zshenv`

.zshrc runs only for interactive shells. If you set PATH there, then cron jobs, zsh -c "command" invocations, and IDE-spawned non-interactive shells do not see your tools. That is how you end up burning half a day on “works in my terminal, breaks in CI.”

The right home is .zshenv, which runs for every zsh invocation:

# ~/.zshenv
export PNPM_HOME="$HOME/Library/pnpm"

typeset -U path PATH # auto-dedupe
path=(
 "$HOME/.local/bin"
 "$PNPM_HOME"
 $path
)

[ -f "$HOME/.cargo/env" ] && . "$HOME/.cargo/env"

typeset -U path PATH ties the path array to the PATH scalar and deduplicates automatically. No more 8 KB PATH strings with the same entry six times because nested shells kept prepending.

This is not a cold-start win, since .zshenv still runs. It is a correctness fix. A shorter PATH does make command lookups faster, so you get a little of both.

8. Fix the things you didn’t know were broken

While I was in there, zprof and a slow re-read of the config surfaced a stack of small bugs that had nothing to do with cold start. They were just wrong:

~/.profile was being sourced twice, once from .zshrc and once from .zshenv. 20-80 ms of pure waste.
compinit’s cache-staleness check had inverted-looking logic and a misleading comment. It happened to do the right thing, but only by accident.
zsh/.zsh/lib/completions.zsh referenced $ZSH, an Oh My Zsh leftover that was unset in my setup. The completion cache-path was silently expanding to /cache/, the filesystem root. Nothing got written there because the directory was not writable, so completions had no cache at all. Caching had quietly been off the whole time.
compdef calls from eager tool initializations were arriving before turbo-mode compinit had run, so completions for those tools were not registering. I fixed it with a small shim that queues the calls until compinit is ready:

if ! (( ${+functions[compdef]} )); then
 typeset -ga __deferred_compdefs
 compdef() { __deferred_compdefs+=("${(j: :)@}") }
fi

Then in the turbo block’s atinit, after zicompinit; zicdreplay:

(( ${#__deferred_compdefs} )) && \
 for c in "${__deferred_compdefs[@]}"; do eval "compdef $c"; done
unset __deferred_compdefs

None of those moved the startup number. They were still bugs, and now they are not.

Doing this on your own config

Measure before you touch anything. time zsh -i -c exit for cold start, zprof for the in-shell breakdown. Skip that step and you will spend an afternoon optimizing the wrong thing. I have done exactly that.

Then grep your shell history against the alias and function lists of whatever plugins you load. You will usually find you are loading hundreds of definitions to use a handful.

Defer what can be deferred. First-prompt latency is what you feel, and almost nothing actually has to load before you can type. Cache expensive evals whose output only changes when the binary changes, and key the cache on the binary’s mtime so upgrades invalidate it for you. Hardcode the constants: brew --prefix coreutils is always ${HOMEBREW_PREFIX}/opt/coreutils. Forking a Ruby program to ask is silly.

And keep environment variables in .zshenv, not .zshrc. Future-you, debugging why something works in iTerm but not in a cron job, will be grateful.

Estimated total

Change	Savings
Stop forking `brew --prefix` × 5	~180 ms
Defer plugins with `zinit wait`	100-300 ms
Cache remaining `eval`s	50-100 ms
Compile `.zcompdump`	30-80 ms
Drop `fnm` (mise covers it)	30-80 ms
Total	~400-700 ms

These are estimates, not measurements. Your actual numbers depend on your hardware, your plugin set, and how much cruft you had accumulated over the years. Under 200 ms on Apple Silicon is doable with stock zsh and a small, well-deferred plugin set.

My dotfiles, with all of this applied, are at github.com/theskumar/dotfiles. The zsh/OPTIMIZATION.md file there is the running log of what is done and what is still open.

I plan to repeat the audit as the config changes.

FluidVoice

Sun, 12 Apr 2026 12:00:01 +0000

FluidVoice with paraquet v2 is soemthing i’ve been using now as my default speech-to-text on Mac, after evaluating WisperFlow, Handy and VoiceInk.

thaw

Sun, 12 Apr 2026 12:00:00 +0000

thaw a fork of Ice. I’m switching to it, as Ice seems to the inactive now.

Handy

Thu, 12 Feb 2026 12:00:00 +0000

Handy Looks like a promising tool for to replace WisperFlow and VoiceInk for speech to text conversion. via

VoiceLink

Mon, 12 Jan 2026 12:00:01 +0000

Learnt about VoiceLink, an alternative to [Wispr Flow] that have been using as my STT software, with it’s pricing model VoiceLink might be better replacement if it performs as good as WisprFlow

New tools

Sat, 20 Dec 2025 12:00:00 +0000

New tools:

gh-actions-lockfile to generate and verify lockfiles for gh-actions
Proxyman is more user-friendly http debugging proxy than Charles Proxy on MacOS