The best terminal for a Mac: what to compare before you switch

Every list of the best terminal for a Mac puts the same five or six names in a slightly different order, and none of them can tell a reader which one to use, because the answer depends on work the list knows nothing about. Someone who lives in one long-running ssh session and someone who opens twelve shells a day across four projects are not choosing the same tool, even though they are typing the same query.

What can be established is the shape of the decision: which properties genuinely differ between these programs, what each one actually costs, and what a switch costs afterwards. That last figure is the one the rankings never quote, and it is usually the one that decides whether a switch sticks.

Start from what already ships

Terminal.app is the baseline, and it is worth knowing what the baseline includes before replacing it. The version in macOS 27 is Terminal 2.15, and it is not the bare program its reputation suggests.

It has profiles, so appearance and startup behaviour can be saved per context and opened deliberately rather than configured once and forgotten. It has tabs. It has split panes. It has marks, which let a long scrollback be divided at meaningful points and navigated between, and which very few people who complain about scrollback know exist.

What it does not have is a text file for configuration, a GPU based renderer, or any concept of a session that survives a restart. If none of those three matter to the work, the honest conclusion is that a replacement will change the look of the screen and not much else. Establishing that first is cheaper than installing three alternatives and forming an impression.

The five properties that actually differ

Strip the feature lists down and the real variation sits in five places.

Rendering is the first. Programs including Ghostty, kitty, WezTerm and Alacritty draw text through the GPU. The visible result is smoothness while scrolling large output, which matters if builds and logs stream past regularly and is close to invisible if the work is mostly reading and typing single commands.

Configuration format is the second, and it has longer consequences than it looks. A terminal configured through a text file can be committed to a dotfiles repository and reproduced on a new machine in one command. A terminal configured through preference panes cannot, which means the setup has to be rebuilt by hand each time. For anyone who has replaced a Mac in the last few years, this is the property that pays back.

Session model is the third. Some of these can restore panes and running layouts after a restart, and some cannot. For work organised as several long-lived contexts, that removes a manual setup ritual every morning. For work that is a single shell at a time, it is irrelevant.

Shell integration is the fourth. Features that mark where each command started, jump between them, and report exit status require the terminal and the shell to cooperate, usually through a script sourced from the shell configuration. This is where the day to day comfort lives, and also where most of the setup effort goes.

Licence and funding model is the fifth, and it is a practical matter rather than a philosophical one. It determines whether the program can be installed on a work machine without asking anybody, and whether a feature can disappear behind a subscription later.

What each of the common choices actually is

The facts below were read from each project's own site or repository in September 2026. Prices and versions change, so treat them as a starting point rather than a settled answer.

Terminal	Licence or price	Latest confirmed	Notes
Terminal.app	Included with macOS	2.15 on macOS 27	Profiles, tabs, split panes, marks. No text config file
iTerm2	GPL v2, free	3.7.3, built 22 September 2026	Requires macOS 10.14 or newer. Longest feature list of the group
Ghostty	MIT, free	v1.3.1	GPU rendering, text configuration, native macOS interface
kitty	GPL v3, free	Actively released	GPU rendering, text configuration, its own extension mechanism
WezTerm	MIT, free	Actively released	GPU rendering, configured in Lua, multiplexing built in
Alacritty	Apache 2.0, free	v0.17.0, April 2026	Deliberately minimal. No tabs or splits of its own
Warp	Free tier, then from 20 US dollars per month	Current release	Free tier includes the terminal. Paid tiers buy agent usage

Alacritty's row deserves a note, because its omissions are a design position rather than a gap. It leaves tabs and splits to a multiplexer such as tmux, on the reasoning that the job belongs there. For someone already running tmux, that is one less overlapping layer. For someone who is not, it means the terminal alone will not organise the work.

The cost question moved from the terminal to the agent

A comparison written three years ago would have treated price as a footnote, since nearly everything in this category is free software. That is no longer the whole picture, because the paid tiers in this space are now selling AI usage rather than terminal features.

Warp is the clearest example, and its pricing page states the structure plainly. The Free tier costs nothing and includes the terminal itself along with limited agent access. Build starts at 20 US dollars per month and includes 1,500 credits, described as 20 dollars of agent usage at API rates. Max is 200 dollars per month for 18,000 credits. Business is 50 dollars per user per month for up to 25 seats, adding team usage metrics, administrator controlled data settings and SAML based single sign on. Annual billing takes 10 percent off each figure, bringing Build to 18 dollars and Business to 45 dollars per user.

Read the structure rather than the headline number. What is being bought is metered model usage with a terminal attached, which means the monthly cost tracks how much the agent is used rather than being fixed. For anyone already paying for a coding agent separately, the question is whether that usage should be bought twice. For anyone not paying for one at all, the free tier is a terminal at no cost and the comparison with the others is on features alone.

Three different readers ask this one question

The reason no ranking can be correct is that the query comes from at least three unrelated situations, and the right answer differs in each.

The first is someone whose terminal is a place to run a handful of commands between other work. Here the requirement is that it starts fast, looks legible, and never needs attention. Terminal.app satisfies that, and the effort of configuring an alternative is spent on a problem that is not being felt.

The second is someone whose terminal is the working environment: several long-lived sessions, remote hosts, editors running inside it, output streaming for minutes at a time. This is where text configuration, session restore and GPU rendering all pay for themselves, and where the setup effort is recovered within days.

The third is someone driving an AI agent from a command line most of the day. For that pattern the terminal itself is nearly incidental, and the questions that matter are where the model runs, what it costs per month, and how close the conversation sits to the files being changed. Comparing rendering speed here answers nothing.

A one week test that produces an answer

Trials fail because they measure first impressions. A test that produces a decision has a fixed shape and takes a week of ordinary work.

Install one candidate, not three, and make it the default for the whole week. Bring across only the keyboard shortcuts actually used daily rather than rebuilding an entire configuration in advance, since half of them will turn out to be habits rather than needs.

Inside that week, deliberately do four things: open a long ssh session to a real server and run a full screen program inside it, watch one long build scroll to completion, restart the Mac and see what the terminal restores, and set up the whole configuration from scratch on a second machine or a fresh user account. Those four cover the properties that differ. Everything else is preference, and preference is settled by using the thing rather than by reading about it.

Write down which of the four went better and which went worse. A switch justified by one clear improvement will hold. A switch justified by a general sense of improvement gets reverted within a month.

The switching cost nobody prices in

Here is the part the rankings leave out, and it is measurable rather than a matter of taste.

Every terminal announces itself to programs through the TERM environment variable, and the receiving system has to recognise the name. On a current macOS install, the system terminfo database can be checked directly.

infocmp xterm-kitty

On macOS 27 that returns an error, because the entry is not present. The same is true for xterm-ghostty and for alacritty. What the system does have is xterm-256color, which is what Terminal.app and iTerm2 use.

This matters the moment an ssh session opens. Log into a server whose terminfo database does not know the local terminal's name, and full screen programs start behaving oddly: less scrolls wrong, an editor draws its interface in the wrong place, key sequences arrive as literal characters. None of it is broken exactly, and all of it costs time. The fixes are known, including copying the terminfo entry to the remote host or overriding TERM for that connection, but they are work that has to happen on every server touched.

The rest of the switching cost is the ordinary kind. Key bindings built up over years have to be found again in different names. Shell integration has to be reinstalled. Colour schemes have to be rebuilt. None of this is difficult and all of it lands in the same week, which is why so many switches quietly revert.

The way to keep the cost honest is to run the candidate for a full working week, including at least one long ssh session into a real server, before uninstalling anything. A ten minute trial measures the appearance of the window and nothing that matters.

The window matters more than the terminal

After all five properties have been compared, the thing that changes the day most is not which terminal draws the text. It is how far the terminal sits from the files being worked on and from the assistant being asked about them.

A shell in one application, a file browser in another, and an AI tool in a third means every task that touches all three includes window switching, and the count adds up faster than any rendering difference saves. Keeping the folder, the shell and the AI in one window removes that, which is the point Atriens is built around. How that compares with the split-application approach is set out in Compared with other file managers, and the pricing is on Pricing.

Before installing anything, check whether Terminal.app's profiles and marks already cover the complaint. If the real need is a text configuration file that follows a new Mac, that narrows the list immediately. If it is smooth scrolling through large output, that narrows it differently. The ranking was never the answer, because the requirement was never stated.