10 Terminal Tools I Keep Coming Back To

Photo by Matt Seymour on Unsplash

My Terminal setup has gotten less romantic with time.

I used to care more about whether it looked clever. These days I mostly care whether it gets me back to the command I ran yesterday, opens a repo without fuss, cleans up a Python project, or keeps an AI coding session from turning into a pile of repeated logs.

That’s a boring standard, but it’s the one that actually filters the list.

Some tools are fun for a week. Some look good in screenshots. Some make a setup feel busy without making the day any easier. The ones that stay usually do one job well enough that I stop thinking about them.

This is the current group I keep reaching for: Atuin, Pure, Neovim, uv, Ruff, ty, Homebrew, FFmpeg, Headroom, and Hermes with build.nvidia.com.

I’m leaving out the basics on purpose. Git, SSH, the shell itself, and the usual Unix commands are assumed. This is more about the tools I’ve added around the baseline because they fixed some real annoyance in how I work.

1. Atuin

Shell history is one of those things that feels fine until you need to find something from more than a few minutes ago.

I’ll remember that I fixed a build issue last week. I’ll remember that a command had three flags and one of them was the part that made it work. I’ll remember the project, or maybe just the shape of the problem. What I won’t remember is the command itself.

Atuin makes that search less painful.

Instead of treating shell history like a long scrollback file, it gives me a better way to search what I’ve already run. That includes commands from older sessions and commands tied to a directory. The directory part is useful because my memory for commands is often tied to the repo. I don’t think, “What was the exact command?” I think, “I ran that in the Gymphant project when the build number script was acting weird.”

That’s the difference Atuin makes for me. It turns history into something closer to a working record.

I use it most when I’m trying to recover a command that worked once and then disappeared into the day. A weird ffmpeg line, a Homebrew command, a test invocation, a one-off script, a command passed through Headroom, or something I ran while debugging an agent session. I don’t want to reconstruct all of that from scratch.

Atuin also changes how willing I am to experiment in the shell. If a command works, I know I can find it again. If it doesn’t, that failure is also part of the record.

That’s useful in a very plain way.

2. Pure

A prompt can get annoying fast.

There’s a version of Terminal customization where every line becomes a status dashboard. Current directory, Git branch, package version, cloud account, runtime, battery, time, icons, colors, nested symbols, and then a prompt character at the end asking you to pretend all of that was helpful.

I don’t want that anymore.

Pure gives me enough information without filling the screen with itself. I can see where I am. I can see Git state. I can see whether the last command failed. If something took a while, I get a timing hint. Most of the time, that’s all I need.

The part I like is that Pure doesn’t make me study the prompt before I run the next command. I don’t need a miniature control panel at the start of every line. I need a calm signal that says, “You’re in this directory, this repo has changes, and the last command didn’t exit cleanly.”

That has made my shell feel a little less crowded.

I still tweak other parts of the Terminal. Fonts, colors, aliases, keybindings, completion, all of that changes. Pure has stayed mostly because it doesn’t ask for attention unless something worth noticing happened.

That’s a good prompt.

3. Neovim

Neovim is where the Terminal stops being a launcher and becomes the place where I can actually work.

I like having the editor close to the commands. I can open a repo, inspect files, make a change, run a test, jump back into code, fix the next thing, and keep the loop in one place. That sounds small, but it affects the way I work. I’m less likely to break concentration when editing doesn’t require moving into a separate app with its own idea of the project.

Neovim can become heavy if you let it. Mine has enough structure to be useful without turning the editor into a second operating environment. I want language server support, search, diagnostics, formatting, Git signs, fuzzy finding, and a fast way to move through files. I don’t want every plugin decision to become a hobby.

The tool fits well with AI-assisted coding too. When an agent changes files, I want to inspect the patch myself. When tests fail, I want to move from the error to the source quickly. When an agent gets too broad, I want the editor open so I can cut the work back down to the actual files involved.

Neovim also makes rough work easier. I can open a script that only needs two edits. I can change a markdown file. I can inspect a generated file without launching a heavier editor. The low overhead means I use it for more than planned coding sessions.

That’s why it keeps its place. It lets me stay close to the repo instead of orbiting around it.

4. uv

Python setup used to take up too much room in my head.

There were too many small choices before I could do the actual work. Should this be a venv? Should I use Poetry? Is this a quick script? Do I need a lockfile? Which Python is active? Did I install that package globally last month and forget? Why is the environment already weird before the code exists?

uv cleans up a lot of that.

The speed is the obvious part, but the bigger change is that starting a Python project feels less scattered. I can create the environment, add dependencies, run scripts, and keep the project shape understandable. It’s also easier to explain to an agent. That counts now. If a repo has clear commands, AI tools tend to behave better. If setup depends on a half-remembered local habit, they guess.

I use uv when I want Python to feel less like a pile of side decisions. That includes small tools, scripts inside app repos, experiments, and project setup I may need to repeat later.

It also pairs nicely with the rest of the Astral stack. uv handles the project and environment side. Ruff handles cleanup. ty gives type feedback. That combination has made Python feel more practical in my Terminal again.

Not perfect. Just less annoying.

That’s enough.

5. Ruff

Ruff is the Python cleanup tool I actually run because it’s fast enough that running it doesn’t feel like a separate event.

That sounds like a small thing, but it changes behavior. Slow tools get delayed. Noisy tools get ignored. Tools with too much setup become something you only run when you’re already trying to be responsible. Ruff is fast enough to sit inside the loop.

I use it for linting and formatting because I don’t want five little Python tools arguing over the same file. I want imports cleaned up, obvious mistakes caught, style made consistent, and the command to finish before I lose the thread.

It’s especially helpful with AI-generated code. Agents can produce a lot of code quickly, but the first draft often has rough edges. Ruff gives me a cheap first check before I spend human attention reading everything line by line. It won’t tell me whether the idea is right. It will catch enough of the careless stuff that review starts from a better place.

That’s the right level of trust for a tool like this.

Ruff doesn’t replace judgment. It removes a layer of cleanup I don’t want to do by hand.

6. ty

Python lets you move quickly, which is useful until your own assumptions start hiding in the code.

A script grows when a helper function gets reused, and before long the shape of a dictionary is implied instead of written down. A return value can be None, while the rest of the file keeps acting like it can’t. That kind of problem is easy to miss while the code still feels small.

ty gives me another check without making the work feel heavy.

I’m interested in it because it comes from Astral, and Astral’s tools have been good at the part I care about: fast feedback from the command line and editor. uv and Ruff already fit that pattern. ty extends it into type checking and language server work.

I don’t want type checking to turn every small Python file into a formal project. I want it to catch places where the code disagrees with itself. That might be a bad argument type, a value that could be missing, a refactor that didn’t reach every call site, or a function that returns something different from what the rest of the code expects.

It’s also useful when an agent is editing code. Types give the agent less room to invent. They make the edges of a function more visible. The agent can still make a bad decision, but it has fewer excuses.

ty is still newer in my stack than Ruff. I’m using it where the feedback helps and not forcing it into places where it would slow down a quick scratch file.

That’s probably the right way for me to adopt it.

7. Homebrew

Homebrew is the part of the setup I don’t think about much until I’m on a new machine or something breaks.

That’s usually a sign that a tool is doing its job.

On macOS, Homebrew gives me a normal way to install and update command-line tools. I don’t have to remember where every binary came from. I don’t have to keep a mental list of install pages. If I need a tool, Homebrew is usually the first place I check.

It also makes my setup easier to rebuild. That has become more important as my Terminal setup has gotten more specific. I don’t want a machine that only works because I manually assembled it over three years and forgot the steps. I want enough of the setup to be recoverable.

Homebrew isn’t exciting in daily use. Most of the time it’s just brew install, brew upgrade, or brew info. That plainness is part of why I like it. It’s infrastructure, not a personality.

It also keeps experimentation low-cost. I can try a CLI, keep it if it helps, remove it if it doesn’t, and avoid turning every tool trial into a permanent scar on the system.

There are other ways to manage a Mac setup. This is the one that has kept working for me.

8. FFmpeg

FFmpeg is the command I reach for when a media file refuses to behave.

That happens more often than people expect. A screen recording is too large. A video needs to be trimmed. Audio needs to be pulled out. A file needs to be converted before it works somewhere else. A quick demo clip needs compression before it can be uploaded. A phone recording needs to become something usable for an article, app preview, bug report, or support message.

I’m not doing professional video editing in the Terminal. I’m doing the annoying file work around the edge of other tasks.

FFmpeg is good at that.

The commands can be ugly. I still search old commands constantly. That’s where Atuin helps. Once an FFmpeg command works, I don’t want to rediscover it. I want to pull it back up, change the input and output names, maybe tweak a bitrate or trim range, and move on.

A GUI app can solve some of these problems. FFmpeg gives me a recipe I can reuse.

That’s the part I care about. Media cleanup becomes something I can repeat, script, and adapt instead of another tiny manual project.

9. Headroom

Headroom is here because AI coding sessions can get messy in a way that older Terminal work didn’t.

When I use an agent, the session can fill up with logs, file reads, command output, repeated explanations, failed attempts, diffs, test results, and stale context from three steps ago. At first that feels normal. Then the model starts carrying too much junk. The session gets slower, the answers get fuzzier, and the useful parts of the task are buried under everything that happened before.

Headroom is meant for that problem.

It wraps agent commands and compresses context before it reaches the model. That’s useful because the model doesn’t need every line of every output. It needs the parts that help it make the next decision. Long logs and repeated boilerplate can waste space without adding much.

I like Headroom because it treats context as something you have to manage, not as an invisible bucket you can keep filling.

That’s been one of the harder lessons with agents. The quality of the session depends on what gets carried forward. A repo summary can help, and so can a focused error log. A giant unfiltered dump usually does the opposite: it gives the agent more to carry without giving it much to use. You still need small tasks, clear prompts, and review. Headroom doesn’t remove that responsibility. It makes the cleanup less manual.

I use it when I expect a session to run long or when the tool output is going to be noisy. It’s not something I need for every command. It’s something I’m glad to have when an agent starts eating the room.

10. Hermes with build.nvidia.com

Hermes is the newest and least boring part of this list.

I’m using it with build.nvidia.com because I want an agent setup that can point at different model backends without making the Terminal workflow feel completely different each time. NVIDIA’s build platform gives access to model APIs, and Hermes can work with OpenAI-compatible endpoints. That combination makes it possible to run agent work from the shell while keeping the model side more flexible.

I’m still forming my opinion on where it fits.

Right now, I see Hermes as part of the agent layer of my Terminal setup. It’s closer to a working CLI agent than a single prompt box. The appeal is that it can sit near the repo, near the commands, and near the same environment where I’m already editing, running tests, and checking output.

That’s important because I don’t want every AI task to move into a browser tab. Some tasks belong next to the files. Some need shell access. Some need a tool that can run commands, inspect output, and keep going through a task without me turning the whole process into copy and paste.

Hermes isn’t as settled in my setup as Homebrew, Neovim, or FFmpeg. It needs more judgment. It’s also part of the area that changes the fastest. I’m comfortable saying that plainly. I use it because it gives me another way to bring agent work into the Terminal, not because the setup is finished.

That’s where I am with it.

How I Actually Use Them Together

The tools don’t all show up at the same time.

A normal coding session might start with Pure showing me I’m in the right repo. Atuin helps me recover the command I used last time. Neovim opens the project. uv handles the Python environment if the repo needs it. Ruff and ty give quick feedback before I commit to reading every change myself.

If media shows up, FFmpeg handles the file work. If the session turns into agent work, Headroom can keep the context smaller, and Hermes can bring the agent closer to the Terminal instead of forcing everything into a chat window.

Homebrew sits under a lot of this. It’s the reason installing and updating these tools doesn’t become its own chore.

That’s the practical shape of the setup. It’s not a clean theory. It’s a bunch of tools that survived repeated use.

I don’t keep them because they make the Terminal look better. I keep them because they reduce the number of times I have to stop and rebuild momentum.

That’s usually what I want from a tool.

Links

Atuin https://github.com/atuinsh/atuin https://atuin.sh/

Pure https://github.com/sindresorhus/pure

Neovim https://github.com/neovim/neovim https://neovim.io/

uv https://github.com/astral-sh/uv https://docs.astral.sh/uv/

Ruff https://github.com/astral-sh/ruff https://docs.astral.sh/ruff/

ty https://github.com/astral-sh/ty https://docs.astral.sh/ty/

Homebrew https://brew.sh/ https://github.com/Homebrew/brew

FFmpeg https://ffmpeg.org/ https://github.com/FFmpeg/FFmpeg

Headroom https://github.com/chopratejas/headroom

Hermes Agent https://hermes-agent.nousresearch.com/ https://github.com/NousResearch/hermes-agent https://hermes-agent.nousresearch.com/docs/

NVIDIA build platform https://build.nvidia.com/ https://build.nvidia.com/models https://developer.nvidia.com/nim