For AI agents: the complete documentation index is available at /en/llms.txt, the full documentation bundle is available at /en/llms-full.txt, and this page is available as Markdown at /en/guide/start/notes.md.
Hunea
  • English

      • Before we start

      This section is a bit long — mostly my own thoughts and considerations. Feel free to skip it; it doesn't affect using Hunea.

      But I do recommend reading Side notes 1, since it touches on Hunea's future development and direction. If you're interested in Hunea, or want to help it thrive, a quick look is worth your time.

      Side notes 1

      Developing Hunea and its companion project Nostra (as of writing this on 2026-08-04, Nostra is still in development and not yet released) has been a somewhat disorienting process for me.

      My goal at the start was simple, to make a TUI product I enjoy using myself. Because I relied heavily on AI to develop it, I was a bit casual at first and, for speed and convenience, used Go + Bubble Tea.

      It went reasonably well at first, but the further I got, the more something felt off. Maybe because I wasn't paying close enough attention, I gradually drifted off course and, after a month or two of tinkering, it ended in failure.

      I thought it over again and figured maybe I just hadn't picked the right direction. So I regrouped, started a new project, and kept iterating. The second time went much more smoothly than the first, still on Go + Bubble Tea.

      Then around early April, I kept feeling that something was odd, though I couldn't quite put my finger on it. Maybe it was because the AI kept failing to fix the lag with very long input in the composer. All of a sudden it hit me, would switching to Rust be more suitable?

      So I had the AI spend an afternoon migrating the code from Go to Rust (if you look at the earliest commits, you'll find they were all done in that single afternoon). The migration went smoothly — the features implemented and verified in Go worked well after the move to Rust, which gave me a lot of confidence.

      The flow from then on was simple: I'd pick a direction, have the AI drive it and test, then I'd do manual testing once it was implemented…

      I also have a bad habit: the AI I use isn't fast to begin with, yet I keep making it review repeatedly after finishing a feature, until there are no errors.

      As a result, I might only move one feature forward in a day, but the review takes several days — reviewing ten-plus times a day is common. (There may still be issues I missed or didn't find. Given my limited energy, I hope you'll bear with me.)

      That's also why, after all this time, I've only made 400+ commits. My efficiency isn't really high, and sometimes I get "defeated" by the AI or other things and can't make much progress for a whole day.

      Meanwhile, my wallet keeps "thinning out," and I can only sigh. Because I don't have a stable income — when I started this project I hadn't even graduated yet (and I've only just graduated now, haha). Wherever there's a free-tier station or a way to get some usage quota, I'll try to take part; if there's really no other option, I pay. (A big thank-you to the operators of those free-tier stations: Hunea wouldn't be where it is today without your efforts, and I can't thank you all individually. I can say with a clear conscience that I've always used it as one person, one window, one Agent; while developing Hunea I never or almost never used subagents. I hope I haven't caused any trouble for those who keep the free stations running, and thank you again for your selfless contributions.)

      In fact, during development, even though the AI did the heavy lifting, I still ran quite a few tests to try to find various potential problems. So a good portion of the git commits are about fixing things.

      I also put a lot of effort into chasing better visuals and rendering performance.

      I won't list everything from that period here.

      At night, when my mind wanders, I think of a lot of things to say, but when I sit down to write, I don't know where to begin.

      Let me just stop for now — I don't know how to say it all anyway.

      Maybe Hunea will keep being developed and maintained; I hope it will be accepted and loved by people. I have many features I hope to implement soon, and maybe I'll open a dedicated area to share some of my ideas.

      Of course, I very much welcome everyone's participation in making Hunea better!

      Finally, a special thank-you (any resemblance is purely coincidental):

      1. Gxx-5.1, Gxx-5.2, Gxx-5.4, Gxx-5.x, Gxx-5.x-Sxx (all with xhigh or equal or higher thinking budget) 80%
      2. Cxxxxx Oxxx 4.6, Fxxxx 5, Cxxxxx Oxxx 5 (all with xhigh thinking budget) 10%
      3. Gxx 5.2
      4. Gxxx 4.5
      5. Qxxx 3.7 Max
      6. Kxxx 2.6

      Side notes 2

      Actually, 2 came before 1, so part of 2 overlaps with 1.

      This one is mainly about what problems Hunea aims to solve.

      The idea for this tool started around late December 2025 through early 2026.

      By then there were already plenty of mature TUI tools: Claude Code (which I barely use), plus ones I have used more — droid (Factory), Codex CLI (OpenAI; the one I used longest), OpenCode (I think it already existed then?), and various Chinese ones like iFlow CLI (I recommended it to classmates for a while; it shut down on 2026-04-17), Qoder CLI, Neovate (I tried it; it seems unmaintained now), and others I no longer remember.

      For me, most of them had UX rough edges — fair enough for products that were still young. By the time this doc is written (July 2026), many of them are much more polished. Even so, some interactions still feel off: input editing, reading and copying messages, and other core flows I care about. If there is one big inspiration, Codex CLI helped a lot — you can see the overall TUI look is close to it, with my own observations from other CLIs mixed in. Is Hunea perfect? Of course not. I mainly wanted something pleasant for my own daily use. Where it ends up is hard to say, and I will not claim the world is ready to love TUI tools either. Personally I prefer TUI: lighter, fewer things installed on the machine, and usable over SSH on remote servers.

      From about January to March 2026 I first built on Go + Bubble Tea. Development felt fast and the UI was decent — until an early architecture mistake forced a full rewrite. I will not rehash that design error here.

      After thinking it through, I moved to the Rust ecosystem and chose an altscreen approach. I deliberately did not pin the input box to the bottom the way OpenCode and many other TUI products do. That pattern is familiar and fine for many people, but I dislike how a fixed bottom bar steals reading height — you end up resizing the terminal just to see more content. I dislike even more scrolling inside the input box when a draft gets long, which pushes me into nvim or another external editor just to reread what I typed. (A fixed bottom composer may still land later as an option, along with other layouts — never forced, always switchable in config.)

      Other things bothered me too: prompts and chrome everywhere, constantly interrupting the flow. Maybe that is just me. Either way, I did not want that design.

      So a lot of Hunea's direction comes from those friction points: a clean, consistent TUI; an unbounded composer that never collapses or scrolls inside itself no matter how long the draft is (external editors exist, but I wanted one consistent place to stay, so mouse click, selection replace, and similar helpers came with it); and other experience fixes.

      Prompt assembly, inspecting what actually gets sent, and related features exist to open the black box. I want a full, honest view of my inputs and the assistant's outputs. Someone might say you can already do this with packet capture or other tooling on top of existing CLIs.

      Fair point — I just do not want that much ceremony. And some tools, Claude Code among them, are not nearly that customizable; they stay black boxes. Core system prompts often cannot be replaced at all. Hunea can. You can replace them, sync across projects (with project vs global scopes; more may come later, but this is already useful), or disable them entirely. You can see what you sent, what came back, and what went out. No black box, fully transparent. The code is open source; no hidden side channels. Keep the defaults, rewrite prompts, or use someone else's later via a smoother path — all fine.

      I also want follow-ups around /prompt: different tool sets and prompt designs per model family, so each model can work closer to its strengths — GPT preferring patch-style tools, Claude preferring other patterns, Kimi / GLM quirks, how to guide DeepSeek comfortably, and so on (that last part is hard without collecting data, so it may come later).

      Those will be specialized rather than one prompt and one tool set forced onto every model. The work is large, but the goal is still low learning cost. The tedious parts should be done for you; open-box defaults with little configuration are a deliberate priority.

      In short, the problems I want to address:

      1. Opacity. Hunea is transparent and open, with no back doors. What prompt was sent and what came back is exactly what you see.
      2. Simplicity and low cognitive load. Little to almost no onboarding cliff. In an era where many tools feel built for agents first, I still want tools that feel good for people.
      3. Speed, small footprint, cross-platform. That is why TUI over web/GUI for now. I have put real work into making TUI feel better; other surfaces may come later, but that is longer-term.
      4. Freedom and extensibility. More of this will open up over time — eventually even a fully customizable core, though that is early to promise.
      5. Whatever else I forgot while typing this by hand.

      At the start the idea was simpler: just a TUI shell I liked using.

      I did not even plan a full agent at first. I wanted an ACP-based TUI wrapper around tools like Claude Code (you can still see that in early commits before the full rewrite and cleanup).

      The drawbacks piled up. ACP itself is incomplete, vendor support is uneven, and more importantly it did not solve the transparency problems I cared about. Needing to install someone else's product before using mine felt backwards, and I still would not know what that product was doing. Different vendors implement things differently — better to build one freer, more consistent platform myself.

      It is also a small attempt to raise the bar for this space at home. There are domestic TUI tools from large companies, but day-to-day use often feels awkward. Profit matters, sure — can the product at least feel less twisted to use?

      Finally: TUI stays light. Users should not need a pile of VS Code installs or browser tabs. Yes, TUI can look harder at first — that is what "Slow Start" is for. Windows users may still hit rough edges today because Windows has not been optimized yet; WSL2 or a Linux VM is the safer path for now.

      Windows is still high priority. Who says Windows is bad for development? I like it a lot — it just needs more time.