Gutenberg's copy of Moby Dick is 1.2MB[0]. Which is to say the slowest benchmarked terminal could display a paltry ~53 Moby Dicks per second, while shitty gives you ~98 Moby Dicks.
I am not sure how many Moby Dicks I require per second, but it is good to have options.
This is cool, but I gotta say - I care much more about keypress-to-screen latency on my terminals than throughput - would love to see some numbers on that.
To me, the most relevant aspect is the time it takes to open. I can't believe how slow the startup time in common linux distributions is by default, it's so annoying, by the time it opens I already forgot what I wanted to do. Alacritty has this cool feature where you only ever have to "open" a single terminal, whereas new windows can be created very efficiently with `alacritty msg create-window`, being forks of the initial window. It makes using my pc a lot more comfortable.
Speed itself may not be very important, but it is a very interesting challenge in itself - to prove to yourself that you can surpass the state of the art!
> The executable is named st; the desktop application and icon are named shitty
That conflicts with the already existing suckless st.
Also I am suitably impressed with the perf numbers, but I also somewhat take away that I could stick with (at least) alacritty or ghostty and not be much slower.
Mitchell is a big proponent of using AI to code. He’s just not a dummy and knows his sh*t and he reviews the code diligently. Hell, he just promoted that he started a company for making tooling for AI agents. There is lots of LLM code in Ghostty it’s just not attributed.
I'm a huge proponent of AI, as long as there's a human in the loop and strong models are used. In fact, it's even reflected in our CONTRIBUTING.md that we prefer LLM-assisted code!
No, there are no such plans right now, but overall, the project's architecture allows for easy separation of different layers for developing a terminal emulator - the parser, in the form of a ragel state machine, and the vterm state machine, with distinct boundaries between them. The rendering layer is separated slightly less clearly, but it's also solvable.
1. Don't call your project "shitty". At best it's juvenile humor. At worst, it's going to make adoption within companies difficult for literally no reason; and
2. You don't need a two letter command. I'm sorry but you're not that special. Your tool should instead denote its purpose with its name. In this case something like "sterm" or "stty" would do that perfectly without being verbose.
I thought it was quite clever, and was surprised I hadn't thought of it (given the prevalence of "tty" puns like kitty and ghostty).
But I'm a 14 year old boy living in a 45 year old body, so I can't get enough juvenile humor. A friend of mine with similar taste in humor once said, "if I ever stop finding this stuff funny, put me in the ground", and I still wholeheartedly agree with the sentiment.
(For example: whenever I need a quick scratch file to put some text in, I call it "shits", because then I can type "cat shits" and giggle inside my head. I'm also have cats, so I deal with cat shits daily.)
> You don't need a two letter command. I'm sorry but you're not that special.
This I agree with, though perhaps in a politer way.
Regardless, though... live and let live? The existence of this doesn't harm you an any way, and your judgey moralizing is a bit much.
this is not true on my machine, at least for my usual benchmark Doom-fire-zig[1]. on said benchmark, ghostty 1.3.1 runs at about 350fps, wezterm 20260713-212414-b3255666 runs at 415fps, Terminal.app runs at 100fps, iterm2 3.6.11 runs at 80fps.
I'm not imposing my opinion, but in my experience, iterm2 is the slowest terminal emulator I know of, so I didn't even bother trying. But overall, I'll add iterm2 to the list, too.
has iTerm2 improved significantly in the last couple of years? I remember feeling the speedup when I went from iTerm2 to kitty, so that's surprising to me.
Because I don't need to. I've never even once thought "my terminal feels slow and I want to find a different one". My terminal (xfce4-terminal) also uses a GUI toolkit that makes it visually fit in my desktop, and I like that.
Regardless, sometimes you just gotta write some code because there's an itch that needs to be scratched. Sounds like this author really wanted to see if he could write a super fast terminal, and make one faster than the incumbents. It's a cool achievement!
Any project I see on HN now, I have no idea if the developer will still be interested in it in a month. I'll stick with ghostty because of its reputation.
The lifetime rendering-time savings wouldn’t even offset the five minutes required to install it and make it my default terminal.
I would need to display roughly 70 GB of benchmark-equivalent ASCII output before Shitty recovers a five-minute switching cost relative to GNOME Terminal.
This assumes I’m actively blocked by every byte being rendered.
I am not sure how many Moby Dicks I require per second, but it is good to have options.
[0] https://www.gutenberg.org/ebooks/2701
I do wonder, however, whether people really have issues with perf on any terminal emulator in 2026
I’ve been living in Terminal.app / zsh / tmux / vim for 15 years and have never once thought “this is slower than I want.”
I'm glad you guys are out there - someone has to do it.
They also count my steps.
That conflicts with the already existing suckless st.
Also I am suitably impressed with the perf numbers, but I also somewhat take away that I could stick with (at least) alacritty or ghostty and not be much slower.
on the other hand what gives them the right to st but not you?
With this you can DuckDuckKagi for the crappy terminal (versus “CRM crm”… ah guess they wanted you to remember their company name)
https://github.com/fearlessgeekmedia/shiTTY
This one just tried to reserve the name with an empty repo a year ago... probably where the LLM got the name.
https://github.com/immz4/shitty
Later, Microsoft fixes the issue but fails to give Muratori credit. After backlash, they went back and gave him a footnote: https://devblogs.microsoft.com/commandline/windows-terminal-... (atlas release section)
GitHub thread in question: https://github.com/microsoft/terminal/issues/10362#issuecomm...
And this gem: https://github.com/microsoft/terminal/issues/10362#issuecomm...
https://github.com/pg83/shitty/blob/master/CONTRIBUTING.md
1. Don't call your project "shitty". At best it's juvenile humor. At worst, it's going to make adoption within companies difficult for literally no reason; and
2. You don't need a two letter command. I'm sorry but you're not that special. Your tool should instead denote its purpose with its name. In this case something like "sterm" or "stty" would do that perfectly without being verbose.
I wouldn't want to work somewhere like that. Trying to pretend that people don't swear is just dumb. It's not even offensive.
I thought it was quite clever, and was surprised I hadn't thought of it (given the prevalence of "tty" puns like kitty and ghostty).
But I'm a 14 year old boy living in a 45 year old body, so I can't get enough juvenile humor. A friend of mine with similar taste in humor once said, "if I ever stop finding this stuff funny, put me in the ground", and I still wholeheartedly agree with the sentiment.
(For example: whenever I need a quick scratch file to put some text in, I call it "shits", because then I can type "cat shits" and giggle inside my head. I'm also have cats, so I deal with cat shits daily.)
> You don't need a two letter command. I'm sorry but you're not that special.
This I agree with, though perhaps in a politer way.
Regardless, though... live and let live? The existence of this doesn't harm you an any way, and your judgey moralizing is a bit much.
this is not true on my machine, at least for my usual benchmark Doom-fire-zig[1]. on said benchmark, ghostty 1.3.1 runs at about 350fps, wezterm 20260713-212414-b3255666 runs at 415fps, Terminal.app runs at 100fps, iterm2 3.6.11 runs at 80fps.
[1]: https://github.com/const-void/DOOM-fire-zig
Regardless, sometimes you just gotta write some code because there's an itch that needs to be scratched. Sounds like this author really wanted to see if he could write a super fast terminal, and make one faster than the incumbents. It's a cool achievement!
(I have, also, thought about building my own perf-optimized terminal. It's a fun problem space!)
I would need to display roughly 70 GB of benchmark-equivalent ASCII output before Shitty recovers a five-minute switching cost relative to GNOME Terminal.
This assumes I’m actively blocked by every byte being rendered.
My main complaint with ghostty is the crappy configuration.