Ghostty creator says new terminal Rex handled 10,000 sessions with about 3.8GB of memory

Ghostty creator says new terminal Rex handled 10,000 sessions with about 3.8GB of memory

N
News Editor
2026-10-08 09:15:06
Mitchell Hashimoto, the creator of Ghostty, has shared scalability test results for Rex, a new terminal built around long-lived sessions and remote connections. In the test, Rex kept 10,000 active terminal sessions running at the same time while using about 3.8GB of memory, and interactive responsiveness was maintained. Hashimoto said the team has not pushed the test further yet, though the next target is 100,000 sessions. He also outlined two bottlenecks that showed up once Rex reached the 10,000-session mark. One came from Linux’s file descriptor table, which tracks files and connections opened by a process. After roughly 5,000 sessions, each new process added about 512KB for that table despite using only about four file descriptors. Rex now includes a piece of C code to shrink that allocation to the size actually needed. The other issue involved threads. Rex previously assigned one thread to each active terminal session while waiting for data, which drove memory costs higher at scale. The current design moves a session to a shared listener thread if there has been no read activity for two seconds.

Mitchell Hashimoto, the creator of Ghostty, has released scalability test results for Rex, a new terminal focused on long-lived sessions and remote connections. Rex is designed to let terminal tasks keep running in the background.

In the test, Rex maintained 10,000 active terminal sessions at the same time while using about 3.8GB of memory, and interaction remained responsive. The team has not pushed the test higher for now. Its next target is 100,000 sessions.

Two bottlenecks emerged at scale

Hashimoto said that once Rex reached 10,000 sessions, much of the overhead was no longer coming from the terminal itself.

The first bottleneck came from Linux’s file descriptor table, the system structure that records files and connections opened by a process. After terminal sessions passed roughly 5,000, each new process added about 512KB for that table even though it actually used only about four file descriptors. Rex now includes a piece of C code that shrinks this allocation back to the size actually required.

The second issue involved threads. Rex previously let each active terminal session occupy one thread while waiting for data. As the number of sessions grew, the memory cost became too high. Now, if a terminal has no read activity for two consecutive seconds, it is handed off to a shared thread for unified listening.

This article was originally published by Bit.Fan. For more cryptocurrency news and market insights, visit www.bit.fan.
200

Disclaimer:

The market information, project data, and third-party content displayed on this platform are for industry information sharing only and do not constitute any form of investment advice or return commitment.

Cryptocurrency trading carries high risks. Users should fully assess their risk tolerance and make independent decisions. All profits, losses, and legal responsibilities are borne by the users themselves.