Jane Street Blog – strace-ui, Bonsai_term, and the TUI renaissance

Enter strace-ui, which turns strace into an interactive terminal UI:

strace-ui gives short IDs to PIDs to make them easier to scan, formats structs, and presents buffers as hexdumps instead of strings. It has some other cool features that you can’t see in the screenshots:

• Interactive filtering. Tracing an async OCaml process? did you forget to pass -e
'!futex,timerfd_settime,epoll_wait'? Don’t worry: press h To hide any syscalls you don’t care about.
• Trace a particular file-descriptor. Press > Or < To go to the next/previous syscall that refers to the same file descriptor, press or F Change your filter to include only those syscalls that touch a given FD. (This is a bit smarter than just numerical FD filtering: strace-ui tries to track FD reuse and follow forks, but it doesn’t do a very good job if you connect to a process that has already opened the FD.)
• what is even rt_sigprocmask? Press m To open the man page and find out.
• Subprocesses or threads are given small numerical labels instead of showing you the raw pid, making it easier to follow complex strace -f Call. (You can also filter by PID or exclude PIDs.)
• DNS resolution: strace --decode-fds=all will print the file descriptor as 1411.11.11.11:56789]>, which is great. strace-ui goes one step further and prints 14other-hostname:56789]>, making it easy to see at a glance what your process is actually doing.

Ian Henry, a developer here, created Stress-UI to scratch his itch. In 2017, he went in search of such a device but never found it. Having experience creating interactive terminal UIs (including OCaml, using lambda_term), he knew how difficult and unpleasant it could be. The idea floated around for years, never quite seeming worth it, until recently when some forces united to make terminal UI development actually enjoyable.

Bonsai, a powerful framework for responsive UI

For several years now we have been building web applications in a functional style with OCaml, using a library we developed called Bonsai, which is heavily 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 dicebutton>
      div>
    |}
end

The components are implemented as fully functional state machines, and can be easily combined. Incrementing within the framework means that values ​​are not recalculated unless necessary. This applies to every value, not just the view.

The nice thing about Bonsai is that it allows you to write state and incremental primitives a la carte. The same primitives that prevent re-rendering the entire page during user interaction can also be used to increase expensive business logic computations on live-updating datasets. (If you’re used to React, imagine that everything uses something similar to hooks, and state is managed outside the component hierarchy.)

And since 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 can have on keeping a large web app’s codebase manageable, especially when you make extensive use of a system like OCaml.

Bonsai is not actually a web framework

So far we were actually talking about Bonsai_Web. Bonsai itself is agnostic to the frontend, because when you think about it, all UI can basically be expressed as stateful incremental computations, with different components knowing how to present themselves as their underlying data changes.

If Bonsai is a library for managing lifecycle and state scope, with a layer on top to express the details of a given UI surface, you can see how the same underlying core can be adapted. And this is where the word bonsai comes from.

When Ty Overby created Bonsai in 2019, the idea that it would eventually be used for terminal apps was a joke. In some ways the whole point of Bonsai was to make us at Jane Street feel somewhat underpowered when it came to web development. Some of our most important apps were built on the ancient and somewhat difficult Shaps library, which lives up to its name.

Terminal apps are fast and keyboard-centric, which we like, but there’s a lot more to it than that on the web, too. The ergonomics of clicking a hyperlink are hard to beat; And of course the web gives you a huge palette for building UIs, including charts and graphics that aren’t practical on the command line, and integrated help (via tooltips and the like). The years following the release of Bonsai_Web saw a proliferation of web apps, many of which were ported directly from the terminal.

But here we are in 2026 and it seems like another renaissance is underway, this time in the opposite direction.

Experience the return of terminal UI – cloud code impact?

Bonsai_Term began as a personal hobby project in the summer of 2024, when Jose Rodriguez—one of our developers—created it to write a manga reader with the Kitty graphics protocol. It showed enough promise that he later created some NCDU-style instruments for widespread use at Jane Street. In April 2025, Bonsai_Term gained so much popularity that we started producing it seriously.

It so happened that AI agents were arriving on the scene, and it was the arrival of Cloud Code in February 2025 that kicked everything into gear. It became clear fairly quickly that a well-built Terminal app was winning out over full-featured IDEs largely due to the speed, simplicity, and portability of the terminal. Terminal emulators are everywhere and deeply integrated into editors; TUI met developers where they already were. In the beginning there was the command line, and so it is ubiquitous and always at hand.

We doubled the bonsai_term, and very soon a feedback loop came into existence. We developed our own cloud code-ish tool, called AIDE, (which we created 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 building it. When building AIDE into a full-featured agent-harness, we removed a rich library of UI components that other apps could take advantage of.

Developers who became familiar with this unusually nice TUI were pleased to find that they could create their own terminal apps with the same new framework it was built on. The bonsai_term will look familiar to anyone who has ever done web development here, and it has the huge advantage of being particularly amenable to AI assistance. It was actually somewhat of a mystery to us. How The models were good at writing the bonsai_term code, given how relatively vague it is and how it depends, for example, only on OxCaml features. (We think this may have something to do with the testing story, discussed below.)

Then, more recently, with the advent of Bonsai_Term and AI agents, Ian found he could create a working prototype in less than ten minutes. The prototype was useful enough to justify the time taken to make it a reality.

Note how these tests involve rendering of the actual UI in the ‘expect’ block

Closing the loop with screenshot tests

One of the most powerful features of Bonsai_Term, which complements AI development well, is its testing framework. You can easily write integration tests that virtually run the app using the app in the Terminal app and print out its state – which looks like a screenshot – at any moment. Because everything is text, this is a straightforward application of our expectation testing framework, and with regular expectation tests, regressions or changes in behavior manifest as differences.

The important thing is that these tests are trivial for the coding agent and the output is also legible for the agent. That closed loop makes it easier for the AI ​​to check its own work and result in features that are often correct on the first try. The experience was so good in fact that much of Stress-UI’s development time was focused on the types of outputs that the agent couldn’t see from tests, for example 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’ve looked at our internal search engine for mentions of bonsai_terms, you’ll find that there are some new apps being created every day. some examples:

• TUI, a time traveling debugger for a trading system.
• A TUI for automating Linux administrative tasks.
• A monitoring TUI for our internal CI system.
• TUI for arranging and monitoring agentive coding sessions.
• A TUI to run and manage agentic evaluations.
• TUI for managing deployments and roles.
• A TUI for searching logs.
• Terminal Charting Library.

We can’t show screenshots of all of these in a public post, but here are two we can share:
proctopusfor managing multi-process applications, and dissectTo decompose bloat into executables.

The uptick likely goes back to the same forces that led to Stress-UI:

• Terminal apps are lightweight, fast, and available everywhere there is a developer.
• With Bonsai_Term you can build terminal apps in a declarative, type-safe way, sharing code between backend and frontend
• You don’t have to use bonsai before to get started
• The AI ​​”speaks bonsai_terms,” ​​and closed loop with screenshot-style expected tests means both you and the agent can see what the app is doing; Response is fast and accurate
• There’s a healthy component ecosystem here, and because Bonsai components combine well, you can create quite sophisticated apps by combining existing components together.

An added benefit is that there is 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 the browser API mean that some libraries that work properly on native platforms cannot be linked to a js_of_ocaml program; And in fact one of the biggest blockers in writing a Bonsai_Web app is carefully crafting the JavaScript-friendly parts of all your dependent libraries. Although much of this work has already been done over the last few years to support our web-app work, it is still not complete.

bonsai_terms doesn’t have this problem, meaning your TUI is a regular OCaml program, and can use all the same libraries and tools and services like any other application.

It’s gratifying to see that getting the ergonomics right really has a huge impact on developer interest. Many developers at Jane Street now reach out to Bonsai_Term when building small utilities for themselves or even sophisticated full applications where previously it might not have been worth the investment. And being in the terminal, these apps are keyboard-driven, lightning-fast, and user-friendly—optimized for usability on the fly. The Web isn’t going anywhere, but seeing terminal apps flourish again is like coming home.

Appendix: How to Try Stress-UI, Bonsai_Term, and Proctopus

Do you want to try Bonsai_Term? You can read our install instructions here. You can point your LLM to our example repo and then have it create its own TUI. We highly recommend asking your LLM to write such expected tests for better results!

you can install proctopus And strace-ui By following their install instructions in their readme here and here.