Something something medical researcher reinvents calculus.
In 2026: frontend web developer reinvents tmux.
Guys, please do us the service of pre-filtering your crack token dreams by investigating the tool stack which is already available in the terminal ... or at least give us the courtesy of explaining why your vibecoded Greenspun's 10th something is a significant leg up on what already exists, and perhaps has existed for many years, (and is therefore, in the training set, and is therefore, probably going to work perfectly out of the box).
Maybe, just maybe, this is of obvious utility to the many people who have needs that are not yours?
I very regularly need to interact with my work through a python interpreter. My work is scientific programming. So the variables might be arrays with millions of elements. In order to debug, optimize, verify, or improve in any way my work, I cannot rely on any other methods than interacting with the code as it's being run, or while everything is still in memory. So if I want to really leverage LLMs, especially to allow them to work semi-autonomously, they must be able to do the same.
I'm not going to dump tens of GB of stuff to a log file or send it around via pipes or whatever. Why is there a nan in an array that is the product of many earlier steps in a code that took an hour to run? Why are certain data in a 200k-variable system of equations much harder to fit than others, and which equations are in tension with each other to prevent better convergence?
Are interpreters and pdb not great, previously-existing tools for this kind of work? Does a new tool that lets LLMs/agents use them actually represent some sort of hack job because better solutions have existed for years?
See related sibling: the use cases are compelling!
My complaint is that tmux handles them perfectly. Exactly the claim that OP is making with their software - is served by robust 18 year old software.
In 2026, it costs nearly nothing to thoroughly and autonomously investigate related software — so yes I am going to be purposefully abrasive about it.
And if you want to interact with tmux from within the python interpreter there is a very good library available, libtmux:
I agree. We skipped CLIs and went all the way to TUIs because TUIs are "easy to make now"? Or maybe because claude/codex?
But in practice you are padding token counts of agents reading streams of TUIs instead of leveraging standard unix pipes that have been around from day 1.
TLDR - your agent wants a CLI anyway.
Disclaimer: still a cool project and thank you to the author for sharing.
The TUI makes more sense to humans who don’t understand the difference between a human and a machine.
hehe, i made something similar for feedback loop on claude hooks. claude can open another claude instance in the testing folder, and check to see if the hooks fire properly
Maybe I'll use this to feed prompts into an interactive Claude session so I can use my max subscription instead of having to pay for API credits when using claude -p
[deleted]
This is kind of fun, something I've been thinking about over the last couple days.
This is one area that makes me feel like our current LLM approach is just not quite general enough.
Yes, developers and power users love the command-line, because it is the most efficient way to accomplish many tasks. But it's rarely (never?) our only tool. We often reach for TUIs and GUIs.
I wish I was keeping better track of them all but there's a bunch of neat tmux based multi-agent systems. Agent of Empires for example has a ton of code around reading session data out of the various terminal uis.
https://github.com/njbrake/agent-of-empires
Ideally imo tui apps also would have accessibility APIs. The structured view of those APIs feels like it would be nice to have. And it would mean that an agent could just use accessibility and hit both gui and tui. For example voxcode recent submission does this on mac for understanding what file is open/line numbers.
https://github.com/jensneuse/voxcodehttps://news.ycombinator.com/item?id=47688582
Something something medical researcher reinvents calculus.
In 2026: frontend web developer reinvents tmux.
Guys, please do us the service of pre-filtering your crack token dreams by investigating the tool stack which is already available in the terminal ... or at least give us the courtesy of explaining why your vibecoded Greenspun's 10th something is a significant leg up on what already exists, and perhaps has existed for many years, (and is therefore, in the training set, and is therefore, probably going to work perfectly out of the box).
Maybe, just maybe, this is of obvious utility to the many people who have needs that are not yours?
I very regularly need to interact with my work through a python interpreter. My work is scientific programming. So the variables might be arrays with millions of elements. In order to debug, optimize, verify, or improve in any way my work, I cannot rely on any other methods than interacting with the code as it's being run, or while everything is still in memory. So if I want to really leverage LLMs, especially to allow them to work semi-autonomously, they must be able to do the same.
I'm not going to dump tens of GB of stuff to a log file or send it around via pipes or whatever. Why is there a nan in an array that is the product of many earlier steps in a code that took an hour to run? Why are certain data in a 200k-variable system of equations much harder to fit than others, and which equations are in tension with each other to prevent better convergence?
Are interpreters and pdb not great, previously-existing tools for this kind of work? Does a new tool that lets LLMs/agents use them actually represent some sort of hack job because better solutions have existed for years?
See related sibling: the use cases are compelling!
My complaint is that tmux handles them perfectly. Exactly the claim that OP is making with their software - is served by robust 18 year old software.
In 2026, it costs nearly nothing to thoroughly and autonomously investigate related software — so yes I am going to be purposefully abrasive about it.
And if you want to interact with tmux from within the python interpreter there is a very good library available, libtmux:
https://github.com/tmux-python/libtmux
> I'm not going to dump tens of GB of stuff to a log file
In the same vein as the parent comment, the curiosity is why you would vibe code a solution instead of reaching for grep.
You can start a tmux session and tell your agent about it and it will happily send commands and get the output from it.
I saw this post a while ago that turned me on to the idea: https://news.ycombinator.com/item?id=46570397
I agree. We skipped CLIs and went all the way to TUIs because TUIs are "easy to make now"? Or maybe because claude/codex?
But in practice you are padding token counts of agents reading streams of TUIs instead of leveraging standard unix pipes that have been around from day 1.
TLDR - your agent wants a CLI anyway.
Disclaimer: still a cool project and thank you to the author for sharing.
The TUI makes more sense to humans who don’t understand the difference between a human and a machine.
hehe, i made something similar for feedback loop on claude hooks. claude can open another claude instance in the testing folder, and check to see if the hooks fire properly
Maybe I'll use this to feed prompts into an interactive Claude session so I can use my max subscription instead of having to pay for API credits when using claude -p
This is kind of fun, something I've been thinking about over the last couple days.
This is one area that makes me feel like our current LLM approach is just not quite general enough.
Yes, developers and power users love the command-line, because it is the most efficient way to accomplish many tasks. But it's rarely (never?) our only tool. We often reach for TUIs and GUIs.
It's why approaches like this get me excited: https://si.inc/posts/fdm1/
I've had my agents using tmux for these use cases for a couple years now. What does TUI-use offer on top?
I've barely been using it lately, mostly leaving it disabled. But the tmux-mcp is pretty solid. https://github.com/nickgnd/tmux-mcp
I wish I was keeping better track of them all but there's a bunch of neat tmux based multi-agent systems. Agent of Empires for example has a ton of code around reading session data out of the various terminal uis. https://github.com/njbrake/agent-of-empires
Ideally imo tui apps also would have accessibility APIs. The structured view of those APIs feels like it would be nice to have. And it would mean that an agent could just use accessibility and hit both gui and tui. For example voxcode recent submission does this on mac for understanding what file is open/line numbers. https://github.com/jensneuse/voxcode https://news.ycombinator.com/item?id=47688582
Are they any good at nethack?
[dead]