hitesh

Posted on Jun 7

I Made My Terminal 7.5x Faster by Deleting the Tools Everyone Tells You to Install

#ai #terminal #vibecoding

My shell took 2 seconds to start. Then I realized an AI agent was paying that tax hundreds of times a day.

For fifteen years the advice was settled: install oh-my-zsh, add some plugins, get autosuggestions and a pretty git-aware prompt. It made the terminal nicer to sit in front of. That assumption — a human, sitting, typing, one command at a time — is now wrong most of the time.

On my machine, the overwhelming majority of terminal commands are issued by AI agents, not me. And once that flips, every plugin you installed for human comfort turns into a tax the machine pays on your behalf, over and over.

I profiled my own setup and cut shell startup from 2.05 seconds to 0.27 seconds — roughly 7.5x — by deleting tools that added zero value to an agent workflow. Here's what I found, why it matters more now than ever, and how to audit your own machine.

The thing nobody tells you: agents don't reuse your shell

When you work in a terminal, you open it once. Your ~/.zshrc runs a single time, you pay the startup cost once, and then you type into that warm session for hours. If sourcing oh-my-zsh costs 600ms at launch — who cares. You paid it at 9am and forgot about it.

AI agents don't work that way. An agent that runs terminal commands typically spawns a fresh shell process per command (or per small batch). There's no long-lived session it's lovingly curating. It runs git status → shell starts → sources your full init → runs the command → exits. Then it runs bun install → a brand new shell starts → sources your full init again → exits. Every command re-pays the entire startup cost.

Now layer on how modern agentic tools actually operate:

Parallel sub-agents. Complex tasks fan out across multiple agent threads working concurrently — one gathering context, one running tests, one editing files. Each spawns its own shells.
Background processes. Dev servers, watchers, and test runners get their own shell instances.
Retry and verification loops. Run a command, check output, fix, re-run. More shells.

So the cost isn't startup_time. It's:

startup_time × commands_per_task × parallel_agents

That 1.78 seconds I shaved off isn't saved once — it's saved on every shell spawn across every agent thread, all day.

A rough illustration: an agent task that runs 50 commands used to burn ~100 seconds just starting shells before doing any real work. Run three agents in parallel on a big task and you're throwing away minutes of pure init overhead — plus the CPU and battery to do it.

What I found when I profiled it

I used zsh's built-in profiler to see where 2 seconds per shell was going:

# Drop this at the very top of ~/.zshrc temporarily
zmodload zsh/zprof
# ... your config ...
# And this at the very bottom
zprof

Open a new shell and read the table. The results were almost comically lopsided.

Offender #1: The Yandex Cloud CLI's completion script — 827ms (52% of total)

The single biggest cost wasn't even a "plugin." It was the shell-completion script for the Yandex Cloud CLI (yc) — an SDK I'd installed months earlier and stopped using. The function eating the time showed up in the profiler as __yc_bash_source, and the completion file it sourced (completion.zsh.inc) was 9 MB. Every shell launch sourced nine megabytes of bash-compatibility completion logic to enable tab-completion for a command I never typed — and that the agent certainly never typed. The whole SDK was 189 MB sitting in ~/yandex-cloud.

This is the purest form of the problem. Tab-completion helps a human who is typing and pressing Tab. An agent generates the entire command string in one shot from a language model. It will never press Tab. The feature's whole value proposition is irrelevant to the primary user of the shell, yet it was the most expensive thing in the startup path.

Offender #2: The completion framework itself — ~640ms

oh-my-zsh's machinery (compinit, compdump, and ~2,500 compdef calls) accounted for most of the rest. compinit rebuilds a completion cache and runs a security audit over completion directories. Useful if you live in the shell. Dead weight if a model is generating your commands.

Offender #3: Forge's shell plugin

Ironically, a different AI coding tool — Forge (a CLI agent) — had installed its own zsh plugin (commands, completions, keybindings) that ran on every launch via eval "$(forge zsh plugin)" in the hot path. AI tooling adding shell-interactivity features to speed up humans, slowing down the AI tooling that's actually running the commands.

The cleanup, in order of impact

I removed things in descending order of cost, measuring after each step:

Step	What I removed	Startup time
Baseline	—	2.05s
Remove Yandex Cloud CLI (`yc`) + its 9MB completion	source lines + 189MB SDK	0.90s
Remove oh-my-zsh	framework + 14MB install	0.40s
Remove Forge's shell plugin	`eval` block + 33MB binary	0.30s
Remove completion entirely (`compinit`)	I never tab-complete	0.27s

A few details that turn this from "delete stuff" into something you can reason about:

Interactive vs. non-interactive shells matter. History expansion (the ! that breaks commit messages), completion, and prompt theming are interactive features — they only load in interactive shells. The fact that they bit an agent at all confirmed it was launching interactive shells that source ~/.zshrc, which is exactly why trimming the file paid off per-command.

Removing a tool means removing what depended on it. When I deleted oh-my-zsh, Forge's plugin started throwing command not found: compdef — oh-my-zsh had been initializing the completion system, and Forge registered its completions through it. You can't just yank the framework; you either restore the one primitive the dependents need (a lightweight compinit) or remove the dependents too. (I eventually removed both Forge and completion entirely.)

Cache logic is easy to get backwards. The standard "rebuild the completion cache once a day" idiom uses a glob modifier to check the dump's age. I initially inverted it and silently ran the slow audited rebuild on every launch instead of the fast cached path. It looked fine and cost 300ms every time. Profile after you change, not just before.

The principle: optimize for your actual primary user

The mental shift is this: your shell's primary user is now a program, and programs have different needs than people.

A human at a terminal values:

Autosuggestions and tab-completion (you're typing, you want help finishing)
A rich, git-aware, colored prompt (you're reading it constantly)
Syntax highlighting (you're scanning your own input)
History shortcuts like !! and !$ (you're recalling past commands)

An AI agent values:

Fast process startup (it spawns shells constantly)
Non-interactive, non-blocking behavior (it can't press q to exit a pager or type into an editor)
Predictable, literal command parsing (history expansion silently breaking a ! in a commit message just wastes a turn)

Almost none of the human-comfort features help the agent, and several actively hurt it. The pager that opens less on git log and waits for a keypress will hang the agent indefinitely — it sees no output and stalls until timeout. The editor that pops open for a commit without -m waits forever for a human who isn't coming. A glob that errors on no-match aborts a command the agent expected to succeed.

So the same audit that speeds things up also makes the environment correct for an agent:

# Non-blocking defaults — nothing waits for a human
export PAGER=cat
export GIT_PAGER=cat
export EDITOR=true          # a no-op "editor" that exits instantly
git config --global core.pager cat
git config --global core.editor true

# Parse command strings literally
setopt no_bang_hist         # '!' stops triggering history expansion
unsetopt nomatch            # don't error when a glob matches nothing

These aren't speed optimizations exactly — they're "stop the agent from getting stuck and burning tokens recovering from a hang" fixes. In an agentic workflow a blocked command is worse than a slow one: it doesn't just cost time, it costs context and tokens while the model tries to figure out why it got no response, often flailing into other tools.

It's not just the shell — it's the whole IDE surface

The same logic extends past ~/.zshrc.

The file watcher. My editor was watching ~163,000 files, 64,000 of them in node_modules. A file watcher exists so the UI updates when files change — but an agent is constantly changing files and doesn't need a watcher to know it did; it made the change. Excluding node_modules, build output, and caches removes a continuous CPU/memory drain and, crucially, removes event-queue lag that can delay saves.

// settings.json
"files.watcherExclude": {
  "**/node_modules/**": true,
  "**/.svelte-kit/**": true,
  "**/build/**": true,
  "**/dist/**": true,
  "**/.git/objects/**": true
}

The dirty-buffer conflict. Without auto-save, a human's unsaved editor buffer and the on-disk file diverge the moment an agent edits that file directly. You get a "save / revert / overwrite" conflict prompt — and the agent, seeing stale or conflicting content, second-guesses itself and wastes turns. Aggressive auto-save keeps disk and buffer in sync so the conflict never arises:

"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000

This is a pure agent-era failure mode. It literally cannot happen in a human-only workflow where the same person owns both the edit and the save.

How to audit your own setup

Profile, don't guess. zmodload zsh/zprof at the top, zprof at the bottom, open a shell, read the table. The offenders are almost never what you'd assume.
Time it honestly: for i in 1 2 3; do /usr/bin/time -p zsh -i -c exit; done. A lean config is well under 0.3s; over a second means you have a problem.
Delete by impact. Start with the biggest line in the profile. Re-measure after each removal so you know what actually moved the needle.
Remove the dependents, not just the framework. Anything hooked into what you deleted will break loudly or silently. Decide whether you need the primitive or the dependent at all.
Make it non-blocking. Pager → cat, editor → no-op, disable history expansion, don't error on unmatched globs. Correctness for a non-interactive caller, not just speed.
Extend to the IDE. Exclude heavy directories from the watcher and search; turn on auto-save so agent edits never collide with stale buffers.

The takeaway

oh-my-zsh, fancy prompts, and completion frameworks weren't bad tools. They were right for their era — when a human sat in front of one long-lived terminal and the startup cost amortized to nothing. That era is ending. When an AI agent spawns hundreds of short-lived shells across parallel threads, the math inverts completely: a one-time convenience becomes a per-command tax multiplied by your concurrency.

The fix isn't anti-tooling. It's recognizing who your tools are actually serving now. My terminal got 7.5x faster not because of some clever trick, but because I stopped optimizing it for a user who's barely there anymore and started optimizing it for the one doing most of the work.

If a program is typing your commands, build the environment that program needs — fast, non-blocking, and literal — and keep the human-comfort layer for the rare moments you're actually in the driver's seat.

Have you stripped your shell for an agent workflow? What was your biggest offender in zprof? Drop your before/after numbers in the comments.

DEV Community