Version 1.1.0 shipped that same day. Today, July 20, we’re at 1.17.1.

Version numbers alone don’t mean much, so I counted what actually happened after that post went live: 31 releases, 55 merged pull requests, and 46 closed issues. I counted 24 groups of new user-facing features in the CHANGELOG, ignoring fixes, documentation, and internal details from the same delivery. If I split the new ai-memory run family into auto-selection, session adoption, Crush support, --yolo, search, and recovery, we’d blow past that number.

Fifteen people had PRs merged during that period, fourteen besides me. Special thanks go to Djalma Júnior, who alone had 24 PRs merged, Matheus Rodrigues, with five, lhzapata, with four, Thiago Silva and Cristiano Dewes, with two each. Nine more contributors had a PR merged. This stopped being “a little program I made over a weekend” a while ago.

I’m not going to dump 55 PRs here. I want to talk about the change that affects my daily use the most: the new ai-memory run.

The session is part of the project too

Code is the result that survived. It doesn’t preserve the entire investigation.

Git shows that you replaced Redis with SQLite. Maybe the commit explains part of it. But where is the Redis experiment? Where is the intermittent bug that only showed up with two workers? Who remembered that the first solution broke on Windows? Why did the team change its mind after three hours? Which workaround was temporary, and which one became the decision?

Much of that exists only in the agent session.

When I program with Claude Code or Codex, the session accumulates the project’s operational reasoning: questions, corrections, discarded attempts, test results, surprises, decisions, and changes in direction. The final code shows what stayed. The session explains how we got there.

And an LLM session, at the end of the day, is text. Claude Code writes JSONL. Codex does too. OpenCode uses SQLite. Pi, OMP, and Crush have their own formats and directories. Each harness packages the conversation differently, but the visible content is still messages and tool results.

Why should I leave the most expensive part of the work trapped inside the harness?

Anthropic can change limits, pricing, models, or formats tomorrow. OpenAI can too. An agent can be excellent this week and unbearable the next. I want to swap the engine without throwing away the whole trip.

That has been ai-memory’s thesis from the start: the programmer must remain independent of provider whims. Models and harnesses are replaceable. The project memory is mine.

Handoffs solved only half the problem

ai-memory already handled handoffs. I would close Claude Code, the hooks would consolidate the session, and the next Codex would receive a short summary with what had been done, open questions, and next steps.

That still exists and is still useful. Anyone who opens claude, codex, or opencode directly keeps the previous behavior. The new launcher is opt-in.

But a handoff is deliberately lossy compression. It preserves what seems most important at that moment. It isn’t meant to carry the entire session or resume each harness’s native session. If the summary left out an old attempt that became relevant again two hours later, you have to search the wiki or the records.

ai-memory run adds another layer: a managed workstream, one line of work that crosses harnesses.

Claude now, Codex in a little while

Basic usage looks like this:

cd ~/Projects/meu-projeto

ai-memory run claude
# work, then exit Claude Code normally

ai-memory run codex --yolo
# Codex continues the same line of work

ai-memory run claude --model opus
# return to Claude's previous native session

ai-memory run
# or let ai-memory choose the right harness to continue

You don’t need -- to separate arguments. Everything after the harness name goes to it, with one deliberate exception: --yolo belongs to the wrapper and is translated into the native dangerous option for Claude Code, Codex, OpenCode, Pi, or Crush.

Under the hood, ai-memory doesn’t try to convert a Codex file into a Claude file. That would be fragile and would probably break on the next update. Each harness keeps its own native session. The workstream connects those sessions to a portable ledger containing the visible part of the conversation.

Think of it this way:

Claude native session ─┐
Codex native session  ─┼─ workstream ─ portable context
OpenCode session      ─┤                 + full search
Pi native session     ─┘

The first time Claude enters that workstream, it gets a native session. When you switch to Codex, Codex gets its own native session and receives the portable delta it hasn’t seen yet. When you return to Claude, the launcher uses Claude Code’s own --resume and delivers only what happened in the other harnesses since the last visit.

This is very different from starting a new chat with a summary pasted into the prompt. Claude returns to its real session. Codex returns to its real session. ai-memory handles continuity between the two.

Managed mode currently supports Claude Code, Codex, OpenCode, Pi, Crush, and OMP. General ai-memory support is broader, with MCP and hooks for other clients, but that doesn’t mean every client already has a native-session adapter for run. Those are different contracts, and I prefer to make that explicit.

What goes into the workstream

When the harness exits, ai-memory reads the tail of the native session without modifying the original store. It imports visible user and assistant messages, completed tool calls with their results, compaction summaries, and a non-mutating Git checkpoint. Every event keeps its origin: Claude, Codex, OpenCode, Pi, Crush, or OMP.

Provider credentials, encrypted records, system and developer prompts, and hidden reasoning stay out. Private formats the adapter doesn’t understand stay out too and produce a loss annotation instead of letting the system pretend it imported everything.

Records pass through the sanitizer before entering ai-memory’s searchable ledger and immutable JSONL segments. The adapter opens native stores read-only; the harness itself remains the writer.

I don’t cram the entire session into the next prompt either. That would recreate the problem the project is trying to solve: too much raw context, too much cost, and too much noise. The next agent gets a size-limited recent delta. If an old decision matters again, the full ledger remains searchable:

ai-memory workstream-search "por que desistimos do Redis"
ai-memory workstream-search --limit 50 --json "migration que falhou"

Inside an ai-memory run, the workstream ID is already in the environment. The agent doesn’t have to discover some UUID.

And the ledger doesn’t replace the wiki. It handles operational continuity. Decisions, rules, procedures, and gotchas that need to survive for months still deserve consolidated Markdown pages. A raw session is evidence. A wiki is organized knowledge.

Can I keep more than one line of work?

Yes. The default workstream is called default, selected by repository and worktree. If I want an independent line for an investigation without contaminating the main work:

ai-memory run --new investigar-race claude

# later, continue that line with another harness
ai-memory run --workstream investigar-race codex

A lease prevents two windows from writing to the same workstream at once. On a normal exit, the launcher imports the tail of the session and releases it immediately. If someone kills the process without cleanup, the lease expires within 90 seconds and the next run resumes from the last confirmed cursor without duplicating imported events.

One stupid annoyance kept coming back: I would reopen a project after a few days and have no idea whether the newest session was in Claude or Codex. I’d guess, open one, realize the context was in the other, close it, and try again.

Now I just run:

ai-memory run

# or keep the same auto-selection in YOLO mode
ai-memory run --yolo

In an empty workstream, ai-memory looks for local sessions from that checkout in Claude Code, Codex, OpenCode, Pi, and Crush, finds the newest one, and opens the right harness for me. In an established workstream, server memory beats the file timestamp: it returns to the last harness attached to that work instead of accidentally adopting an old session that happened to receive a newer write. OMP remains available when selected explicitly, but it doesn’t participate in auto-selection yet.

On the first explicit run, the launcher can also offer existing sessions from the same checkout for adoption. You can start using it without abandoning the chat that was already open before you updated ai-memory.

Other new features I actually use

I promised I wouldn’t read the entire changelog out loud, but a few changes from this month deserve a mention because they reduce work for the programmer.

A briefing before the first question

A project can request an automatic briefing at the start of every session:

[briefing]
inject_on_session_start = "true"
max_chars = 4000

ai-memory assembles a package with pinned pages, _rules/, _slots/, and recent titles. The agent starts with the project’s rules and basic state instead of spending the first conversation rediscovering the architecture. It’s opt-in because it consumes context on every SessionStart, including after a Claude /clear.

Global preferences and cross-project search

Preferences that apply to all my work can now live in the reserved _global scope: coding style, preferred tools, personal rules, and conventions that don’t belong to one specific repository. Normal queries already combine that scope with the current project.

For meta-repos that need to query several sibling projects all the time, there is another opt-in:

[recall]
default_global = "true"

With that, memory_query and memory_recent without an explicit scope search every project. I don’t turn it on in every repo because gratuitous global search only adds noise.

Less static instruction, more Agent Skills

The routing block in CLAUDE.md or AGENTS.md got smaller. Detailed instructions for when to search memory, consolidate, save a decision, or create a handoff moved into managed Agent Skills. One command installs or updates both without trampling the rest of the file:

ai-memory install-instructions

That reduces drift too. When the protocol changes, I update the managed package instead of hunting down an old prompt copied across forty repositories.

Privacy before the network

Each repo can now exclude paths from capture:

[capture]
ignore_paths = ["private/**", "~/personal-notes/**"]

When an integration recognizes a file tool and the path matches, the event is discarded locally before spool, queue, network, or server. The limits are clear: this isn’t magic DLP, it doesn’t understand every shell command, and it doesn’t track content quoted in free-form text. But it handles the verifiable case without selling a fake guarantee.

There are also new integrations with Kimi Code, Grok Build CLI, Devin, and Zero, an OpenCode Zen/Go provider, finalize-session for Codex, and workspace-administration improvements. Again: having MCP and a hook doesn’t automatically mean having ai-memory run. The README separates those levels.

Bonus: ai-jail on the outside, YOLO on the inside

Just over a week ago I wrote about how I protect myself from agents deleting my stuff. My recommendation remains the same: YOLO mode gives the best experience, provided the system limits the possible damage.

ai-jail reached version 1.15.0 and now understands the ai-memory launcher. My favorite way to work has become:

ai-jail ai-memory run codex --yolo

Or, when I want ai-memory to choose which harness should continue:

ai-jail ai-memory run --yolo

Order matters. ai-jail stays on the outside so the launcher and child process remain inside the same sandbox. ai-memory run by itself manages the session, but it doesn’t create a sandbox.

--yolo gets rid of the harness’s approval ceremony. ai-jail handles containment: the current project is read-write, home is replaced with tmpfs, necessary parts of agent state are mounted selectively, and sensitive directories such as .ssh, .gnupg, and .aws stay outside the jail. The new support also keeps ai-memory’s local state writable so hooks can maintain spools and cursors between runs.

ai-jail recognizes both the ai-memory layer and the selected harness. If you have Codex-specific global configuration, for example, it still applies when the actual command is ai-memory run codex. Even the status-bar redraw adjustment understands that the child is Codex.

This combination takes care of both annoyances at once: the agent stops asking for confirmation on every command, and the session stops belonging to the agent. You get the speed without handing over your entire home directory.

One more thing: ai-usagebar grew too

When I published the original ai-usagebar, it monitored Claude, Codex, Z.AI, and OpenRouter in a Waybar widget or TUI. Version 0.14.0 already covers eleven usage, spending, or balance integrations.

Kimi got the two pieces of information that really matter for coding: weekly subscription quota and the rolling five-hour window. Kilo, Novita, Moonshot, and Grok show remaining balance. A separate Anthropic Console integration shows API spending for the month without conflating it with the Claude Code subscription. It makes clear that the Cost API doesn’t include Priority Tier.

You can also register multiple Anthropic accounts, see weekly limits for specific models such as Fable, and get a pace marker. The bar doesn’t turn red just because it reached 40%; it compares the percentage spent with how much of the window has passed. If I used 40% in 20% of the week, I’m moving too fast. That’s the useful information.

The project outgrew Waybar. It has a native macOS menu bar app, a GNOME extension, and a standalone TUI. The newest addition is a local Claude Code context monitor: I press c, choose one of the recent sessions, and see how much of the window it has consumed. It reads limited tails from local JSONL files and doesn’t invent a percentage when it can’t determine the window size.

In my workflow, the three end up working together. ai-usagebar shows which subscription still has room. ai-memory run switches harnesses without throwing away the work. ai-jail lets the chosen one run in YOLO without unrestricted access to the machine.

Updating

The installation pages for all three projects cover every method, including AUR, Homebrew, and release binaries:

• ai-memory
• ai-jail
• ai-usagebar

After updating ai-memory, reinstall the hooks for the harnesses you plan to use in managed mode. The three main ones in my case:

ai-memory install-hooks --agent claude-code --apply
ai-memory install-hooks --agent codex --apply
ai-memory install-hooks --agent opencode --apply

Crush doesn’t need a hook in managed mode; it receives context through a temporary file configured only for the launched process. The managed workstreams documentation covers installation, privacy, recovery, and native arguments for each adapter.

Conclusion

A month ago, ai-memory could already turn a session into a wiki and hand off to the next agent. Now it can manage the line of work itself: adopt an existing session, keep one native session per harness, carry visible history, resume each client in its own format, and keep the entire ledger searchable.

For me, that’s the value. The code contains the implementation that won. The session contains the decisions, failed experiments, gotchas, unexpected bugs, and changes of mind that produced that implementation. Throwing all of it away every time you change providers is wasteful.

A raw transcript doesn’t solve the problem by itself either. It’s large, repetitive, and expensive to stuff into every context. ai-memory keeps the evidence, delivers only the recent delta, and uses consolidation to turn what deserves to survive into short Markdown pages.

There are still new formats to support, platform rough edges, and plenty of testing ahead. The difference is that there is now a real foundation, with an acceptance test that calls actual harnesses, 14 outside contributors with merged PRs in a little over a month, and daily use pushing the design forward.

I rent LLMs and subscriptions from whoever is delivering the best service today. My project’s session stays with me.

I like this phase. The project stops being “what I imagined in my setup” and becomes “what breaks on somebody else’s machine.” Then Windows shows up. macOS. Arch. AUR. Weird paths. Tokens saved somewhere else. Different shell. Different terminal. Annoying? Yes. Necessary? Also yes.

But today’s main dish is not ai-jail or ai-memory. It’s TUI. More specifically, my recent habit of writing small terminal tools in Rust with Ratatui, while wanting them to look like Bubble Tea.

The app I won’t open

Over the last few weeks I also worked on a private project I do not plan to open source. It’s a TUI to track my US bank account, investments, assets, positions, covered calls, open calls, all that boring grown-up stuff. I won’t publish the code because this tool was born glued to my financial workflow, my spreadsheets, my statements, and my internal hacks. Opening it would turn a tool for myself into free support for other people’s bank bugs. No thanks.

But I can show the general look. I censored what needed censoring:

Obvious note, but I’ll make it explicit: every value, ticker, position, and date shown in the screenshot is bogus demonstration data. It is not real account data, not my real portfolio, and not investment advice.

Every time I build a small TUI, the same question comes back: what stack should I use?

If I were writing everything by hand, I would probably pick Python or Go. They are more comfortable for this kind of small utility. Python because it is direct, full of libraries, great for scripts that talk to APIs and parse JSON. Go because it produces simple binaries, cross-platform support is sane, and the CLI ergonomics are good.

But today I rarely write all that code by hand. I orchestrate Claude, Codex, OpenCode, ask for reviews, ask for refactors, ask for tests. In that setup, Rust’s lack of ergonomics hurts less, because the LLM is the one fighting the borrow checker, trait bounds, and annoying lifetimes. I stay closer to reviewer and end user. And then Rust starts looking very attractive.

Good tooling. cargo is great. Tests are easy to run. Cross compile is manageable. The final binary is clean. Dumb memory bugs mostly disappear. I am not saying Rust is magically better than Go or Python for every TUI. It isn’t. But with an LLM writing most of it, the cost that would usually make me avoid Rust drops a lot. And current models are surprisingly competent with Rust, as long as you make them run tests, fix warnings, and you don’t accept the first version as if Moses brought it down from the mountain.

Ratatui is good, but I wanted the Charm look

Ratatui is a Rust library for building full terminal interfaces: dashboards, interactive apps, tables, lists, gauges, layouts, the whole thing we used to call “modern ncurses.” It grew out of tui-rs, and today it is probably the obvious path if you want to build a serious TUI in Rust.

Ratatui works well. My problem is taste: by default, I don’t find it pretty. Not ugly in the “this looks like a DOS program from 1993” sense. You can build good-looking stuff with it. But many Ratatui TUIs fall into that square, gray, functional look, like a datacenter admin panel.

I like the Charmbracelet vibe more. gum, for example, is a collection of commands that make shell scripts interactive without turning them into a festival of read -p and case. Prompt, select, filter, spinner, table, pager, styling. You can make a bash script feel like a decent app in minutes.

And then there is Bubble Tea, in Go, inspired by Elm architecture. You have a model, receive messages, update state, render a view. Simple idea, very good fit for terminal apps: state comes in, event comes in, view goes out. Charm also has visual taste I like: good colors, decent spacing, light components, nothing that looks like a WinForms form thrown into a terminal.

So I wanted this: stay in Rust with Ratatui, but steal the feeling of Bubble Tea. Not the whole runtime. Not a perfect clone. Just the visual direction and a few components.

That is how ratatui-bubbletea was born.

The project does not replace Ratatui. It sits on top. The idea is to offer a theme and component layer inspired by Bubble Tea/Bubbles, while still rendering through Ratatui.

Right now it is split into crates:

• ratatui-bubbletea-theme, with palette, helpers, and shared styles.
• ratatui-bubbletea-components, with ready-made components like select list, spinner, progress, table, text input, viewport, and help.
• ratatui-tea, optional, for people who want ergonomics closer to Model, Msg, and Cmd, without pretending Rust became Go.

The README has the full examples and documentation for what exists today. For now, I treat it as a small toolkit. It serves my apps, and if it serves somebody else, fine. If it doesn’t, no drama either. The goal was to stop reimplementing the same theme and the same widgets every time I started a new TUI.

ai-usagebar as the public example

Since I won’t open the financial app, I needed a public example using this aesthetic. So I updated my ai-usagebar.

If you don’t remember it, I explained the project in “I Built a Waybar Widget for Omarchy to Monitor LLM Plan Usage: ai-usagebar”. It started as a Waybar widget to show LLM plan usage: Claude, OpenAI Codex/ChatGPT, Z.AI, OpenRouter. One glance at the bar and I know whether I am close to the limit and which vendor to use next.

Later it also became a standalone TUI. And thanks to contributions, it now supports Windows too. That is funny because its origin is completely Linux/Omarchy/Waybar. But that is open source: somebody uses it in another environment, finds friction, sends a PR, and now the project is a little less provincial.

In ai-usagebar, the visual change will not alter anybody’s life. It is a simple screen. Tabs, gauges, text, shortcuts. But it is a good example because it is small, real, tested, packaged, and does not depend on my private app. You can look at the code and see how I applied the theme layer.

The scratch-my-own-itch apps

All these projects follow the same logic: I have an itch, I make a small tool, I use it, adjust it, package it. No startup roadmap. No manifesto. Just a tool that fixes something annoying in my own setup.

One recent example is clock-tui. It did not start with me. It was an old Rust project, tclock, that looked abandoned. I wanted a big clock on my second vertical monitor. That monitor sits on the side, and I like having a huge desk clock taking up part of the screen. I used the original clock-tui for a while.

But an entire vertical screen just to show the time is wasteful. I already had ghpending, which lists open issues and PRs across all my projects. It is my “is anybody waiting for an answer?” in CLI form. I also wanted to see my agenda.

So I made another small app: google-calendar-tui. It uses the Gmail accounts already registered in GNOME Online Accounts and summarizes my upcoming appointments in the terminal. Read-only. No new OAuth ritual. No extra secret config scattered somewhere weird.

With those two pieces, I modernized clock-tui and added auto-refreshing widget layout support. Now the clock takes the screen the way I wanted, but around it I also get GitHub pending work and Google Calendar appointments.

This is exactly the kind of thing I would never build if it cost me an entire weekend. But with an LLM, it becomes a sequence of small tasks: read the old project, modernize dependencies, run tests, add a widget module, call ghpending, call google-calendar-tui, organize layout, fix bugs, package. It still takes work. But it is supervision and refinement work, not fighting boilerplate.

Tweaking Geary without a fork

Another itch came from GNOME.

Since I wanted to centralize my accounts in GNOME Online Accounts, I started using Geary and GNOME Calendar on the second monitor too. I like the idea: accounts configured once, desktop apps reusing the same infrastructure, no tiny program inventing its own login flow.

The problem is that Geary has a fixed three-column layout. On a normal screen, fine. On a vertical monitor, it gets cramped. The folder column, message list, and email body fight for space. I did not want to maintain a Geary fork just to hide a sidebar. Forking a large GTK app is debt. You blink and spend the rest of your life resolving merge conflicts.

So I made a GTK module: geary-hide-sidebar-module. It injects behavior into Geary at runtime and lets me collapse/expand the sidebar, with a shortcut and auto-collapse for narrow windows. No rebuilding Geary. No fork to maintain. Just a small module with one very specific job.

This is a good lesson: sometimes you do not need to fork the whole application. You can adjust it from the outside. GTK_MODULES exists. Wrappers exist. Config exists. CSS exists. Scripts exist. Not every customization has to become eternal maintenance of somebody else’s code.

Small code got cheap

That is why I keep insisting on this idea of small apps. With current LLMs, it became very easy to implement a specific idea to make your environment fit your needs. No waiting for someone else to have the exact same pain. No searching GitHub for three hours for a tool that does 80% of what you want and 40% of what you don’t want.

You describe the itch, create a repo, ask for a prototype, test it, ask for refactoring, ask for tests, ask for packaging. If it sucks, throw it away. If it works, install it and use it.

I do not let this turn into random junk dumped in ~/bin with no owner. My apps have tests. They have automated builds. Many have GitHub releases, AUR packages, normal installation with yay on Arch. They use XDG paths, so config goes to ~/.config, cache goes to ~/.cache, data goes to ~/.local/share. Organized. Upgradable. Removable. Something another person can clone and contribute to.

Here are all the links in one place:

• ratatui-bubbletea
• ai-usagebar
• clock-tui
• ghpending
• google-calendar-tui
• geary-hide-sidebar-module
• ai-jail
• ai-memory

If you use any of them and it breaks in your setup, open an issue. If you know how to fix it, send a PR. I actually use these tools, so useful bug reports tend to turn into fixes fast.

My practical rule is this: customize your environment without turning everything into duct tape. Build small tools. Test them. Package them. Document them. Let the LLM carry the boring weight and use your brain to decide what is worth keeping.

That is the fun part of programming that had gone missing for a bit. Now it is back.

I’ll repeat something important before someone starts cloning all my repositories thinking they are 1.0 products: most of the frank-* projects on my GitHub are proofs of concept. Experiments. Some work well for me, in my environment, in my workflow. That does not mean they are ready to become a critical dependency in your company tomorrow morning. Want to play, contribute, study? Great. Just don’t confuse “I published it on GitHub” with “this is production ready.”

There are exceptions. FrankMD, for example, received a decent amount of contributions, tests, polish, real bug fixes, real use. Today it is much more stable than it was in the first post. Still, the point stands: these projects were born as a vibe-coding lab, not as a 3-year product plan with roadmap, enterprise support, and SLA.

This post is a roundup of what I learned in that lab. A few of my tools, a few habits, a few recommendations. Nothing mystical. No “revolutionary new way to program.” Old engineering with new tooling.

First: stop collecting agents

If you are a normal developer, you do not need 12 agents, 40 wrappers, 7 orchestrators, and a Kubernetes diagram to choose who gets to write an if.

In practice, focus on Claude Code, Codex, or opencode. That’s it.

Yes, Gemini CLI exists. Yes, Cursor exists. Yes, Windsurf, Crush, OpenClaw, Pi, Aider exist, and tomorrow another half-dozen will show up. I tested a bunch. Read my LLM benchmark posts, especially “LLM Benchmarks Part 3: DeepSeek, Kimi, MiMo”. The conclusion is boring and obvious: today, the best cost-benefit options for heavy programming are Opus 4.7 and GPT 5.5 on subsidized Pro/Plus/Max plans. Nothing comes close when the job is spending several hours a day with a real coding agent.

Paying directly for tokens is expensive. Paying for a subsidized monthly plan is much cheaper. That’s why I keep alternating between Claude Code and Codex: not because I want “multi-agent architecture,” but because the plans have limits and I work many hours in a row.

Are DeepSeek v4 and Kimi 2.6 cheaper? Yes. Are they usable? Yes. I like them for several cases. But for Agile Vibe Coding the way I’ve been advocating since “From Zero to Post-Production in 1 Week”, they are still lacking. They stumble more on continuity, long refactors, tests, understanding the whole project. Can you use them? Sure. But if the goal is consistent productivity, Opus and GPT are still the bar.

Running an open-source model locally is neat. I played with that a lot in the Minisforum MS-S1 Max with AMD AI Max+ 395 review. For one-shots, studying, playing with local inference, it’s fun. For Agile Vibe Coding all day, every day, it is still not practical. Latency, context, quality, setup maintenance, VRAM, all of it collects tax.

Running multiple LLMs in parallel is not practical either, the whole “planner + executor + reviewer + judge” routine. I tested that in “LLM Benchmarks: Is It Worth Mixing 2 Models?”. The idea looks nice on paper. In practice, it increases cost, latency, error surface, and the gain does not pay for the complexity.

The secret is not having a bunch of agents. Forget OpenClaw or Pi for day-to-day programming. The secret is engineering process. XP. Tests. Clean Code for AI Agents. CI. Pair programming. Constant refactoring. Small code. Automated deploy. Fast feedback.

Tools help. Engineering wins.

ai-jail: autonomy with a fence

The first project I want to highlight is ai-jail. It is a sandbox wrapper to run AI agents with restricted system access. On Linux it uses bubblewrap (bwrap) and Landlock. On macOS it uses sandbox-exec. The idea is simple: the agent sees the environment it needs to work, but does not go rummaging through your whole system.

Do I use it every day? Yes. Do I use it always? No.

When I know I am not doing anything risky, I open claude or codex directly. If I am touching a simple project, just running tests, editing markdown, refactoring local stuff, often I do not bother. In more than 600 hours of intense Agile Vibe Coding, more than half a million lines of code and documentation, I never had one of those folklore cases of an LLM destroying my host system in some unrecoverable way.

And look, I explicitly used agents to configure my Omarchy. ZSH, Hyprland, Waybar, terminal configs, login scripts, all of it. They never did anything I did not ask for.

Those stories of “the agent deleted my whole home by itself” make me raise an eyebrow. In my experience, when you ask it to delete something dangerous, Claude and Codex ask for confirmation. You have to say yes. If you said yes without reading, that is not LLM black magic. That is user in zombie mode.

Nothing is guaranteed, of course. Hence ai-jail.

My favorite use is combining ai-jail with the harness’ no-brakes mode:

ai-jail claude --dangerously-allow-permissions
ai-jail codex --dangerously-bypass-approvals-and-sandbox

It sounds contradictory, but it makes sense. I remove the confirmation friction inside the agent, but put a fence at the operating-system level. The agent can work fast inside the project, but the host filesystem is essentially read-only. The current directory is read-write. Whatever I explicitly map with --rw-map is also read-write. The rest is not to be touched.

The ai-jail README sums it up well: it is a sandbox wrapper for agents like Claude Code, GPT Codex, OpenCode, and Crush. On the first run it creates a .ai-jail in the project, which can be committed. It supports --dry-run to see mounts before executing, --lockdown for a stricter mode, --private-home to hide real dotfiles, --mask .env to hide sensitive files inside the project itself, and isolated browser profiles for Chromium/Firefox.

Do not sell this as absolute security. Process sandboxing is not a VM. Kernel bugs exist. Side channels exist. macOS has limitations. The README itself is clear: if you need to isolate a truly hostile workload, use a disposable VM. I do not use ai-jail as “military-grade armor.” I use it as another layer, good enough for a development workflow.

And even inside the project, everything is Git. I push frequently to GitHub or to my private Gitea. So the realistic worst case is the agent destroying the project directory. Annoying? Yes. Catastrophic? No. I clone again. I come back from the remote. I redo what was local. If .git gets corrupted, I delete everything and clone again.

Secrets also have a copy outside. .env, tokens, keys, everything that matters sits in Bitwarden. Self-hosted in Vaultwarden, of course. So if I lose the local directory, I did not lose the keys to the kingdom.

The most common risk is not the agent deleting everything. It is you leaking a secret to Git. That happened to me more than once. You run git add ., forget a .env, push to the remote, congratulations. It happens. That’s why you must look at git status, git diff --cached, and think before pushing.

Even when it happens, LLMs are very competent at helping rewrite history. I ask them to clean the secret from Git, force-push, review that it disappeared, and then I rotate the key. It is not pretty, but it is manageable.

So yes, I recommend using Claude/Codex with dangerous permissions inside ai-jail. Is there a 0.001% chance of an unrecoverable accident? There is. But if you are a good engineer, that should not kill you. I have layers: automatic Btrfs snapshots, restic to my NAS, NAS archiving offsite to AWS Glacier, remote Git, Bitwarden. No tool replaces backups.

ai-memory: context that survives the harness

The second is ai-memory, which I explained in detail in “I Built a Memory System for Coding Agents: ai-memory”.

The motivation is simple: harnesses lose context. Claude Code compacts. Codex compacts. opencode compacts. The session ends. You open another agent and it does not know what happened in the last 4 hours. If you only use one harness, maybe it does not bother you much. If you alternate between Claude and Codex like I do, it gets annoying fast.

I wanted a long-term memory consolidator that worked across different harnesses. Something that allowed handoff between Claude, Codex, and opencode without me manually writing HANDOFF.md every time. Something that captured prompts, tool calls, and session events through hooks, consolidated them into markdown pages, indexed with SQLite/FTS5, and exposed everything through MCP when the agent needed to query it.

Another motivator was what I explained in “Is RAG Dead? Long Context, Grep, and the End of the Mandatory Vector DB”. For code projects, simple text almost always solves more than fancy vector DB architecture. Markdown, grep, SQLite FTS5, long context, and good files in docs/ already take you far. ai-memory follows that line: compile memory into text, leave it on disk, index it simply, and only call an LLM when consolidation is worth it.

ai-memory was not made to be a user-browsable knowledge base. It has a read-only web UI, yes, but that is for auditing and inspection. The memory is optimized for LLM consumption. It is an internal wiki the harness can query when it thinks it needs to. It is a place where I can explicitly ask “save this for the next session” and expect it to survive longer than Claude or Codex’s default compaction.

The README sums it up well: coding agents lose all context when the session ends; ai-memory gives them a shared persistent wiki. Every prompt, tool call, and decision can be captured automatically. At the end of the session, relevant pages are rewritten as coherent narrative. In the next session, another agent can receive a handoff already prepended into the context.

This is useful when you close Claude at 6pm, open Codex the next day in the same directory, and want it to know you were testing session cookies because JWT rotation had run into trouble. Or when you return to a project six weeks later and do not remember why you discarded Redis.

But do not confuse it with canonical documentation. If you did important research you do not want to lose, ask the agent to write markdown in docs/ inside the project. Architecture decision, benchmark, library analysis, deploy runbook, anything that must survive with guarantees should become an explicit file in the repo. That is simpler, auditable, and versioned.

ai-memory covers the middle band: transient information that might matter later. A weird bug that appeared. The reasoning that led to a decision. An environment gotcha. A session summary. Things you do not want to turn into official docs yet, but also do not want to throw away.

It is still beta. I use it in personal production, but it needs many more users beating on it. The most polished integrations today are Claude Code, Codex, and opencode. Gemini CLI, OpenClaw, and exotic MCP clients still need more testing. PRs are welcome. Bug reports too. “I installed it and it broke on my setup” is exactly the kind of feedback that reveals a wrong assumption.

ai-usagebar: knowing when to switch horses

As I said above, I prefer using Anthropic and OpenAI’s subsidized plans. The problem is that if you do real Agile Vibe Coding, you hit limits. Daily limit. Weekly limit. Session limit. Limit that changes. Limit that does not show up clearly anywhere.

I was using claudebar, which is good, but only covers Claude. I wanted to see the main vendors in one place. That became ai-usagebar, which I introduced in “I Built a Waybar Widget for Omarchy to Monitor LLM Plan Usage: ai-usagebar”.

It is a Waybar widget and Rust TUI to monitor Anthropic Claude, OpenAI Codex/ChatGPT, Z.AI GLM, and OpenRouter usage. For Claude and OpenAI, it reads the OAuth credentials the official CLIs already wrote. For Z.AI and OpenRouter, it uses API keys. It shows session percentage, reset, limits, balance, and lets you switch the primary vendor.

The value is banal and therefore useful: I glance at the bar and know whether I should continue in Claude, hand off to Codex, or top up OpenRouter credit. I do not want to discover I hit the weekly limit in the middle of a large refactor.

There is also a standalone TUI:

If you do not use Omarchy, Hyprland, or Waybar, you can still run ai-usagebar-tui in any terminal. SSH, tmux, normal terminal, whatever. The bar is convenience. The TUI is the universal form.

ghpending: GitHub pending stuff without the ritual

After the marathon, I ended up with dozens of ai-* and frank-* repos on GitHub. That creates an annoying problem: issues and pull requests start appearing. A contributor opens a PR. Someone reports a bug. Someone else sends a suggestion. If I have to open the browser, enter repo by repo, filter tab by tab, I will postpone it. And if I postpone it, I go weeks without answering contributors.

Yes, I could use gh, the official GitHub CLI. I do use it. But I wanted something dumber and faster: a short command to print a digest of everything pending in the repos I chose to monitor. That became ghpending, which I described in “I Built a CLI to Check My GitHub Pending Stuff: ghpending”.

That is it: ghpending add to choose repos, ghpending to see the digest, ghpending list, ghpending rm. Without auth it works with GitHub’s 60 req/h anonymous limit. With GITHUB_TOKEN=$(gh auth token) ghpending, it goes up to 5,000 req/h.

The point is not replacing GitHub. It is reducing friction. If I can run one command in the terminal and see “there are 3 PRs and 2 issues to look at,” I look. If it depends on browser ritual, notifications, and tabs, it waits.

And Claude/Codex are very good at this kind of work. You can ask:

“Check the open pull requests, review the code, see if it compiles, run the tests, add tests if missing, rebase from master if needed, merge and close.”

Or:

“Check the open issues, evaluate whether there is a real bug, reproduce it if possible, propose a fix, answer the user.”

They read the PR, understand the diff, run tests, rebase, solve simple conflicts, write the contributor response. You still keep your brain on. You are delegating mechanical work you already know how to do.

Refactoring: ask explicitly, several times

Claude and Codex are very good at refactoring, but do not assume they will do it automatically the way you would. I usually start projects or features with explicit instructions:

“Use Rust best practices. Avoid unnecessary duplication. Modularize only where it makes sense. Add unit tests for every new feature. Follow Clean Code principles. Do not create an abstraction before it is needed.”

After a large feature, a large fix, or a few hours of development, I stop and ask:

“Now that we touched a lot of code, re-evaluate it carefully. Delete dead code. Refactor obvious duplication. Add missing tests. Remove magic numbers. Check if any modules are too large. Do not change behavior without tests.”

Before release:

“Before publishing this version, do a sanity audit. Look for secret leaks, dangerous permissions, destructive commands, path traversal, unnecessary unwraps, missing validation, and anything that looks like an obvious vulnerability.”

Does that guarantee security? Of course not. Not even close. But it removes a lot of dumb mistakes. It is another layer. I like running this audit with Claude and then with Codex, because each one finds different things. Bugs still pass. Security is process, not a magic ritual.

Disposable experiments: code got cheap

Before choosing a library, framework, architecture, model, or service, I like creating experiments/.

Example:

“Before choosing between Qwen and DeepSeek, create a disposable prototype in experiments/ for an A/B test. Document the analysis in docs/ with result, cost, latency, quality, and recommendation.”

This changed how I decide. Before, many engineering decisions became opinion, feeling, faith in somebody else’s benchmark. Now code is cheap. I ask the agent to make two or three versions, run tests, measure, document, throw away what does not work.

Prototyping got genuinely fast. Frank Karaoke is a good example: turning YouTube into a karaoke app was the kind of idea I would maybe leave in a mental list for months, waiting for “a free weekend” that never arrives. Now I can open experiments/, ask for a rough prototype, test the technical path, and decide whether it deserves to become a project. Look at my other 2026 posts about frank-* and ai-* projects: almost all of them started like this, as disposable code that proved something before earning a name.

But cheap prototypes do not mean one-shot. I already wrote in “Why LLMs Aren’t Giving You the Result You Expect”: a good prompt is an iterative conversation. You provide context, show references, point out constraints, read the result, correct direction, ask for a rewrite. If you throw in a vague sentence and expect a finished product, that’s on you.

I learned this by taking a beating too. In the Frank Yomik post I described my first real vibe-coding failure: when the direction is wrong, insisting on the same prompt just digs the hole deeper. Sometimes you need to reduce scope, isolate the problem, create a test, change strategy. LLM does not turn a bad plan into good engineering.

And there are domains where you need to study along with it. In the DriveClub and shadPS4 post, AI almost sent me in every wrong direction because the problem required understanding rendering, gamma, shaders, buffers. The tool helps you explore, but you still decide whether the explanation makes sense. If you do not understand enough to verify, you are just accepting a pretty guess.

That is also why I keep repeating the idea from “Software Is Never Done”: deploy is not the finish line. The prototype becomes a product when it handles bug reports, maintenance, refactoring, docs, releases, rollbacks, users complaining. LLM helps a lot with that boring cycle. But the cycle still exists.

If it is testable, test it. If it can be measured, measure it. If it cannot be measured, at least write down the assumptions. The important thing is not choosing just because it “seems better.”

Cheap code also means detachment. Make code to throw away. Make an ugly prototype. Make a disposable benchmark. Ask the agent to document what it learned in docs/decision-qwen-vs-deepseek.md, then delete experiments/ if you want. The document stays. The lesson stays.

LLMs are also very good at documentation. Use that. Ask it to document everything. Why we chose PostgreSQL instead of SQLite in this case. Why the deploy uses a multi-stage Docker image. Why the service runs behind Cloudflare Tunnel. Why that sysctl exists. Even if you delete half of it later, the cost of writing fell near zero.

Automated deploy or you will stop maintaining it

Every project of mine that matters has automated build. Many run in my homelab, as I described in “Migrating my Home Server with Claude Code”. Almost every project has a bin/deploy that builds a Docker image, pushes it, rotates it on the server, applies migration if needed, and validates healthcheck.

Claude and Codex are excellent at deploy. They read bin/deploy, understand Dockerfile, edit GitHub Actions, adjust release workflows, fix binary signing, update Homebrew taps, generate checksums. And yes, I ask Claude/Codex to SSH into my homelab and redeploy Docker containers. They are very good at that. ai-jail, for example, has GitHub Actions to build signed binaries for Linux and macOS.

If you have dozens of projects, the more automated the better. I rarely type admin commands in the terminal by myself. I ask the LLM to do it, observe, approve what is dangerous, and then ask:

“Document what was done and why it was done.”

This applies to the homelab and my workstation. My Omarchy is customized through Claude: ZSH, Hyprland, Waybar, scripts, shortcuts, themes, integrations. Even my gaming/emulation setups fall into this, as I showed in the retro racing games running on Distrobox post. This is a case where I normally do not use ai-jail, because I actually want to touch the host. So I look at commands, read diffs, approve slowly. Even then, I never had the agent break my system in an unrecoverable way. Quite the opposite. My PC has never been more stable and documented.

Days later, when I forget why I configured something that way, the context is in markdown, Git, ai-memory, or the project history itself. I can ask and the agent has something to pull from.

Even this post was written this way

This is how I write these posts now. I dump a huge messy block from my brain into Claude. I ask it to read recent posts to calibrate style. I ask it to check the projects directly and elaborate the technical parts. I ask it to use the latest screenshots, upload to S3 when needed, link previous posts, review the tone.

Then I read and edit. I cut what sounds generic. I replace sentences that sound like release notes. I put my rants back in. The result is still my text; I just spend energy on what matters: deciding what to say, correcting nuance, cutting nonsense.

“But did you test Pi?”

Every time I mention an LLM or LLM tool, someone shows up in the comments with the same question: “but did you test Pi?”, “but did you test DeepSeek?”, “but what about Qwen?”, “but what about the new model that came out yesterday?” Every. Single. Time.

It is annoying as fuck. And almost always it comes from three kinds of people: someone who tested nothing and wants to outsource the work, someone who already chose a tool and wants me to validate their choice, or a fanboy treating an LLM vendor like a soccer team. They all sound the same. NPC repeating tutorial dialogue.

Software engineers should not decide based on other people’s opinions. Not even mine. If you choose a tool because “Akita said so,” you understood it wrong. I advocate Claude Code and Codex because I used them for hundreds of hours, in real projects, publishing code and post-mortems of what worked and what failed. And even then I did not stop at opinion.

I built my own automated benchmark: llm-coding-benchmark. I update it when a popular vendor releases a new version. I run comparable scenarios. I publish results. Then I adjust my opinion based on the data. That gives me enough ground to say that, in my workflow, Opus and GPT keep winning. Not because I woke up wanting to defend some billionaire company’s logo.

If your first reaction was “but did you test Qwen?”, great. Test it yourself. Run the benchmark. Create a better scenario. Send a PR. Show numbers. Show cost. Show latency. Show where it failed. Show where it won. Bring new data.

Loose opinion is irrelevant. “It works for me” does not scale. “I like it better” does not matter. “In my one-shot prompt it was better” is an anecdote. Engineering starts when something can be reproduced, compared, and acted on.

So it is simple: bring actionable data or shut the hell up. I do not need vendor fan clubs in the comments. I need people testing, measuring, and contributing new results.

Final checklist

Short summary, because this post is already long:

• Focus on Claude Code, Codex, or opencode. Stop collecting agents.
• Use Opus 4.7 and GPT 5.5 through Pro/Plus/Max plans when daily productivity matters.
• DeepSeek, Kimi, and local models are useful, but still do not replace the main workflow.
• Agile Vibe Coding is XP with LLM: tests, Clean Code, CI, pair programming, and deploy.
• Use ai-jail when you want agent autonomy with a filesystem fence.
• Combine ai-jail with dangerous Claude/Codex permissions when the project is protected by Git.
• Have real backup: Btrfs snapshots, restic, NAS, offsite, Git, Bitwarden.
• Review git add, git diff --cached, and pushes so you do not leak secrets.
• Use ai-memory for transient context and handoff between agents.
• Write canonical documentation in docs/ when information needs to survive with guarantees.
• Use ai-usagebar to know when to switch from Claude to Codex, or when to top up OpenRouter.
• Use ghpending so you do not abandon issues and PRs.
• Ask for refactoring explicitly after large features.
• Run a security audit before release, preferably with more than one model.
• Create disposable prototypes in experiments/ before deciding by faith.
• If you disagree with a benchmark, run llm-coding-benchmark and bring new data.
• Document decisions in markdown. Code got cheap. Documentation too.
• Automate deploy. If it depends on a manual ritual, you will stop doing it.

In the end, it is the same advice as always: tools change, engineering does not. LLM increases leverage. If you already had good habits, you will produce more. If you did not, you will just produce mess faster.

And yes, this changes the interface of the work. I already wrote about that in “VS Code Is the New Punch Card”: polishing pixels in an editor is now old-programmer nostalgia. The hard part is writing intent correctly, reviewing execution without being lazy, measuring results, throwing away cheap code, and not confusing opinion with data.

The problem with juggling several plans is keeping track of how much I’ve burned on each. I’d been using claudebar, a Waybar widget that shows your Anthropic plan usage. I like it, but I wanted to see all my vendors in one place, glance at it and know where I stand. And I didn’t want to clutter my Waybar with a separate widget per vendor. So I built my own: ai-usagebar.

It’s a Rust port of claudebar, drop-in compatible, extended to four vendors: Anthropic Claude, OpenAI Codex/ChatGPT, Z.AI (GLM), and OpenRouter. It keeps the same flags (--icon, --format, --tooltip-format, etc.), the same minimalist Pango-bordered tooltip, and the same Omarchy theme auto-detection. The difference is that now all four vendors show up in the same place, instead of 865 lines of bash babysitting just one.

How it authenticates with each vendor

This is the part worth explaining, because each vendor does it differently. Claude and Codex use OAuth: their official CLIs (claude and codex) already wrote the credentials to disk when you logged in, and ai-usagebar reads those same files. No environment variable needed, the token even refreshes itself.

Z.AI and OpenRouter use API keys, so for those you need to set a key (via env var or inline in the config).

The interface beyond Waybar

Besides the widget on the bar, there’s a tabbed TUI (ai-usagebar-tui) to see everything at once. Navigate with Tab / h / l between vendors, auto-refresh every 60s. You can open it by clicking the Waybar widget, or run it straight from the terminal (more on that in the next section).

The OpenRouter tab shows credit balance, today/week/month spend, and the tier:

And there’s a settings overlay to pick the primary vendor and paste the API keys without editing the config by hand:

Not on Omarchy or Hyprland? Run it as a standalone TUI

The Waybar widget is optional. The two binaries are independent, so if you don’t run Omarchy, or Hyprland, or Waybar (or you just prefer to check usage now and then instead of having it on the bar all the time), ai-usagebar-tui works as a fully standalone terminal app:

ai-usagebar-tui    # opens in your current terminal

It runs in any terminal emulator (Kitty, Alacritty, Foot, Ghostty, etc.), works even over a plain SSH session, and doesn’t depend on a compositor or any window-manager feature. All the controls and the settings overlay work the same. Same four vendors, same tabs:

Typical use off Omarchy: a quick check before starting a long session (“am I close to my Claude weekly limit?”), a monitor in a tmux pane while you code, or a shell-only tool on a remote machine (install the binary and that’s it, no Waybar or Hyprland dependency). The TUI is the canonical way to see all four vendors at once, whether or not you ever set up the widget.

Install

On Arch there’s an AUR package, two flavors:

yay -S ai-usagebar-bin    # prebuilt binary from GitHub Releases (~5s)
yay -S ai-usagebar        # compiles from source (~30-60s)

Or straight from source:

cargo build --release
sudo make install                  # → /usr/local/bin
# or
make install PREFIX=$HOME/.local   # → ~/.local/bin

The recommended Waybar config is a single module you scroll to cycle through vendors, with click to open the TUI:

"custom/aibar": {
    "exec": "ai-usagebar --format '{vendor_short} {session_pct}% · {session_reset}'",
    "return-type": "json",
    "interval": 300,
    "signal": 13,
    "tooltip": true,
    "on-click": "ai-usagebar-tui",
    "on-scroll-up":   "ai-usagebar --cycle-next",
    "on-scroll-down": "ai-usagebar --cycle-prev"
}

If you’d rather see all four vendors at once, you can use one module per vendor. The README has the full config detail, format placeholders, and the variations.

Why I built it

This looked like a Saturday-night little project, so I just did it. And it was: porting claudebar to Rust and adding the extra vendors I wanted was painless. I came out of one night with a widget that does exactly what I needed and is more reliable (tested, modular) than the original shell script.

If you use other vendors I didn’t cover, or you hit a bug, send an issue or pull request: github.com/akitaonrails/ai-usagebar. It’s MIT.