HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
kovidgoyal
kitty
Python2017–2026
kovidgoyal / kitty

kitty

If you live in the terminal, kitty is made for you! Cross-platform, fast, feature-rich, GPU based.

87Distinct people
113Mentions
2Explicit recommenders
35.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

If you live in the terminal, kitty is made for you! Cross-platform, fast, feature-rich, GPU based.

GitHub

Where it is used

  • Graphviz — Graphviz adds a -Tkitty output to display inline graphics using the kitty Terminal graphics protocol. This implements inline graphics in terminals that support that protocol, including kitty. Source
  • mpv (media player) — mpv is documented on kitty's integrations page as using kitty's graphics/video output (vo=kitty) to play videos in the terminal. Source

What people are saying

I mostly switched to librem 14, arch linux (i3wm, gnome from time to time), still using a mac for work (mostly presentations, video conferencing). Development tends to get more…

kgarten used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

Libghostty 1.0 direct repository linkFavorable

The community overwhelmingly praises libghostty 1.0 for providing a stable, high-performance C library that simplifies embedding terminal emulation in diverse applications like IDEs and custom TUIs. Users highlight the project's rigorous ABI design and rapid ecosystem growth as key benefits, although some note that specific features like Windows support or advanced configuration UIs remain limited compared to established terminals.

210 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4

Mentions over time

HN mentions by year113 dated mentions

Observed mentions: 2017-01-07 04:17:33 UTC to 2026-10-07 18:29:01 UTC.

051015202017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 8 mentions; 3 submissions, 5 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 14 mentions; 1 submissions, 13 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 13 mentions; 3 submissions, 10 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 14 mentions; 2 submissions, 12 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 19 mentions; 1 submissions, 18 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 11 mentions; 1 submissions, 10 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC835
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC14113
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC606
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC10010
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC13310
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC12111
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC14212
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC19118
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC11110
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC606

What Hacker News says

113 sources
Good questions. > why did it write so much to begin with? It's an incremental project covering a complex domain. At any time, the code has to stay balanced in a spot that addresses correctness and performance across things like pty parsing, a terminal grid, stateful pty behavior, rendering, scrollback history, font glyphs, and like all software there is a fractal of idiosyncrasies that sprout up. And that's just the terminal side. Unless you can see the future, like most software, so much of the project is trying things and seeing what happens at the periphery, like how to represent "row damage" and apply it in a way that works with macOS Core Graphics and 1000 other things. e.g. Can you tell me off the top of your head what the trade-offs are of representing the terminal contents/scrollback as a pre-wrapped grid vs. a list of logical lin
Read the rest
es that are soft-wrapped on the fly? Did you enumerate them all and correctly weigh them such that you can pick the ideal solution ahead of time? No. You just kinda make educated decisions and find out in practice what the exact weight of the trade-offs are. You should see the amount of iterations a human needs on these kinds of projects. https://github.com/ghostty-org/ghostty has almost 18,000 commits. So does https://github.com/gnachman/iterm2. So does https://github.com/kovidgoyal/kitty. > why do you assume that now there's no more debt? I don't. Like all software, you try to ratchet into better and better positions, and you try to come up with metrics that can tell you "You are here" with regard to rather fuzzy goals like "it should be correct and performant and nice to use". But I can look at individual findings and their solution to go "yes, this improves the code." And on principle I think that, e.g. correct/DRY/simple by-construction is superior to by-convention, and I assume it helps future agents reason about the system and make future edits, and it gives them singular places to make changes that impact multiple components just like it would a human. But how much did it actually matter?
In There's No Limit to How Bad Code Can Get
You're right my comment was off the cuff but I stand by it's logic. I didn't say Kovid was a terrible person, just not great. Having not done research into him specifically I just noted with the parent that certain qualities such as supposed abrasiveness often overlap with qualities I dislike, like using the Lenna image. My point is that using the Lenna image is a signal, just as you rightly point out so is my comment. I know exactly what the image is and is used for. But I also think it's sad that it's politically charged to say using a Playboy image in a literally objectifying fashion as a test-subject by a women who's requested we don't use it is bad. It's not a sudden ban, it's been an issue since ~2015. Fun fact I learnt in this, Goyal is totally open to changing it (https://github.com/kovidgoyal/kitty/issues/661), it's simply no-one
Read the rest
changed it. I'll see if I can, thanks for the correct call-out.
In FIM – Linux framebuffer image viewer
> Kitty I don't remember why I rejected. Maybe worth another look at then? I'm far from a Kitty power user, but it does pretty much everything else I want it to, including working as a quake-style terminal[0]. And you can extend it with kittens[1] if you so desire. Also, the next release should presumably include smooth scrolling[2] which I'm quite looking forward to. Maybe more than any one feature though, I appreciate the hard work that Kovid (the creator of Kitty) has done to tastefully add new VT standards and try to make terminals as useful as they can be in the 21st century. [0] https://sw.kovidgoyal.net/kitty/kittens/quick-access-termina... [1] https://sw.kovidgoyal.net/kitty/kittens_intro/ [2] https://github.com/kovidgoyal/kitty/pull/9330
In Ghostty – Terminal Emulator
The author of Kitty, Kovid Goyal, calls running tmux on local sessions an “anti-pattern” in the linked GitHub issue. I can’t help but find that a bit ironic, because the very first time I tried Kitty, I was in the middle of work when I discovered Arabic support was broken - https://github.com/kovidgoyal/kitty/issues/536 . I simply launched the macOS Terminal app, attached to the same tmux session, verified my Arabic text rendered correctly, and then closed Kitty. Without tmux, I would’ve been forced to recreate my entire workflow from scratch.
In Replacing tmux in my dev workflow
I quite liked Kitty, and wanted to keep using it. But the slow startup was a deal breaker for me. Even with `--single-instance` it was at least 5x that of st for me, which is noticeable for an app I use very frequently. Besides, I'm not a fan of running a single instance of any app, since if (when) it crashes, all my work is gone. Then I had a look around their issue tracker, and noticed others complained about this too[1]. And the dismissive and defensive response from the author just rubbed me the wrong way. [1]: https://github.com/kovidgoyal/kitty/issues/330
In Suckless.org: software that sucks less

Showing the 15 most recent of 113 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.