better-agent-terminal: two bundle editions and a package version stuck at 0.0.1-dev

The manifest says 0.0.1-dev while the releases say v3.2.14

The version numbers in this project live in two places and they do not agree. The package manifest declares version 0.0.1-dev, a placeholder that would never ship, while the published releases are at v3.2.14, and the three most recent are pre-releases of that same build: v3.2.14-pre.1, pre.2 and pre.3, all on 2026-09-30, two of them within minutes of each other. That is a project comfortable cutting three candidate builds in an afternoon and promoting them later. The manifest also names the package manager, pnpm 10.33.2, and describes itself as a Windows terminal aggregator, a leftover from when the platform story was narrower than the current one, since the app ships a Tauri host for desktop, a React renderer, a Node sidecar and mobile builds for iOS and Android that require version 3.1.3 or later.

Two bundle editions with hard file-count and megabyte ceilings

The most interesting line in the scripts is the resource check, and it comes in two modes against one checker. The all-in-one mode runs with strict missing resources, a ceiling of seven thousand files and a ceiling of 850 megabytes. The lightweight mode uses the same script with fifty files and ten megabytes. So this is not one installer that happens to be small; it is one codebase shipping two editions, and the ceilings are enforced by a script that runs as a named npm task rather than by a convention someone remembers. A parallel pair of preview-readiness checks exists for the same two modes, plus separate verifications for packaged agent binaries and for release asset sizes. Whichever edition you install, someone has already written down the number it is allowed to weigh.

The pre-commit gate is a chain of a dozen commands

One script named for running before continuous integration chains the whole local gate in a single line, and it is worth reading because it shows what the project considers a regression. It starts with a TypeScript typecheck with no emit, then a Vite build, then bundle preparation for continuous integration, then a Rust check on the Tauri side, and after that a run of test suites: the Node sidecar, the host API, direct host calls, Claude coverage inside the host, Codex, message deduplication, and input history navigation, with the visible line cut off partway through the final name. Two observations. Type checking and compilation are separate steps, so a type error is not reported as a build failure. And the test list is named after the regressions it exists to catch, message deduplication among them, which suggests those bugs happened more than once.

The statusline says fifteen items and the table lists thirteen

The agent panel's status bar is introduced as configurable, with fifteen items across a left, a centre and a right zone. The table under that sentence names thirteen. Session id, git branch, tokens, turns, duration, context percentage, cost, workspace, five-hour usage and reset, seven-day usage and reset, maximum output, cache efficiency and prompts. Either two items are undocumented or the count is stale, and a reader designing their own template has no way to tell which. What the table does make clear is that most of these are live surfaces rather than labels. Clicking the session id resumes a past session, clicking tokens opens a context breakdown, clicking cache efficiency opens a history with a per-turn cost breakdown, and every item can be reordered, recoloured or switched off in a drag-and-drop template editor.

Four permission modes, two of them at the extremes

Tool execution is controlled by a four-way choice, and the names describe the mechanism rather than a policy. Default asks you to approve each tool call individually. Accept Edits approves file edits automatically and still prompts for everything else. Plan mode makes the agent write a plan file first, and approving that plan auto-executes it, so the single approval covers a whole sequence of calls. Bypass turns off approval entirely, and the page marks it as use with caution, which is the weakest warning in a document that is otherwise careful. Two mitigations sit next to it. There is a preset that spawns the agent in a separate git worktree, described as isolation to prevent destructive changes to the main working tree, and there is auto-compaction that fires when the token count crosses a threshold you configure.

Cache expiry is handled as a billing event

The cache features are the part of this project with a point of view. A floating badge shows the remaining life of the five-minute and one-hour cache windows, refreshing every thirty seconds and staying hidden until the session has been idle for a minute, so it cannot become noise. More telling is the expiry warning: when more than 150 thousand cached tokens have expired after an hour, a confirmation dialog appears before the prompt is sent, on the stated grounds of preventing accidental full-price reprocessing. Alongside that, cache history shows per-turn cache reads and writes with cost calculations per model, Opus, Sonnet and Haiku, and the cache efficiency item reports a percentage. This is the only agent frontend in this batch that treats a warm cache as a cost line rather than a latency feature.

Usage is read from OAuth or from a Chrome session key

Account handling is deliberately manual. A slash command switches between multiple Claude accounts, and rate-limit usage for the five-hour and seven-day windows is tracked either through Anthropic OAuth or through a Chrome session key, with both windows shown in the statusline next to a reset countdown. A separate panel breaks context usage down by category, naming code, conversation, tools, memory and MCP, so you can see which part of the window is full rather than only how full it is. The agent panel also persists conversations across restarts, can fork a session from any point in the conversation with the pending prompt sent automatically, and can put a session to rest and wake it again from the context menu to save resources. Subagent tasks are tracked separately, with progress, elapsed time and stall detection.

Electron is gone, a Node sidecar remains, and a temp script sits in the root

Version 3 is described as the Tauri-only release, with the Electron runtime removed and the stack rebuilt as a Rust and Tauri host, a React renderer, and a small bundled Node sidecar kept only where JavaScript SDK or runtime support is still required. The tree matches that split into a src-tauri directory, a renderer directory, a shared directory and the sidecar. Around them sit the pieces of a project that builds and ships on Windows: a choco directory, a Procfile variant for the worker panel, an install script, a test script, a server entry in bin, a runtime catalog, and a release note file at the root next to both a plan file and a plans directory. One entry does not belong: a file named .tmp-item7.py is committed at the repository root, which is either a leftover from a scripted edit or a stray test fixture that should not be in a release tree.

Editorial conclusion

This is one of the more considered agent frontends, and the parts that stand out are the cost surfaces rather than the terminal emulation: a statusline where every item is clickable into its own breakdown, a pre-send dialog when the cache has expired, and worktree isolation as a preset rather than a convention. Two things to check before you rely on it. Pick the bundle edition deliberately, because the two modes have hard ceilings of 850 or 10 megabytes and a file-count limit each, and a plugin or agent binary that pushes the all-in-one build over the line fails the check. And read the permission modes before you leave one on: bypass mode auto-approves everything, and the worktree preset is the only thing standing between a mistake and your working tree.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tony1223/better-agent-terminal on GitHub