Nicheloom

Market intelligence for builders — see what's gaining traction before it's crowded.

Godot and Rust based multiplexer (terminal panes and more)

Details

External ID
49660676
Source
HN
Company
—
Product
Godot and Rust based multiplexer (terminal panes and more)
Website domain
github.com
Launched
Sept. 11, 2026
Cohort
—
Upvotes
97
Upvotes percentile
0.9202551834130781
Tags
—
Fetched at
Sept. 15, 2026, 5:25 p.m.
Updated at
Sept. 15, 2026, 5:25 p.m.

Description

I wanted to share my side-project: gPTY. Started off as an idea to combine Godot and Rust in a project (two stacks I wanted to use more to learn more). The base inspiration was tmux - simply allow spawning multiple PTYs and then let the user grid/tile them how they see fit.But since we have the Godot game engine at our disposal, we can do some more interesting things, like add an FPS counter, and then subsequently also let people set their preferred FPS (the idea being the potential lower power draw if someone's running it on a laptop on battery power vs someone running it on a desktop with high/native FPS). In its current state, with me using Oh-my-Pi a lot, it's evolving into a terminal workspace that can be used for orchestrating autonomous AI agents by way of dogfooding (or you know, just run herdr inside of gPTY - it's the better orchestrator and just good software - I found it after starting this project, and now I'm finding myself using it a lot).Also, we're not limited to just terminals. Since we have Godot, we have basically a 2D (and potentially a 3D) canvas to play with. We can already full-screen the app for "zen" mode, no taskbar, no distractions. TUI die-hards can have their media or other apps entirely in terminal panes.There has been some ground-work on getting Markdowns displayed properly done and I want to work on some kind of Wiki framework for local knowledge-management next, then create more types of panes (think native audio/video on a media pane, that sits alongside your terminal pane), and some simple 2D games (like snake) to prototype. More details are on the ROADMAP.What's not easy (and probably won't happen) is a browser. Having done a couple of (small) projects using Electron already, the temptation to ditch Godot/Rust (learning curve) did come up (and also the ecosystem, the ease with which I could pull components and use web technologies - development velocity would definitely be higher there). But on the flipside, given all of the available LLM and AI support that we are privileged to have today, I figured the velocity should be comparable depending on how much I leaned on those. And lean I did.Godot/Rust seemed the better call to me and my intent anyway - going with the 'it's not just the end but the journey that matters' philosophy. So yes, there has been heavy use of LLMs & AI to generate a lot of the code. But I do review and steer actively, not relying solely on vibes, and there's a few bits here & there that have been human authored.There are definitely a lot of polish and QoL items that need to land to make the end user experience better, but in the meantime, let me know your thoughts and/or concerns!Repository: https://github.com/godot-pty/gptyDocs/Blog: https://godot-pty.github.io/gpty/

Enrichment

Theme
interactive simulations and creative experiments
Vertical
Horizontal
Function
Dev tools
Audience
Developer
AI stance
Not AI
Project type
Hobby / open-source project
Normalized one-liner
terminal multiplexer built with godot and rust
Manually corrected
False

Could you build this?

Partial Building a terminal multiplexer by combining Godot's rendering/scene graph with Rust PTY management requires non-trivial native FFI bindings and low-level terminal emulation.

What it would actually take: Requires Rust using GDExtension (Godot's C++ FFI) to communicate directly with Godot 4. The Rust layer must handle PTY spawning, raw mode I/O, and an ANSI/VT100 parser/virtual screen buffer (like `vte` or `alacritty_terminal`), serializing the text matrix and style attributes into Godot textures or custom Control nodes at 60+ FPS without thread deadlocks.

Discussion

20 comments analyzed.

Competitors mentioned: herdr, warp, tmux, alacritty

Concerns raised: RAM usage on the higher side, Documentation is LLM-written with verbosity and unclear sections, Binary size 60-80 MB, Performance and load testing not completed yet

Feature requests: Personal knowledge management system, Performance optimization for high agent counts, Browser support to expand mindshare

Competitors

Other products that read as similar to this one — 203 launches clear the similarity bar, closest 8 shown.

Attention rank: #18 of 204 (itself plus its competitors, highest first — normalized so YC and Product Hunt are compared fairly).

Launched 312 days after the earliest competitor.

Other launches for this product

Same idea, different domain

Nobody's really built a dev tools tool for Sales yet.