And so I ended up with a TUI

2026-04-16T00:00:00+00:00

This is a short experience report about building a tiny TUI/CLI to inspect configured agents and model assignments in Opencode.</p>

I wanted a simple way to see which models were configured on which (sub)agents and their relative costs. I also did not want to spend much time building it. To me, this is an opportunity to try one-shotting it from a PRD.</p>

Basically:</p>

which agents exist</li>
which models they use</li>
how much those models cost per 1M tokens</li> </ul>
The result is a small CLI program called Opencode Config Lens</code></a>.</p>
In short, it scans ~/.config/opencode/</code> for the main config and can optionally include Weave config, which I am currently trialling. It then combines that with current pricing data from https://models.dev and renders a table that makes the configuration easier to inspect at a glance.</p>
Vibe coded</h2>The project was vibe-coded from a single PRD</a> that I created in a back-and-forth with GPT-5.4. Asking the coding agent to implement the PRD produced a working program.</p> After the initial generation, I made a few more functional changes and refactors</a>. I could not resist iterating, which is to be expected: building things tends to reveal new things. I also cleaned up a few things. I tell myself I am learning how LLMs work, or just trying not to release something too sloppy, but I am not sure I should not have stopped earlier.</p> So I ended up with a TUI</h2> This is also my first experiment with building an actual TUI application (using Ratatui</a>). It is probably overkill compared with a simple CLI table, but since I was instructing an LLM, the bar was low. Below is what it looks like.</p> </p> What is interesting is that I only had to ask for a TUI instead of a text-based CLI in my original spec. I literally changed it to: “build me a TUI application.” Asking an LLM to make those changes did not feel much different from asking for changes to a text-based CLI.</p> Reflections</h2> Despite the one-shot being fully functional, I kept iterating for a few more hours. I enjoyed it, but mostly because once you see the product, you get more ideas for improvement. Could I have built the CLI by hand in the same total amount of time? Probably not by much, and it would have been less good-looking and responsive. Definitely not a TUI.</p> I did not learn much about building a TUI or practising Rust, so there is that. But that was not really the goal. I wanted some basic insight, and I got that. I should probably get better at knowing when to stop.</p> This is also a program that probably would not have been written without LLMs. (I do appreciate the irony of using LLMs to build LLM tooling.)</p> Closing thought</h2> The program does its job well. It looks good, and I still find it surprising how easily you can get to this result with an LLM and a coding agent. Although the TUI worked from the start, I kept iterating not to fix bugs but to make it clearer and better. That feels similar to more professional development: it's only when you see the product or build it hands-on that you learn, get ideas, and improve.</p>

HanLHo. - Fractional Architect & Software Product Engineer - ratatui

And so I ended up with a TUI