

Yeah, complexity is a valid concern. But if your workflow stands to benefit from the performance gains, I’d say it’s a worthy trade-off.
The server/client model that Foot uses is actually pretty clever for RAM-constrained situations, especially if you’re spawning tons of terminal instances. AFAIK, it’s not fundamentally impossible with GPU terminals. Ghostty has single-instance mode on Linux that shares some resources, but the RAM savings aren’t as dramatic because GPU terminals maintain texture buffers and rendering state in VRAM per instance.
The catch with Foot’s approach is all I/O gets multiplexed on a single thread. That’s fine for lightweight usage, but for workflows like mine that involve heavy TUIs and multiple tmux sessions with dozens of windows/panes with big scrollback buffers, it becomes a bottleneck when one or more panes are flooding output from scripts/playbooks/etc.
The terminfo issue was resolved in the v1.2.0 release.
SSH shell integration is disabled by default, but once you enable it in your config you’ll be good to go.
https://ghostty.org/docs/features/shell-integration