We’ve always found strace useful but somewhat hard to work with. Its output is often
inscrutable, it’s hard to follow subprocesses or threads, and if you want to filter
syscalls you have to rerun the trace with a flag for each one. What you want in debugging
is a tool for exploring, refining, etc., but strace can make this difficult.
Enter strace-ui, which turns strace into an interactive terminal UI:
strace-ui assigns short IDs to PIDs to make them easier to scan, formats structs, and
renders buffers as hexdumps instead of strings. It has some other nice features that you
can’t see in the screenshot:
- Interactive filtering. Tracing an async OCaml process? Did you forget to pass
-e? Don’t worry: press h to hide any syscall you
'!futex,timerfd_settime,epoll_wait'
don’t care about. - Trace a particular file-descriptor. Press > or < to jump to the next/previous
syscall that referenced the same file descriptor, or press F to change your filter
to only include syscalls that touch a given FD. (it’s slightly smarter than just numeric
FD filtering: strace-ui tries to track FD re-use and follow across forks, but it doesn’t
do a great job of that if you attach to a process that’s already opened FDs.) - What even is
rt_sigprocmask? Press m to open the man page and find out. - Subprocesses or threads are assigned short numeric labels, instead of showing you the
raw pid, making it easier to follow a complexstrace -fcalls. (You can also filter by
PID or exclude PIDs.) - DNS resolution: strace’s
--decode-fds=allwill print file descriptors as
14<TCP:[55.55.555.555:12345->11.11.11.11:56789]>, which is great. strace-ui goes one
step further and prints 14<TCP:[a-real-hostname:12345->another-hostname:56789]> , which
makes it easier to see at a glance exactly what your process is doing.
Ian Henry, a dev here, made
strace-ui to scratch his own itch. In 2017, he’d gone looking for such a tool but never
found it. Having had experience building interactive terminal UIs (including in OCaml,
using lambda_term), he knew how difficult and unpleasant it could be. The idea percolated
over the years, never feeling worth it, until recently when a few forces converged to
make terminal UI development actually kind of delightful.
Bonsai, a powerful framework for reactive UIs
For years now we’ve been building web applications with OCaml in a functional style, using
a library we developed called Bonsai, loosely
inspired by Elm. A simple Bonsai component with a little
interactivity looks like this:
module Dice = struct
let faces = ...
let component (graph @ local) =
let face, set_face = Bonsai.state (List.hd_exn faces) graph in
let%arr face and set_face in
{%html|
<div>
You rolled a #{face}
<button
style=""
on_click=%{fun _ ->
let index = Random.int (List.length faces) in
set_face (List.nth_exn faces index)}
>Roll the dice</button>
</div>
|}
end
Components are implemented as purely functional state machines, and are easily composable.
Incrementalization inside the framework means that values don’t get recomputed until
necessary. This applies to every value, not just the view.
What’s neat about Bonsai is that it allows you to compose state and incrementality
primitives a la carte. The same primitives that prevent re-rendering the entire page during
user interaction can also be used to incrementalize an expensive business logic computation
on a live-updating dataset. (If you’re used to React, imagine if everything used something
very similar to hooks, and state was managed outside of the component hierarchy.)
And because Bonsai is written in OCaml, it becomes possible to use the same language and
types on both the backend and frontend. It’s hard to overstate the impact this has on
keeping a large web app’s codebase manageable, especially when you make pervasive use of
OCaml’s type system.
Bonsai is not really a web framework
So far we’ve actually been talking about Bonsai_web. Bonsai itself is agnostic to the
frontend, because when you think about it, all UIs can fundamentally be expressed as
stateful incremental computations, in which different components know how to render
themselves as their underlying data changes.
If Bonsai is a library for managing the lifecycle and scoping of state, with a layer on top
for expressing the particulars of a given UI surface, you can see how the same underlying
core can be adapted. And that is where Bonsai_term came from.
When Ty Overby made Bonsai in 2019, the idea that it’d eventually end up being used for
terminal apps was a running joke. In some ways the whole point of Bonsai was that at Jane
Street we felt somewhat underpowered when it came to web development. Some of our most
important apps were built on the ancient and somewhat difficult
curses library, which lives
up to its name.
Terminal apps are fast and keyboard-centric, which we like, but the web also has a lot
going for it. It’s hard to beat the ergonomics of clicking a hyperlink; and of course the
web gives you a vast palette for constructing UIs, including charts and graphics that
aren’t practical on the command line, and integrated help (via tooltips and the like). In
the years after the release of Bonsai_web there was a huge flowering of web apps,
including many that were ported directly from the terminal.
But here we are in 2026 and it feels like another renaissance is afoot, this time in the
opposite direction.
Terminal UIs experience a comeback — the Claude Code effect?
Bonsai_term began as a personal hobby project in the summer of 2024, when Jose
Rodriguez—one of our devs—built it to write a manga reader with the kitty graphics
protocol. It showed enough promise that he later made some ncdu-style tools for wider Jane
Street use. In April 2025, Bonsai_term had enough traction that we started
productionizing it in earnest.
It so happened that AI agents were coming onto the scene, and it was the arrival of Claude
Code in February 2025 that kicked everything into gear. It became clear fairly quickly
that a well-made terminal app was winning out over full-featured IDEs, in large part
because of the speed, simplicity, and portability of the terminal itself. Terminal
emulators are everywhere and deeply integrated into editors; TUIs met devs where they
already were. In the beginning was the command
line, and so it
remains—ubiquitous and always at hand.
We doubled down on Bonsai_term, and pretty soon a feedback loop came into being. We
developed our own Claude Code–ish tool, called AIDE, (which we built to maintain the
freedom to choose between different model vendors, to suit our unusual development
environment, and to better control the execution sandbox), which became both a demo of
Bonsai_term and a partner in creating it. While building AIDE into a full-featured
agent-harness, we threw off a rich library of UI components that other apps could then
take advantage of.
Developers who became acquainted with this unusually good TUI were pleased to discover
that they could make their own terminal apps with just as much polish thanks to the new
framework it was built in. Bonsai_term would feel familiar to anyone who’d ever done web
development here, and it had the huge advantage of being especially amenable to AI
assistance. It was actually somewhat of a mystery to us how good the models were at
writing Bonsai_term code, given how relatively obscure it is and how it relies, for
example, on OxCaml-only features. (We think it might have something
to do with the testing story, discussed below.)
Then, recently, with the advent of Bonsai_term and AI agents, Ian found he could
make a working prototype in less than ten minutes. The prototype was useful enough to
justify the ongoing time spent making it real.
Notice how the ‘expect’ block in these tests contains a rendering of the actual UI
Closing the loop with screenshot tests
One of the most powerful features of Bonsai_term, which complements AI development
nicely, is its testing framework. You can easily write integration tests that literally
just walk through using the app in the terminal app and print its state—which looks like a
screenshot—at any moment. Because everything is text, this is a straightforward
application of our expect test
framework, and as with regular expect tests, regressions or changes in behavior manifest
as diffs.
Importantly, these tests are trivial for a coding agent to run and the output is legible
for the agent too. That closed loop makes it easy for the AI to check its own work and
results in features that are more often correct on the first try. The experience was so
good in fact that much of the development time for strace-ui was focused on the kinds of
output that the agent couldn’t see from the tests, for instance the performance
characteristics of scrolling, filtering, and rendering. (It also had a really hard time
with file-descriptor tracking.)
A million terminal apps bloom
If you watched our internal search engine for mentions of Bonsai_term, you’d find that a
handful of new apps are being built every day. Some examples:
- A time travelling debugger TUI for a trading system.
- A TUI for automating Linux administrative tasks.
- A monitoring TUI for our internal CI system.
- TUIs for orchestrating and monitoring agentic coding sessions.
- A TUI for running and managing agentic evals.
- TUIs for managing deployments and rolls.
- A TUI for exploring logs.
- Terminal charting libraries.
We can’t show screenshots of all of these in a public post, but here are two we can share:
proctopus, for managing multi-process applications, and dissect, for decomposing bloat
in executables.
The uptick likely goes back to the same forces that led to strace-ui:
- Terminal apps are lightweight, fast, and available everywhere a dev is
- With Bonsai_term you can build terminal apps in a declarative, type-safe way, sharing
code between the backend and frontend - You don’t need to have used Bonsai before to get started
- AIs “speak Bonsai_term,” and the closed loop with screenshot-style expect tests means
that both you and the agent can see what the app is doing; feedback is fast and accurate - There’s a healthy component ecosystem, and because Bonsai components are nicely
composable you can build fairly sophisticated apps by stitching existing components
together
There’s one extra benefit that’s a quirk of how Bonsai_web works. Bonsai_web
applications are written in OCaml but ported to JavaScript by a transpiler called
js_of_ocaml. The vagaries of browser APIs mean that some libraries that work fine on a
native platform can’t be linked into a js_of_ocaml program; and indeed one of the
biggest blockers in writing a Bonsai_web app is in carefully carving out the
Javascript-friendly parts of all of your dependent libraries. While much of this
carving-out has already been done over the years to support our web-app work, it’s far
from complete.
Bonsai_term doesn’t have this problem, which means that your TUI is more of a regular
OCaml program, and can use all the same libraries and tools and services as any other
application.
It’s been gratifying to see that getting the ergonomics right actually has a huge effect
on developer interest. A lot of devs at Jane Street now reach for Bonsai_term when
building little utilities for themselves or even sophisticated full-fledged applications,
where before it might not have been worth the investment. And by dint of being in the
terminal these apps are keyboard-driven, lightning-fast, and constrained in a useful
way—optimized for usefulness over flash. The web isn’t going anywhere, but seeing terminal
apps flourish again is like coming home.
Appendix: how to try strace-ui, Bonsai_term, and Proctopus
Want to try Bonsai_term out? You can read our install instructions
here. You can point your LLM at our examples
repo and then ask it to build your
own TUI. We highly recommend asking your LLM to write expect tests like this
one
for better results!
You can install proctopus and strace-ui by following their install instructions in their
readmes here and here.
