Forward

Before beginning this piece, I would like to acknowledge a few points. I bring these up both to preempt criticism and allow the reader to understand where I am coming from, but I do not think they should be taken to diminish or discount any of the rest of this.

  • It probably doesn’t really matter what terminal emulator you choose. The overwhelming majority of people using computers day to day, and even most developers, probably aren’t using advanced features. Even more, those who are using advanced features probably already know their tool of choice so well that switching would end up costing them more time than it eventually saves.
  • I am not in that .1% of roles where my choice of terminal emulator is critical to performance. I could do all of my work on the default Konsole or Terminal.app easily enough, if I so chose. I also don’t “live in the terminal” as an object of philosophical fixation; I am just as happy to use a GUI app if it provides a better experience. If that gives you pause in listening to me, be advised.
  • There is more information here than 99% of users will ever want/need. For the vast majority of readers, jumping to either the minimalists section or superlatives would be the best thing, depending on whether you are heavily resource constrained (or just a big fan of minimalism) or not.

Terminals And Their Evaluation

There are a number of criteria on which you can evaluate a terminal emulator: Available platforms, included features, configurability, performance, UX, efficiency, and much more. Common examples of this include a given terminal’s support for various image protocols (iterm, sixel, and kitty), the amount of configuration options and their ease of use, the presence of a built in multiplexing solution, whether they are easily extendable through scripting, etc. In this piece I will conversationally evaluate all of these things, but also include as much objective information as possible. I will do this in part by listing the available platform(s) at the top of each section, and providing a set of benchmarks at the bottom. For this I will use Alacritty’s vtebench tool, the benchmarking “kitten” from kitty (when possible), and testing the terminal’s start time Hyperfine on Linux (I have yet to find a good mac equivalent for the mac exclusive terminals). The machine that I used to run most of these measurements on uses an Intel i7-12700KF CPU at 5.1Ghz, NVidia 3080Ti GPU, 48GB DDR5 RAM, and a 2TB NVME SSD. It runs NixOS for the Linux terminals. For the Mac exclusive ones, I used a 2024 Macbook Pro with an M4 Pro Silicon chip and 24GB RAM. I will make sure to test some of the cross platform options on the Macbook as well to ensure comparisons are reasonably fair. All of these benchmarking comparisons were run using the latest version of these programs available on the unstable branch of nix packages (nixpkgs) on the weekend of April 11th, 2026, or the standard version available in homebrew (in MacOS). Lastly, I will also include RAM utilized while idle. I am not personally a huge believer in the utility of benchmarks in this regard (most terminals are fast enough and consume few enough resources that it won’t really matter), and massive amounts of TTY throughput isn’t necessarily reflective of how we might use them day to day, but they may be useful as a guideline for curious or resource-conscious users.

The Defaults

The following terminals are the ones you primarily use because they come preinstalled on your system. That isn’t to say that they are bad; entire careers have been conducted in Terminal.app, oftentimes by people making a lot more money than me. What it means is that these terminals all share a handful of characteristics that users should keep in mind before committing to using or not using them. These terminals are all relatively lightweight, tend to be a little lighter on the need for configuration, and are extremely unlikely to be abandoned by their developers (the benefit of first party tools). However, they are also universally not GPU accelerated (read: a little slower), less customizable than some other options, and generally behind on cutting age features (usually a drawback to a first party tools).

Konsole

Konsole is the terminal associated with the KDE Plasma desktop environment for Linux. It is one of the best examples of the KDE philosophy ecosystem I can think of; maximal in terms of features, highly customizable (especially for an included terminal app), and altogether attractively designed. As for downsides…there really aren’t many. The real “downsides” of Konsole are more about what it does worse than other options than about anything it does outright wrong. It just isn’t as performant (lacks hardware acceleration), configurable, or efficient as the options I would consider to be the very best, nor does it have any special integrations with the KDE environment that might especially motivate people on that DE to stick with it. In my book, Konsole is a textbook example of “good, but not the best”. I cannot think of a real reason to recommend it to anyone over the very best options, but at the same time it is more than adequate, and could be most peoples’ daily driver without issue.

Link To Benchmarks

xfce4-terminal

xfce4-terminal (xfce-term) is the terminal associated with the xfce Linux distribution, a distro known for being very lightweight and resource un-intensive, targeting older or weaker machines. It is a common choice for those wishing to “resurrect” an old laptop that no longer has the horsepower to run the latest Windows (or heavier Linux distro) effectively. The terminal, then is more or less exactly what one might expect. It is very lightweight, consuming around 30MB of RAM for me whilst idle, among the very lowest of any options that I have tested. It also starts up very quickly, the fastest of any options outside of the Minimalists section. It actually does have image support through the sixel protocol, but does not support the Kitty image protocol or have any hardware acceleration. Of any of the built-in, distro-specific terminals, I have to say this might be my choice for best executed in terms of achieving its goals. As of 2026-04-06, xfce distro uses X11, and the primary competition xfce-term posses in the minimalist space there is against st-term. While st-term is by no means bad, I cannot really say that it is necessarily better than xfce-term. Indeed, I personally do not see the benefits of switching, and if I were on a very weak machine running the xfce distro, this would probably be my terminal of choice.

Link To Benchmarks

Terminal.app

Terminal.app is the default Mac terminal, no doubt familiar to many, if not all readers. It is also the terminal I have probably used the most of any in this piece, having used it for around a year somewhat heavily when I switched to using Mac OS for work. Amusingly, as many other users can attest, a very significant portion of my use of Terminal.app was listening to other Mac users ask “Why don’t you switch to iterm2?” This annoyed me at the time, as I wasn’t particularly interested in bothering with various different terminals, but in retrospect it was a very legitimate question. Terminal.app is configurable in terms of both settings and appearances, but really, it plays the little brother role to both iterm2 and other options in virtually every way. It is less configurable, less performant, less beautiful, and similar in terms of resource consumption. It isn’t awful by any means, but unless absolute stability and desire to install no extra programs are your only real criteria, I don’t really see much of a point to remaining with it. Even for the most die-hard Apple enthusiasts, iterm2 out “Macs” this default Macintosh application. Not recommended.

Link To Benchmarks

Ptyxis

Ptyxis is the terminal currently associated with the GNOME DE for Linux, and it appears as though it will be the terminal of choice for that platform moving forward. For those unfamiliar, this is signficant because GNOME has gone through three terminals (that I know of) in its lifetime: GNOME Terminal (classic, minimalist terminal), GNOME Console (AKA kgx, an intended upgrade to GNOME Terminal that appears abandoned) and now Ptyxis. Of all the terminals that come as defaults with the major Linux distros, this is among the most “modern”, featuring GPU acceleration, highly active development, and a level of customizability really only rivaled by KDE Konsole in this “default Linux terminal” space. Even more, it has a unique hook: the native integration of per-tab container oriented tools and environments. Put simply, each Ptyxis instance (and each individual tab) can be associated with a given container, making switching between multiple containers (or opening new tabs within the same container) a breeze compared to other offerings. While this is not particularly helpful to my personal workflow, I can absolutely see it being relevant to a great number of users. I have to say: I am overall fairly impressed with Ptyxis, and I think it accomplishes what it sets out to do better than most, up there with xfce4-terminal in terms of default terminals meeting their goals.

Best For:

  • Users for whom switching containers is paramount
  • Users very attached to the GNOME environment/toolset

Link To Benchmarks

The Curiosities

These terminals are, for whatever reason or another, not for me, and I do not recommend them. However, that doesn’t mean that I believe they are bad; Indeed, most of them have some kind of hook (thus the name) that might make them interesting to you. Rather, I simply believe that either they possess drawbacks I am unwilling to tolerate or, are mostly or entirely outmoded by other offerings.

Tabby

Please do not use Javascript to write your terminal emulator. Just because you can, does not mean you should.

Cool-Retro-Term (CRT)

CRT is an example of a terminal where I’m not sure if it’s really trying to be a serious entry into the terminal space. CRT is named as such because it attempts to mimic the appearance of a classic cathode ray tube (CRT) television. In that, it succeeds with flying colors. However, as a daily driver terminal, I am just not sure why you might actually use it. It lacks any kind of image support, and while it is hardware accelerated, it still isn’t as fast as a lot of other options. It also lacks the extensive configurability of a lot of its peers. Add that to the fact that the CRT aesthetic is actually much harder to read than standard terminal text, and I can only recommend if you value the retro aesthetic above all else. Still, it may be worth an install just for the sake of having around to look cool.

Link To Benchmarks

Warp

Warp almost merited its own section. It is a very unique case, and I have struggled to evaluate it in comparison to other options. For those who may be unaware, Warp is a terminal focused on integrating LLMs/AI directly into the terminal experience. It markets itself as “the agentic development environment”, and pushes those features hard in all of its promotional material. It is also worthy of note that Warp is a VC backed product rather than an open source project like the other terminals on this list. This suggests it will likely have high development velocity, but also an elevated possibility of becoming abandonware in the feature, should the company not work out financially. When using Warp for the first time, users are asked to…log in? A strange thing to be sure, but it makes sense for a platform focused on paid AI integration. That being said, I will not pretend like it wasn’t immediately off putting, and felt wrong in a space that is normally about the blooming of a thousand free flowers. Ultimately, I decided for this piece to evaluate Warp with the AI features disabled, which is mercifully a very convenient toggle. This may seem unfair as it effectively disables Warp’s killer app, but at the same time AI integration is different than what the other options terminals are doing that I felt quality comparison with them on would be impossible. With AI integration off, one major positive should be said for Warp: it’s very pretty. The default “Warpified” prompt is sleekly modern and attractive, and several of the built in backgrounds/color options look great. It also comes bundled with a few majorly cool features. The first of which the user is likely to notice is its “blocks”: visual groupings for commands and their outputs, which are an appreciable boost to visual coherency. Even cooler, these blocks can be shared with others using Warp. It also has built in completions/suggestions that usually require shell configuration to get in the terminal, which isn’t terribly useful to most veterans but is probably very nice for new users. It even has its own built in IDE, which I personally question the utility of, but may be desirable for those looking to unify their workflow under one development platform. Unfortunately, I do think that, despite all these positives, the bell ultimately tolls for Warp, because it gets a number of the basics wrong. Firstly, all of these bells and whistles come at a cost, as Warp uses more than double (almost 600MB!) the amount of RAM of next hungriest terminal while idle. Furthermore, despite being a heavily developed Rust project, it is slow, noticeably so compared to many other options (although it defied my attempts to apply several of the benchmarks). It also lacks the configurability and extensibility of many of the best options in this space, despite presenting as a very maximalist choice. With the AI off, Warp certainly has redeeming qualities, but I find it difficult to recommend in light of its shortcomings.

Link To Benchmarks

Contour

Contour is a terminal I found out about from a forum post by Wez Furlong, the creator of WezTerm. Contour is a modern GPU accelerated terminal written in C++ focusing on performance, and in that it would appear to succeed. Anecdotally, it is one of the snappier terminals I have used. Less anecdotally, when using actual benchmarks, it lags well behind some of the frontrunners. Still, it’s performant to the point that it isn’t really an issue, and has a solid look/feel. That being said, I am unsure whether or not it really offers anything over other options to make it a solid choice. This is an excellent example of terminal that doesn’t really do anything wrong (except for some strange default keybinds), but at the same time doesn’t do enough different/better to stand out from other options, at least in my humble opinion.

Link To Benchmarks

The Minimalists

Here we arrive at terminals that deliberately do less. That suck less, in one case. These terminals deliberately seek to keep things as simple and streamlined as possible, and should appeal to those who find most software bloated beyond any real purpose. I am a big enough sucker for pretty lights and avant garde nonsense that daily driving these did not turn out to be for me, but I certainly see the appeal for a significant subset of users.

Simple/Suckless Terminal (st)

st term in an interesting case: First of all, explaining the name: It is a terminal by suckless.org. It is commonly referred to as “suckless terminal” colloquially, but seems to be called simple terminal or “st” by its maintainers. If you are familiar with suckless philosophy, you probably have a decent idea of what kind of software this is. If not, a reasonable way of expressing it is to say that, in their minds, most software sucks because it does too much. Simple terminal then is exactly what you would expect from such a group: the absolute most minimal terminal possible. No hardware acceleration. No image support. Ligatures? Scrollback? More like BLOAT (suckless adherents call everything bloat). As a trade off for these things, you get simplicity and blazingfly fast startup times (65ms), second only to Foot. That being said, I don’t know if I really recommend it. It doesn’t beat xfce4-terminal by enough in any category to really push for it, and some of the things it deems bloat I would call basic quality of life, particularly scrollback.

Best for:

  • Those demanding the utmost (utleast?) minimalism on X11

Link To Benchmarks

Foot is a terminal emulator built for the Wayland DE on Linux that strives to have the smallest footprint possible. Ha. Puns aside, it does an incredible job. It uses the single least amount of RAM of any terminal that I have seen (25MB for me whilst idle), a ridiculously small binary (<5MB), and has a startup time so fast that it borders on imperceptible: ~30ms normally, ~16.5ms when using its special client/server configuration, as though it needed to be even faster. It also doesn’t even totally eschew image support despite its minimalism. Overall, I am a big fan of Foot, and if you are on a Wayland DE and want the fastest, lightest terminal available, look no further.

Best for:

  • Users with extremely limited resources in terms of space/hardware power
  • Usecases where startup time is paramount for one reason or another
  • Fans of minimalism in general

Link To Benchmarks

The Contenders

These are good-to-great terminal emulators. They check all the major boxes, and I think deserve serious consideration from users. While I don’t recommend these quite as strongly as I might the superlatives, they are still strong offerings that you could spend your whole career with and be quite happy.

Alacritty

Alacritty’s influence and legacy in the realm of terminal emulators can scarcely be overstated. It ushered in the modern era of GPU accelerated terminal emulators, and remains the gold standard for speed to this day. In fact, its parser is used in many other terminals in the ecosystem. It is rock solid, stable, and really all but beyond reproach in what it does. Why, then, do I not give it the highest possible recommendation? Because I think that in 2026 it exists in a bit of a no man’s land. It is very fast, but so are kitty and Ghostty, and both of those distantly outstrip it in terms of features. It does have a minimal footprint compared to those…but if you want minimalism, Foot is much more minimal while also being fast at a lot of tasks. If you’re looking for a feature-light, midweight terminal that works at blistering speeds, Alacritty cannot be beat. I simply question the size of the audience for whom that is the ideal.

Link To Benchmarks

Rio

Rio is a modern terminal emulator built in Rust, and has a surprising amount of features for what appears to be mostly a one-man-band project. Perhaps its most unique “hook” is its integration with RetroArch shaders, allowing a degree of customization over the look/feel of your terminal that can’t really be had anywhere else. These shaders can range from CRT emulation like Cool-Retro-Term all the way to the truly bizarre. Productive? Probably not, but they are genuinely cool. Rio also sports a configurable “hints” system that can show/suggest keybinds where relevant, which is a neat feature. Overall, Rio does a lot right: it’s fast, feature rich, supports every image protocol, and has a much smaller binary footprint than similar competitors. Unfortunately, I also think it just tends to be a little buggier in my testing than many of the other options (I just opened it to an immediate freeze while typing this), and it doesn’t do quite enough good to launch it into the [Superlatives](the superlatives) category regardless.

iTerm2

iTerm2 (iterm) is a very old, very feature complete terminal that stands as one of the jewels of the MacOS development ecosystem, widely beloved by users for well over a decade at this point. It is the gold standard for color support, introduced its own image protocol, and had built in multiplexing long before any of the Linux options I have covered dared to try it. It’s not all roses, however: iterm is slow compared to many of the modern options (slow enough I thought something might be wrong while benchmarking it), favors an absolutely sprawling GUI config rather than file-based config (a matter of taste, but I find the latter strongly preferable), is very resource hungry at <350MB of idle RAM consumption, and has somewhat dated and less than excellent documentation. I also find its scripting cumbersome compared to, say, WezTerm. Still, it has a lot of devoted adherents, and in my research for this piece I believe I discovered why: iterm was “good” before anything else was. All of those “modern” features I listed? iterm was doing them 10 years ago, long before anyone else. I don’t use iterm anymore for a number of reasons (I think other choices have mostly surpassed it, and I value having cross platform solutions), but it is easy to see why it has built such a strong following. It has faithfully carried users from before I ever wrote “Hello World” into the modern day while scarcely showing its age, and that is something to be proud of.

Best for:

  • Happy users who don’t feel like a switch
  • Mac loyalists

Link To Benchmarks

The Superlatives

The following terminals can be used by everyone, but in my opinion also represent the true endgame for terminal enthusiasts. These terminals vary significantly in terms of their strengths, empahsis, and underlying technologies leveraged, but all share the following: Great user experience, high configurability, and cutting edge features. I recommend all of the terminals here unreservedly, and have enjoyed my time with each of them.

WezTerm

WezTerm is a a terminal emulator by developer Wez Furlong, written in Rust and featuring all the goodies one could imagine in a modern terminal emulator. That isn’t an exaggeration - If I had to pick the single most feature-rich terminal, I would pick WezTerm. It might be easier to list the things it doesn’t do. It supports every image protocol under the sun. It has a special “copy mode” to enable easy selection of text without reaching for the mouse. It has its own special enhanced ssh integration with a built in custom library. It possesses built in support for multiplexing without the use of tmux/screen/zellij/any other third party solution. It is a pioneer of highly configurable scrollback with a multitude of unique settings. It has very thorough and digestible documentation. Rather than a GUI config or a toml/json/conf file, it is configured in the Lua scripting language, allowing condional config and scripting potential that is virtually unmatched in the terminal space. With all of these positives, one might ask: Why would you ever use another terminal? For starters, it isn’t the fastest, or even close. In terms of both startup time and benchmarking metrics, it is easily the slowest of the Superlatives. It is also the least actively maintained of this group, not seeing a major release since Feb. 2024. Furthermore, most of these fun, advanced features require a significant amount of configuration to take full advantage of, which brings us to the next point: Lua config can be a double edged sword. While the incredible amount of extensibility it offers is no doubt appealing to many, just as many others won’t want to put a lot of time into actually “programming” their terminal config. WezTerm’s defaults are really nothing special, and unless you’re already a Lua wiz (looking at you, Neovim users), it takes little bit of work to get where you want to be, certainly the most of any of the maximalist emulators. Even still, all of the positives I previously mentioned still stand, and it’s fast enough that most people would never perceive the difference in speed without actively looking. All in all, WezTerm comes highly recommended from me.

Best for:

  • People who demand the utmost in customizability from their terminal
  • Tinkerers: those who genuinely enjoy exploring the possiblities with tooling.

Link To Benchmarks

kitty

kitty’s tagline is “If you live in the terminal, then kitty is made for YOU!” A bold, albeit playful claim. One that of course begs the question: Does Kitty live up to it? I would say yes, to the point where I will open this section by saying that kitty is my current terminal of choice, and I have been very happy with it. Firstly the good: kitty is extremely performant. In fact it is in contention with Alacritty for most performant terminal, and is infinitely more feature rich than that one competitor. In terms of what Kitty can do, its only real competition is WezTerm in terms of feature richness and flexibility. Configuration in kitty is done in a massive kitty.conf file, which can be intimidating at first, but is probably the single most exhaustively commented file I have ever encountered. It also does not require the user to learn Lua for configuration if they are not familiar (although I wouldn’t call basic Lua terribly prohibitive), which is also a plus. The existence of a config file might suggest that things are less scriptable than with WezTerm, but that is not necessarily the case. Instead of a using the same setup for configuration and scripting like WezTerm does with Lua, Kitty has the concept of “kittens” (awww), which are small Python (and sometimes Go) programs that can be used to script terminal behavior. These kittens can be very powerful, with some of the built in ones enabling a menu of hotswappable themes, a clipboard protocol that works even over ssh, a custom in-terminal diffing solution, and much more. Overall, I would say that creating your own kittens has a somewhat higher barrier to entry than just extending your Lua config in WezTerm, but this is balanced by the fact that basic configuration with a .conf file requires a lesser initial investment. In terms of multiplexing, kitty’s solution is called “sessions”, which are simple scripts in .kitty-sessions files that define a layout/programs to launch for kitty and are then called with a keybind or command. With all of those positives, one might be tempted to ask “What are the downsides of kitty?” And truthfully, one of the biggest bits of praise is to acknowledge that that the shoe never really drops. I have yet to really find any major downsides with the terminal itself. Indeed, the only prevalent complaint I see other people have with kitty is a dislike of the primary maintainer (Kovid Goyal, who is also the main author of Calibre), who is known to be more than a little prickly at times. As far the program itself though, kitty knocks it out of the park, and I can’t think of a stronger recommendation than reiterating that it’s what I now use every day.

Best for:

  • Terminal users willing to do some configuration, but not necessarily as much as with WezTerm
  • Those demanding the utmost performance while still maintaining the highest level of feature completeness

Link To Benchmarks

Link To macOS Benchmarks

Ghostty

Ghostty is by far the newest of the terminals in this section, being less than two years old (for its public release). It is known for being what is probably the flagship application for the relatively new low level language Zig. This is significant detail not just for language enthusiasts, but because of what it means for Ghostty as part of an ecosystem: being the public face of a whole language means Ghostty is likely to get a lot of extra attention, and with extra attention comes extra development and more maintainers. Indeed, despite being less than a quarter of kitty’s age, it already has a similar number of commits from an even greater number of contributors. Ghostty is also known for using native rendering for each major platform. WezTerm and kitty look like themselves regardless of whether the user is on Windows, Mac, or Linux. By contrast, Ghostty looks like a native Mac app on my Macbook, and the sharpness and coherency of the design immediately jumps out. As for performance, Ghostty does not quite meet the lofty standards set by Alacritty and Kitty, but in truth the margin of difference is small enough that it is vanishingly unlikely to be meaningful in the real world; it is not the difference between slow and fast, but rather lightspeed and ludicrous speed. As for configuration and features, Ghostty does lag slightly behind its older compatriots. Ghostty config is done in a very simple .ghostty file that uses an extremely simplified “key=value” syntax, and relies on online reference documentation to provide a list of the available options. It also lacks any native support for advanced scripting features that Kitty and Wezterm have, as well as having no built in session/multiplexing abilities, relying on tmux or similar external software. This might lead the reader to wonder: “If it’s just fast and pretty, does it really stack up to the best?” The answer to that is “yes”, for two reasons, the first of which was already touched on: It has the most active development of any terminal. The momentum behind it is incredible, and if I had to pick a terminal cart to attach my metaphorical horse to for future purposes, I would choose Ghostty. It does not have quite all of the niceties of Kitty/WezTerm now, but I can very easily imagine a future world in which it does. The second reason is even more important, and one that we have yet to cover: The fact that, out of the box, Ghostty blows every other terminal away. Other terminals take what I would call a very old school approach to configuration: they are incredibly power, but little to nothing is done for you. The concept of a “sensible default” is treated as an affront to generations of tinkerers who enjoy spending an inordinate amount of time configuring and hacking to make the software truly their own. Ghostty takes the opposite approach, aiming for “zero config for most users”, and it shows. Ghostty is imminently usable and beautiful immediately after installation, and many of the nicest things about it are discoverable without so much as reading a line of documentation. I myself am one of those tinkering weirdos, but I also recognize that the majority of users are not, and I truly wish that other terminals would take a lesson from Ghostty and ship an experience that doesn’t require digging to find any of the magic. Until then, Ghostty runs absolute laps around the competition in this department.

Best for:

  • People who just want to download a terminal and be done with it, without missing out.
  • People playing the long game and choosing based on what might be best in the future
  • Zig enthusiasts

Link To Benchmarks

Closing Thoughts:

I enjoyed trying out so many different terminals and learning more about them. I did not at all enjoy compiling the benchmarks, to the point that it threatened to sour me on the whole process. Neverthless, it is done now, and I hope that it may provide a measure of value to at least a small number of readers.

Benchmarks Section

Below are the benchmarks taken for each of the terminal emulators. They are here at the bottom for ease of comparison, and also so that they do not overwhelm the rest of the text.

Foot Emulator Benchmarks

Idle RAM usage: 25 MB (normal), 18 MB (server mode), 31 MB total (active server/client)

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars717.43ms278.8
Unicode chars1.57s115.6
CSI codes with few chars1.65s60.6
Long escape codes2.2s356.1
Images1.15s463.3

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion24251.22 MiB3.68ms< 4ms0.48ms
dense_cells21151.29 MiB4.12ms< 5ms0.35ms
light_cells19401 MiB4.61ms< 5ms0.55ms
scrolling811 MiB123.32ms< 131ms7.21ms
scrolling_bottom_region791 MiB127.2ms< 139ms10.09ms
scrolling_bottom_small_region811 MiB123.73ms< 135ms7.78ms
scrolling_fullscreen16581 MiB5.57ms< 6ms0.7ms
scrolling_top_region841 MiB119.69ms< 128ms7.63ms
scrolling_top_small_region741 MiB136.05ms< 147ms8.11ms
unicode11211.06 MiB8.39ms< 8ms5.46ms

3) Startup Time (hyperfine, normal mode)

ModeMean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
Normal29.7 ms1.6 ms26.7 ms34.4 ms10037.2 ms7.6 ms

4) Startup Time (hyperfine, client mode with server running)

ModeMean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
Client (server alive)16.7 ms0.9 ms14.4 ms20.1 ms1580.5 ms0.5 ms

Ghostty Emulator Benchmarks

Idle RAM usage: 188 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars1.83s109.1
Unicode chars1.59s114.0
CSI codes with few chars1.98s50.5
Long escape codes7.16s109.5
Images7.64s69.8

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion10501.22 MiB9.19ms< 10ms0.53ms
dense_cells7681.29 MiB12.34ms< 13ms0.7ms
light_cells12601 MiB7.27ms< 8ms0.56ms
scrolling631 MiB158.63ms< 180ms16.51ms
scrolling_bottom_region621 MiB161.39ms< 181ms14.11ms
scrolling_bottom_small_region631 MiB158.86ms< 178ms16.72ms
scrolling_fullscreen6701 MiB14.45ms< 16ms1.54ms
scrolling_top_region641 MiB157.88ms< 182ms16.57ms
scrolling_top_small_region621 MiB160.97ms< 180ms14.09ms
unicode9921.06 MiB9.59ms< 11ms1.79ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
258.5 ms18.9 ms245.0 ms297.8 ms10173.2 ms111.9 ms

Cool Retro Term Emulator Benchmarks

Idle RAM usage: 218 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars6.23s32.1
Unicode chars3s60.3
CSI codes with few chars2.02s49.6
Long escape codes5.06s154.8
Images13.87s38.5

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion8051.22 MiB11.74ms< 12ms2.29ms
dense_cells7801.29 MiB12.21ms< 12ms4.54ms
light_cells5901 MiB16.4ms< 17ms1.81ms
scrolling451 MiB225.04ms< 235ms5.94ms
scrolling_bottom_region541 MiB187.74ms< 200ms10.6ms
scrolling_bottom_small_region581 MiB174.21ms< 214ms25.12ms
scrolling_fullscreen3271 MiB30.35ms< 30ms2.05ms
scrolling_top_region541 MiB185.91ms< 208ms13.73ms
scrolling_top_small_region611 MiB165.92ms< 187ms15.34ms
unicode7061.06 MiB13.84ms< 13ms14.89ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
375.0 ms27.2 ms345.2 ms444.8 ms10156.1 ms185.6 ms

Contour Emulator Benchmarks

Passive RAM usage: 288 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars6.04s33.1
Unicode chars6.31s28.7
CSI codes with few chars2.97s33.7
Long escape codes3.44s227.6
Images1.58s336.9

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion8431.22 MiB11.09ms< 11ms0.36ms
dense_cells13201.29 MiB7.04ms< 7ms0.22ms
light_cells3711 MiB26.38ms< 27ms0.52ms
scrolling681 MiB146.82ms< 165ms16.58ms
scrolling_bottom_region561 MiB180.79ms< 196ms11.85ms
scrolling_bottom_small_region571 MiB175.44ms< 191ms10.39ms
scrolling_fullscreen5391 MiB18.01ms< 18ms0.14ms
scrolling_top_region551 MiB182.53ms< 193ms8.24ms
scrolling_top_small_region561 MiB178.95ms< 190ms9.13ms
unicode2991.06 MiB32.93ms< 34ms1ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
375.0 ms27.2 ms345.2 ms444.8 ms10156.1 ms185.6 ms

Alacritty Emulator Benchmarks

Idle RAM usage: 143 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars1.68s118.9
Unicode chars1.32s137.5
CSI codes with few chars1.33s75.3
Long escape codes5.71s137.4
Images1.31s406.3

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion16241.22 MiB5.77ms< 6ms0.52ms
dense_cells16031.29 MiB5.95ms< 6ms0.3ms
light_cells20421 MiB4.17ms< 5ms0.42ms
scrolling861 MiB116.47ms< 125ms5.67ms
scrolling_bottom_region841 MiB119.21ms< 129ms7.93ms
scrolling_bottom_small_region831 MiB120.18ms< 132ms9.2ms
scrolling_fullscreen9251 MiB10.32ms< 12ms1.73ms
scrolling_top_region831 MiB120.24ms< 129ms7.32ms
scrolling_top_small_region821 MiB121.79ms< 129ms5.64ms
unicode18031.06 MiB5.02ms< 5ms0.15ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
156.4 ms25.7 ms137.6 ms229.5 ms1267.5 ms84.8 ms

Ptyxis Emulator Benchmarks

Idle RAM usage: 242 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars1.13s177.3
Unicode chars1.59s113.8
CSI codes with few chars2.41s41.5
Long escape codes3.3s237.5
Images2.17s246.1

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion7961.22 MiB12.05ms< 32ms13.23ms
dense_cells7841.29 MiB12.36ms< 27ms11.35ms
light_cells34121 MiB2.48ms< 5ms2.32ms
scrolling621 MiB160.92ms< 170ms6.76ms
scrolling_bottom_region641 MiB157.69ms< 167ms7.22ms
scrolling_bottom_small_region611 MiB165.2ms< 173ms6.96ms
scrolling_fullscreen7961 MiB12.08ms< 15ms3.26ms
scrolling_top_region591 MiB171.39ms< 184ms9.07ms
scrolling_top_small_region601 MiB168.82ms< 178ms7.36ms
unicode7571.06 MiB12.71ms< 32ms23.32ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
488.1 ms24.2 ms443.9 ms531.0 ms10234.5 ms224.5 ms

Konsole Emulator Benchmarks

Idle RAM usage: 129 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars3.92s51.1
Unicode chars2.44s74.0
CSI codes with few chars2.57s39.0
Long escape codes10.1s77.6
Images17.58s30.3

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion7011.22 MiB13.93ms< 17ms1.89ms
dense_cells6761.29 MiB14.11ms< 18ms2.53ms
light_cells7011 MiB13.83ms< 16ms1.75ms
scrolling561 MiB180.55ms< 202ms17.09ms
scrolling_bottom_region601 MiB169.3ms< 190ms21.21ms
scrolling_bottom_small_region591 MiB171.75ms< 194ms18.09ms
scrolling_fullscreen4601 MiB21.35ms< 31ms4.74ms
scrolling_top_region661 MiB152.24ms< 183ms20.44ms
scrolling_top_small_region631 MiB159.17ms< 191ms22.53ms
unicode6811.06 MiB14.07ms< 11ms56.25ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
189.1 ms6.8 ms172.8 ms199.8 ms15116.3 ms35.2 ms

Warp Emulator Benchmarks

Warp refused to provide output and resisted my attempts to attain benchmarks with the both vtebench and hyperfine. I would imagine that has to do with some bit of being standards non-compliant, but I will admit that I did not dig terribly deep. Anecdotally, it’s noticeably slower than the best options, but not to the point of being a major problem.

Idle RAM usage: 582 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars3.76s53.2
Unicode chars3.03s59.7
CSI codes with few chars3.03s33.0
Long escape codes4.16s188.5
Images3.44s155.1

Terminal.app Emulator Benchmarks

Idle RAM usage: 44 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars4.19s47.8
Unicode chars2.93s61.8
CSI codes with few chars2.14s46.8
Long escape codes4.99s157.3
Images5.61s95.1

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
dense_cells4851 MiB20.01ms< 20ms0.17ms
medium_cells2831.02 MiB34.93ms< 36ms0.94ms
scrolling601 MiB140.98ms< 143ms31.43ms
scrolling_bottom_region871 MiB115.09ms< 117ms1.28ms
scrolling_bottom_small_region871 MiB115.4ms< 117ms1.1ms
scrolling_fullscreen551 MiB156.45ms< 159ms22.04ms
scrolling_top_region871 MiB115.22ms< 116ms1.23ms
scrolling_top_small_region861 MiB115.94ms< 117ms0.79ms
sync_medium_cells2711.06 MiB36.46ms< 40ms7.47ms
unicode5971.06 MiB16.26ms< 48ms20.92ms

iTerm2 Emulator Benchmarks

Idle RAM usage: 377 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars9.09s22.0
Unicode chars15.93s11.4
CSI codes with few chars37.28s2.7
Long escape codes10.04s78.1
Images19.34s27.6

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
dense_cells1031 MiB96.66ms< 123ms19.18ms
medium_cells191.02 MiB539.68ms< 576ms26.35ms
scrolling1801 MiB29.11ms< 33ms2.87ms
scrolling_bottom_region181 MiB560.11ms< 569ms4.54ms
scrolling_bottom_small_region181 MiB559.61ms< 565ms4.82ms
scrolling_fullscreen1341 MiB47.05ms< 55ms4.93ms
scrolling_top_region41 MiB2711.5ms< 2768ms42.65ms
scrolling_top_small_region181 MiB562.94ms< 583ms10.03ms
sync_medium_cells171.06 MiB611.24ms< 623ms9.86ms
unicode1041.06 MiB97.61ms< 82ms141.24ms

xfce4-term Emulator Benchmarks

Idle RAM usage: 51 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars937.42ms213.4
Unicode chars1.46s124.1
CSI codes with few chars2.7s37.0
Long escape codes3.11s252.2
Images2.06s258.9

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion8851.22 MiB10.64ms< 57ms26.94ms
dense_cells9321.29 MiB10.48ms< 42ms18.32ms
light_cells23821 MiB3.83ms< 15ms6.06ms
scrolling611 MiB165.13ms< 166ms20.84ms
scrolling_bottom_region681 MiB147.85ms< 156ms6.55ms
scrolling_bottom_small_region651 MiB153.52ms< 172ms14.94ms
scrolling_fullscreen9651 MiB9.87ms< 14ms3.91ms
scrolling_top_region711 MiB141.3ms< 148ms5.32ms
scrolling_top_small_region711 MiB141ms< 152ms8.31ms
unicode7081.06 MiB13.91ms< 30ms45.49ms

st Emulator Benchmarks

Idle RAM usage: 14 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars2.93s68.3
Unicode chars1.95s92.9
CSI codes with few chars12.85s7.8
Long escape codes7.59s103.3
Images5.09s104.7

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion6971.22 MiB14ms< 14ms2.35ms
dense_cells2251.29 MiB44.01ms< 46ms3.67ms
light_cells8201 MiB11.79ms< 12ms0.68ms
scrolling441 MiB228.18ms< 230ms1.63ms
scrolling_bottom_region521 MiB192.31ms< 194ms1.67ms
scrolling_bottom_small_region551 MiB184.27ms< 186ms3.75ms
scrolling_fullscreen5801 MiB16.84ms< 17ms0.7ms
scrolling_top_region531 MiB191.53ms< 192ms0.82ms
scrolling_top_small_region541 MiB186.7ms< 190ms4.28ms
unicode261.06 MiB412.46ms< 1164ms478.29ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
65.7 ms14.9 ms36.6 ms99.8 ms4611.8 ms4.4 ms

WezTerm Emulator Benchmarks

Idle RAM usage: 138 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars7.28s27.5
Unicode chars3.74s48.4
CSI codes with few chars5.19s19.3
Long escape codes4.06s193.1
Images1.51s352.2

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion5571.22 MiB17.5ms< 28ms5.27ms
dense_cells5891.29 MiB16.51ms< 25ms4.77ms
light_cells2721 MiB36.29ms< 44ms11.37ms
scrolling631 MiB160.02ms< 172ms9.72ms
scrolling_bottom_region601 MiB166.9ms< 180ms10.44ms
scrolling_bottom_small_region581 MiB173.28ms< 184ms8.06ms
scrolling_fullscreen2911 MiB33.98ms< 41ms4.79ms
scrolling_top_region591 MiB170.76ms< 183ms9.39ms
scrolling_top_small_region601 MiB168.98ms< 183ms12.57ms
unicode3281.06 MiB29.99ms< 47ms15.58ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
180.9 ms8.9 ms170.7 ms197.8 ms1596.0 ms73.2 ms

Kitty Emulator Benchmarks

Idle RAM usage: 131 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars1.64s122.2
Unicode chars1.35s134.0
CSI codes with few chars2.34s42.7
Long escape codes2.37s331.2
Images1.85s288.8

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
cursor_motion2921.22 MiB33.82ms< 66ms17.26ms
dense_cells5421.29 MiB18.03ms< 29ms6.86ms
light_cells15191 MiB6.11ms< 6ms0.51ms
scrolling671 MiB149.28ms< 161ms7.81ms
scrolling_bottom_region701 MiB142.53ms< 153ms8.59ms
scrolling_bottom_small_region701 MiB144.16ms< 154ms7.82ms
scrolling_fullscreen9951 MiB9.53ms< 11ms1.05ms
scrolling_top_region701 MiB143.76ms< 152ms6.58ms
scrolling_top_small_region691 MiB144.91ms< 156ms10.08ms
unicode811.06 MiB127.01ms< 10ms629.32ms

3) Startup Time (hyperfine, normal mode)

Mean TimeStd DevMin TimeMax TimeRunsUser CPUSystem CPU
221.1 ms14.7 ms210.2 ms261.6 ms11127.4 ms87.2 ms

Kitty macOS Emulator Benchmarks

Idle RAM usage: 95 MB

1) Kitty Benchmark Results

TestTimeThroughput (MB/s)
Only ASCII chars1.56s128.2
Unicode chars1.14s158.6
CSI codes with few chars1.28s78.0
Long escape codes2.37s330.5
Images1.81s295.0

2) vtebench Results

TestSamplesPayloadAvg TimeP90 TimeStd Dev
dense_cells7371 MiB13.04ms< 13ms0.36ms
medium_cells7241.02 MiB13.36ms< 17ms2.5ms
scrolling1321 MiB62.88ms< 81ms17.11ms
scrolling_bottom_region3591 MiB27.34ms< 33ms5.02ms
scrolling_bottom_small_region3571 MiB27.51ms< 33ms4.98ms
scrolling_fullscreen761 MiB116.55ms< 119ms1.66ms
scrolling_top_region3661 MiB26.84ms< 32ms4.8ms
scrolling_top_small_region3561 MiB27.59ms< 33ms5.05ms
sync_medium_cells6111.06 MiB15.86ms< 16ms1.85ms
unicode8451.06 MiB11.42ms< 8ms19.25ms