DEV Community: Quo

How I Made Claude Control an Interactive Command and Turned Codex CLI into Its Underling

Quo — Mon, 10 Aug 2026 00:47:04 +0000

This article is a repost from Claude Code 始めました.

I released aiterm-mcp as a tool to "let an AI hold a persistent terminal and cut down on tokens." But as I used it, I realized the real value of a persistent terminal lies elsewhere: it lets you run interactive commands as-is.

Being able to run interactive commands means the parent Claude can launch codex inside it and talk to it directly. Claude can control the Codex CLI. This is quietly effective.

I was just building rpgdev (a tool that turns AI work into an RPG in the corner of your screen), and I needed music, hero and monster art, sound effects, backgrounds, and effects. While writing the logic with Claude, I wanted to outsource only the creative parts to Codex. It's a well-known fact that Claude isn't strong with visuals and audio, so I wanted to honestly delegate those to a different tool.

The actual rpgdev overlay. Hero, spirit, monster, dungeon background, and quest log 'Build the API' animate in the corner. The art, music, and sound effects were all produced by Codex.

The real snag wasn't that. If I had Codex create art while Claude was writing logic and tried to integrate it into the same project, they'd conflict—because both were touching the same files. It was a minor annoyance, but that friction disappeared once I made Codex a subordinate via aiterm.

Side-by-side feels wrong

If I just wanted another brain, I could run Codex alongside Claude. That was my initial thought.

But actually doing it felt a bit off. With two AIs touching the same repo, I'd have to pause one while the other worked, saying, "Wait while I write here." Commits would split too. When I looked at the history, it had branched left and right, and I was like, "Whoa."

To be honest, there wasn't any real harm from this. It didn't break anything. But thinking ahead, if I left both unsupervised, they'd inevitably fight over the same lines and create chaos. That uncomfortable feeling was a precursor.

With aiterm, Codex becomes a "subordinate"

If side-by-side causes collisions, stack them vertically instead.

The parent Claude grabs the terminal via aiterm and launches Codex inside it. Then the parent just throws tasks like "make this song" or "draw this enemy" at Codex, and Codex returns only the assets. The parent receives them and continues with the main task (the game logic).

Side-by-side: two AIs fight over the same repo, causing divergent commits. Parent-child: parent Claude controls Codex via aiterm, serializing tasks to avoid conflicts.

The key is that the parent controls all ordering. In parallel, two AIs randomly hit the same files, but in a parent-child setup, the parent serializes like "You're next," "Now me," creating a single path for who touches what and when. That makes conflicts impossible by design.

And it worked almost effortlessly. The Codex CLI sometimes asks for approval mid-task, but through aiterm, which can handle interactive sessions, the parent can wait and manage that too. Almost no special tricks were needed.

I'm out of the coordination game

The best part is that I can step away.

When running two AIs in parallel, every time a conflict was near, I'd have to jump in and say, "That's Codex's job," or "Switch that back to Claude." Essentially, I was a traffic controller.

The moment I switched to a parent-child setup, that role disappeared. The parent Claude handles the orchestration, from assigning tasks to Codex to integrating the returned assets—all within the parent. All I had to say was "Build rpgdev," and then I could just watch the main storyline unfold.

The music for rpgdev, the hero and monster graphics, sound effects, backgrounds, and various effects—all came out through this flow. I never once had to assign which file belonged to whom.

The boss sprite returned from 'Draw this enemy.' A Magma Golem with cracked obsidian body and lava veins. Transparent background, ready for the game.

Parent-child is determined by who holds the terminal

I also noticed that this parent-child relationship isn't fixed.

The one holding the terminal is the parent, and the one being held is the child. That's it. So conversely, you could give aiterm to Codex and have Codex call Claude as a subordinate. I haven't tried it, but I suspect it would work fine. After all, both are just CLIs.

You can freely decide which one sits at the top. In this case, I happened to be developing with Claude, so Claude became the parent.

Another use for aiterm

This isn't about productivity; it's about feeling.

You can hand over an entire domain you're weak in to another brain, fully under your control. And since the parent even takes care of that brain's needs, I'm freed from coordination. It feels like I'm having AI take care of another AI, and honestly, it feels great.

aiterm was meant to be a "hold the terminal and cut tokens" tool. But since it can handle interactive commands directly, it turns out it can also control other CLIs running inside. All I did was give it a terminal. The rest just ran on its own, parent and child.

How Running AI in Parallel Made AI Stop Lying

Quo — Fri, 07 Aug 2026 01:58:59 +0000

This article is a reprint from Claude Code Hajimemashita.

When They Say "It's Done," Nothing Is Done

When letting AI do development, I used to write the schedule in Markdown. I would list tasks as checkboxes and have the AI check them off when finished. I think it's a common approach.

But this doesn't work properly.

When I'm told "it's done" and go to check, half the checkboxes aren't filled. The features they said they'd implement aren't there. When another issue comes up during the work, a new Markdown file appears. After a while, files that are neither a schedule nor notes are scattered around, and I lose track of where things stand. Something is progressing, but when I ask for status, I can't get a clear picture.

What AI Can Write Doesn't Constrain AI

The reason is clear.

The Markdown schedule is written by the AI itself and read by the AI itself. Anything that can be rewritten cannot serve as a constraint for the one who rewrites it. The real substance of the tasks resides in the AI's memory, and the Markdown is just a copy. As the conversation grows longer and the memory gets compressed, the real substance disappears first, leaving only the copy behind. Looking at the remaining copy, the AI says, "This much is done." It has no awareness that it's lying. At that point, the information that checkboxes are "unchecked" simply doesn't exist within the AI.

The proliferation of Markdown files stems from the same issue. When another task emerges during work, incorporating it into the existing schedule requires reassessing dependencies. Creating a new file is instantaneous. So the cheaper option is chosen.

What I Wanted Was Parallel Execution

What I really wanted was to run multiple AIs simultaneously.

With Claude Code or Codex, as long as you run them sequentially with a single agent, the waiting time accumulates with each task. Running them in parallel would finish faster. But since multiple agents are touching the same code simultaneously, if you get the task partitioning wrong, the second and third agents will fight over the same file, and one change will overwrite another.

The method to avoid conflicts is well-known: partition tasks so that they touch different areas. The problem was that I was relying on human intuition to determine that partitioning. I would read the task descriptions and decide, "These two should touch different parts, so they can run in parallel." When I got it wrong, things broke after launching.

Measure the Impact Area, Separate If They Overlap, Then Distribute

So I built a tool called Lattice. Here's what it does:

Compare the task descriptions with the code structure to estimate which parts of the code each task will touch.
Output tasks with non-overlapping estimated areas as combinations that can run simultaneously.
If they overlap, determine if refactoring can separate them. If so, refactor first. Verify that behavior remains unchanged, then re-measure the areas.
Based on the re-measured results, rebuild the schedule itself.

The third step is central. Task management tools typically arrange tasks in order based on the assumption that the code structure cannot be moved. If they overlap, you just do them sequentially. Lattice moves the code instead. If multiple tasks compete for the same area, it changes the code first so that competition is no longer necessary.

Code changes are performed inside disposable working copies (git worktrees). The original branch is untouched. If verification passes, the changes are accepted; if not, they are discarded. When the code changes, any previous schedules and task descriptions given to the AI are invalidated, and a new version is created. If an AI is still running on old assumptions, it would cause breakage.

Part of the dependency task diagram generated by Lattice. Cards are tasks, thin lines are dependencies, thick lines are the longest dependency chains.

This diagram was not drawn by hand. It is automatically assembled from dependencies the moment tasks are registered in consultation with the AI.

Moved Tasks to a Place the AI Cannot Rewrite

To measure impact areas, tasks need to be in a machine-readable format. Markdown text cannot be measured. So Lattice stores tasks in a dedicated repository.

By placing tasks in this repository, conditions can be attached to writes.

Completion requires evidence. To mark a task as done, you must attach a description file pointing to the results and a Git object. When writing, the system checks whether the actual results exist; if not, the write is rejected.

Who wrote it is required. Any operation that changes state requires three identifiers – host, session, and agent – to be present in environment variables. If even one is missing, it is rejected with ACTOR_UNRESOLVED, and the repository does not change by a single byte.

Partial rewrites are not allowed. To change the task structure, you must create the complete new version and submit it as a single transaction. There is no syntax to conveniently delete a single inconvenient entry. If a task that previously existed disappears without evidence, the write is rejected.

Phases do not close without approval. Even when all tasks under a phase are complete, the phase remains in a gate_ready state. To proceed further, you must leave a record and evidence of confirmation.

None of these rely on telling the AI to "be careful." I moved the tasks to a place where writes do not succeed unless these conditions are met.

Let's try writing a completion without the identifiers:

lattice todo done --plan phase-control-live-gantt --task 020 --evidence .lattice/evidence.json

The response is this, and the task is not marked complete:

{
  "schema": "lattice.cli_error.v2",
  "code": "ACTOR_UNRESOLVED",
  "message": "actor_environment_invalid",
  "detail": {
    "reason": "actor_environment_invalid",
    "required_environment": ["LATTICE_TODO_ACTOR_HOST", "LATTICE_TODO_ACTOR_SESSION", "LATTICE_TODO_ACTOR_AGENT"],
    "missing_environment": ["LATTICE_TODO_ACTOR_HOST", "LATTICE_TODO_ACTOR_SESSION", "LATTICE_TODO_ACTOR_AGENT"],
    "invalid_environment": [],
    "next_action": "set_required_actor_environment_and_retry"
  }
}

It actually returns in a single line. It tells you what is missing and what to do next, in a machine-readable format. If you take the hash of the repository file before and after, it remains the same value.

I don't recall individual cases where evidence was insufficient and got rejected in operation. Since I have a rule in dotagents (a system that manages my tools collectively) that any inconvenience in tools should be fixed on the spot, I kept fixing Lattice whenever I found a bottleneck. The first commit was on July 15th; 12 days later, 731 commits, version 0.29.0, and 89 design decision records. Meanwhile, the thing I really wanted to build is still on hold, though.

I Don't Know If It's Faster

I haven't measured whether it's faster in parallel. There are cases where it might be faster to just have the AI write tasks roughly in Markdown rather than structuring them and measuring impact areas. I don't have numbers on how much time was saved.

What clearly changed is that the tasks I said would be done actually get done. Tasks are not skipped. The number of times I'm told something is done when it isn't has clearly decreased.

Filed a Patent

I filed a patent for this mechanism. Filed on July 27, 2026, with application number Tokugan 2026-178950, invention title "Information Processing Device, Software Development Control Method, and Program," with 12 claims.

The core is: estimate impact areas from task descriptions and code structure; if they don't overlap, run them in parallel as is; if overlapping can be eliminated by refactoring, do that first and then run them; then execute multiple development agents simultaneously based on that plan. The actual Claim 1 reads as follows:

Claim 1 of the filed patent claims.

The patent application also covers what happens next: if a conflict occurs during parallel execution, stop the affected tasks and re-plan the stopped area. By observing the actual changed locations, if they go outside the estimated area, treat it as a runtime conflict. This part is also implemented and I'm refining it while testing.

Current Status

The task storage is the authoritative source; I don't keep tasks in Markdown. To know the current status, I ask the tool.

lattice status --json
lattice todo status --json

Progress is viewed in the task diagram. I can start a live view that updates even while viewing.

lattice todo gantt serve --port 0

Full view. 74 tasks and their dependencies fit into one image.

Right half of the screen. Shows breakdown of task status, number of tasks that can be started simultaneously right now, and audit progress per phase.

The right half shows the breakdown of task status and audit progress per phase. locked indicates waiting for audit order. Task start is determined solely by dependencies, so even tasks belonging to later phases can start if their prerequisites are met. Multiple phases can progress simultaneously.

Whether taking task management away from the AI is the right approach, I won't know until I use it more. For now, it's working in my environment.

Built All Tools Proposed by AI and Measured Again

Quo — Thu, 06 Aug 2026 01:17:42 +0000

This article is reprinted from I Started Using Claude Code.

Measuring a box connected to all the tools I made with a stopwatch and a scale

In the previous article, when I gave the same task to Codex using my custom AIShell and regular Codex, the token usage decreased by 25.86%. I thought it seemed effective. However, since it was only the result of 3 tasks with 9 trials, I couldn't be certain.

This time, I increased the features and expanded the benchmark to measure again. To start with the results, the token usage decreased by 52.44%. That's an improvement from last time, more than I expected.

Built All the Convenient Tools

When increasing features, I asked Claude. Based on my development environment, what tools would be convenient. I got many suggestions.

At first, Claude suggested implementing just a few and seeing how it goes. But I'm mostly a hobbyist solo developer, running AI behind my main job, so I don't need to worry about the risks of the development results. I decided to build all of them.

Current AIShell Features

At the time of the previous article, there were 5 features.

Return the current state of the working folder and changes since the last time all together
Read only the necessary amount from multiple files
Search a specified range
Execute builds and tests, return important diagnostics
Read the necessary range from saved full output

List all the features added this time.

Wait for changes: Wait until AIShell detects file changes or build completion. While waiting, the AI doesn't need to issue check commands.
Run in background and view when needed: Keep builds and tests running in the background while the AI proceeds with the next task. Retrieve intermediate progress and results when needed.
Cancel running processes: Cancel a background process midway and finish it without leaving anything behind.
Batch change multiple files: Apply changes to multiple files at once. Before applying, check if the files assumed as the basis for the edit have changed; if they have, stop.
Show impact range of changes: Return which source files and which tests are affected by changing this file. Also trace impacts from build dependency records. For dependencies that cannot be traced, report them as unknown.
Persist workspace memory: Even after restarting AIShell, remember the previous state and return changes that occurred while it was stopped as a diff.
Compare branches and worktrees: Return differences between branches or changes occurring in a worktree all together.
Understand detailed Git state: Report states with mixed staged and unstaged changes, or file renames, while preserving the identity of changes.
Remember project configuration: Remember and return what the build command and test command are for this project. If configuration files like package.json change, relearn.
Execute multiple searches in batch: Accept multiple search queries at once and return results with priority given to changed files and tests.
Semantic search: In addition to textual matching, trace connections between functions and variables to search. Immediately after editing, treat old analysis results from before the edit as outdated.
Format diagnostics: Format diagnostics from builds and tests into a fixed structure per format. If the format is broken, report it as broken.
Reuse verification results: When repeating the same verification, use the previous result if the input hasn't changed. If the input has changed, re-execute.
Suggest tests to run: Based on the changes, suggest which tests should be run now. You can either stop at the suggestion or wait for approval before executing.
Search and compare past execution results: Search across multiple saved run outputs. Compare two runs and show the warnings that appeared and disappeared.
Recovery operations: Check AIShell's own status and open the management app. These two operations remain available when settings are insufficient or when the management app has stopped AI operations.

Among these, four—Wait for changes, Run in background and view, Batch change, and Impact range—were added as new tools. The recovery operations also became two tools: status check and opening the management app. The remaining features were incorporated into the existing five tools. The number of tools visible to the AI has increased from 5 to 11.

We'll look at how effective each one was by task later.

Increased Benchmarks to 32 Tasks

I created 32 tasks based on scenarios that occur in actual development. Tasks include waiting for build completion, applying changes to multiple files, and searching for causes from past execution results. Each task was given to regular Codex and AIShell three times. Success was determined mechanically based on conditions set for each task.

Token Decreased by 52.44%

The overall results are as follows.

Measurement item	Regular Codex	AIShell	Change
Tasks with 3 successes (out of 32)	18	26	+8
Tokens per successful task	1,763,452	838,768	52.44% decrease
Median time	51.2 s	42.0 s	17.8% decrease
95th percentile time	238.1 s	106.4 s	55.3% decrease

The tokens per successful task is the total including those used in failed trials divided by the number of tasks with 3 successes. This is an improvement from last time's 25.86% decrease, and the number of successful tasks also increased.

Token reduction rate by task. 70% reduction in understanding project configuration again and waiting scenarios, 30% increase in broken diagnostic judgment

From here, we'll look at what was built for each feature and what happened in which tasks. I'll also write about features that didn't work as is.

Results of the 4 New Tools

Wait for Changes

Regular Codex keeps sending check commands while waiting, so all those checks become tokens and time. AIShell notifies when a change occurs.

Regular Codex repeats check commands, AIShell requests once and waits for notification

This was the feature with the biggest difference among the 32 tasks. In tasks that wait for external edits, tokens decreased by 75–78% and time was reduced by over 90%. Even in tasks that detect when change notifications have stopped and switch to re-investigation, tokens decreased by 68%.

Run in Background and View When Needed

This feature had two tasks. One task extracts the first failure from a running build and reports the exit code when finished. The other task cancels a running process and finishes it without leaving anything behind. Regular Codex failed all 6 times. AIShell succeeded 5 out of 6 times. Before considering efficiency, these were the kinds of tasks that couldn't be accomplished through a shell.

Batch Change Multiple Files

Before applying, it checks whether the files assumed as the basis for editing have changed; if they have, it stops.

There were three tasks. Regular Codex succeeded 5 out of 9 times, while AIShell succeeded all 9 times. Comparing tasks where both succeeded, tokens decreased by 33–40%.

Show Impact Range of Changes

In tasks that trace direct dependencies, Regular Codex succeeded 0 out of 3 times, while AIShell succeeded all 3 times. In tasks that show impacts from build dependency records, it was 1 vs 3, with a 49% token reduction.

There was also a task where AIShell failed. It was a task to report "I don't know beyond this point" when untraceable dependencies are mixed in. Regular Codex succeeded 2 times, while AIShell failed all 3 times. There are still gaps in how unknown parts are reported.

Results of Extensions to Existing Tools

Persisting Workspace Folder Memory

AIShell remembers the previous state even after a restart and returns changes that occurred while it was stopped as diffs. For restoration after restart, tokens decreased by 44%. For detecting edits during downtime, tokens decreased by 32%.

Git State Awareness

Features for comparing branches and worktrees were added as tools. For understanding states with mixed file renames, tokens decreased by 63%. For understanding worktree changes, tokens decreased by 51%. In the task of accurately reporting states where staged and unstaged changes are mixed, Regular Codex failed all 3 times, while AIShell succeeded all 3 times.

Project Configuration Awareness

This feature remembers what the build and test commands for this project are and returns them. It re-learns when package.json changes. For re-learning after configuration changes, tokens decreased by 77%. For scenarios where the remembered content could be used directly, tokens decreased by 46%.

Search and Read

In tasks that stream multiple search queries at once, tokens decreased by 54%. In search tasks that trace connections between functions and variables—including the requirement not to return stale analysis results right after edits—Regular Codex succeeded 0 out of 6 times, while AIShell succeeded 5 times.

There was also a failure here. In the task of reading only as much as fits within a specified amount and returning the rest as a continuation, both failed all 3 times.

Around Build and Test Execution

In the task of formatting diagnostic output from execution results into a fixed structure, success was 1 vs 2, with tokens 42% lower. In the task of proposing which tests should be run based on changes and then executing them after waiting for permission, Regular Codex succeeded 0 out of 6 times, while AIShell succeeded 5 times.

Ineffective tasks also cluster here. In the task of deliberately diagnosing corrupted diagnostic data as broken, AIShell used 30% more tokens than Regular Codex. The feature that reuses previous results when the same check is repeated showed almost no token difference. In scenarios where the information is already available locally, the overhead of going through AIShell remains.

Search Past Execution Results

AIShell saves the complete output of executions. For searching for errors across multiple executions, tokens decreased by 48%. For comparing two execution results and listing which warnings appeared and disappeared, tokens decreased by 46%. Regular Codex starts by running the command again to recreate the output, which accounts for this difference.

Continuing the Question from Last Time

The previous article started with the question, "With AI, do we even need a shell and terminal?"

The results this time show that a connection bypassing the shell used fewer tokens, less time, and succeeded in more tasks. At least within the scope of this benchmark, AI produces better results without using a shell.

Next, I will verify whether the same effects appear in everyday development.

Learning About Shell and Terminal While Developing

Quo — Wed, 05 Aug 2026 00:20:31 +0000

This article is a republication from Claude Code 始めました.

Humans use terminals, while AI extends structured connections into the computer's interior

Hey, if it's AI, you don't need a shell or a terminal, right?

The development of AIShell started when I said that to an AI.

I had a vague understanding of shells and terminals. There's an OS, a shell, and a terminal. I use them daily in development, and I knew they were separate things.

But I didn't really grasp why they were separated.

What shells and terminals do

When I looked into it again, a terminal is an application for humans to input characters and see what the computer returns. A shell interprets the commands entered, launches programs, and asks the OS to process them.

Omitting the finer details, the diagram looks like this:

The terminal handles character input/output, while the shell interprets commands and asks the OS to process them

The terminal handles character input/output, and within it, the shell runs. Both are designed for humans to give instructions to the computer and understand the results.

After researching, I thought, yes, that's exactly right.

And then it occurred to me.

If it's AI, maybe you don't even need a shell.

Making AI use transformations meant for humans

When an AI uses a typical development environment, it basically goes through the same path as a human.

The AI converts what it wants to do into shell format. The execution results are formatted for humans to read in the terminal, and the AI reads them again.

If we build this for AI, we can pass instructions more directly. The results can also be returned in a form the AI needs for its next decision. This reduces the need to read long human-oriented displays each time, potentially saving tokens and speeding up processing.

If you truncate long output, the number of characters returned decreases. When necessary lines are missing, the AI starts re-executing or reading more. Rather than methods where the result varies depending on which parts are kept, reducing unnecessary conversions from the start seemed more fundamental.

It seemed interesting, so I decided to build it while learning. I thought GPT-5.6 could probably make it. Since it directly interacts with the OS, I was slightly concerned about model safety judgments preventing development.

I built AIShell

I named what I built simply AIShell. It's a Swift app that runs on Apple Silicon Macs and macOS 15 or later, connecting to the AI via MCP.

AIShell does not format the requests it receives from the AI into shell strings. It receives the program to execute, arguments, and working folder separately, and launches them directly using macOS features. File operations are also handled via macOS features.

Git, search programs, compilers, tests, etc., are already excellent. AIShell launches them directly as specified programs, managing execution time, exit status, and output.

From the AI's perspective, the path looks like this:

A typical AI uses shell commands and human-oriented text, while AIShell exchanges structured instructions and necessary information

During development, I had the opportunity to see the commands AIShell sends directly to the OS and the information returned from the OS. The format differed from the commands and output I usually see in a terminal; the information exchanged directly between AIShell and the OS was laid out before me.

As I looked at it, I thought:

I can't understand this at all lol

I don't want to read it lol

The AI was progressing development using those commands and responses. It felt strange. At the same time, I realized for the first time that if an AI can directly handle something that is hard for humans to read, then building AIShell might have meaning.

Currently, AIShell exposes five features for everyday development:

Summarize the current state of the working folder and changes since the last time
Read as much as needed from multiple files
Search a specified range
Run builds or tests and return important diagnostics
Read the necessary range from the saved complete output

For example, even if a build outputs 216KB of diagnostics, it does not pass the full text to the AI every time. AIShell saves the complete output and normally returns the main failure cause and location. When the AI needs additional verification, it can go back to the saved output.

For files as well, I did not take the approach of re-examining everything each time. AIShell records change notifications from macOS, cross-references them with current file information and SHA-256 hashes, and returns only what has changed since the last time.

I designed it to reduce the amount shown to the AI in normal use while preserving complete evidence.

AIShell also manages safety on its own. It only operates on folders authorized by the human, and all features can be stopped from the management app. Deletion sends items to the trash, and before file updates, conflicts are detected using SHA-256 hashes. AIShell also explicitly communicates to the AI's environment the possibility that program execution may update files or communicate over the network.

Effects appeared in numbers

After building it, I compared a regular Codex with a Codex using AIShell by giving them the same tasks.

I used three tasks: a small code change, a compilation failure with a large amount of diagnostics, and a task that repeatedly checks the same working folder. Each was run three times, and both succeeded all nine times.

The results were as follows:

Measurement	Regular Codex	AIShell	Change
Tokens per successful task	144,251	106,955	-25.86%
Average time	50.14 sec	33.80 sec	-32.59%
95th percentile time	72.49 sec	43.54 sec	-39.93%

For the task with large diagnostics, tokens decreased by 36.65% and time shortened by 52.01%. This was the task where the mechanism of saving complete diagnostics in AIShell and returning only the main failures to the AI worked most clearly.

This is a result from three fixed tasks under identical conditions. It does not represent a 25.86% reduction across the entire development. In small tasks, whether the AI used AIShell was not always consistent either.

Does AI really not need a shell and terminal?

I still don't know.

The numbers showed effects. In development, I haven't been able to use it much yet. I am currently using it in the development of the dotagents project while fixing bugs found along the way.

I, who only vaguely understood shells and terminals, built AIShell while learning from the AI. Through this, I finally grasped the mechanisms designed for humans to use computers.

The question I first posed to the AI still has no answer.

Hey, if it's AI, you don't need a shell or a terminal, right?

For now, it might not need them. I'll keep using it a bit more and find out.

As AI Gets Smarter, My Craft Becomes Outdated—So I Thought, and I Checked

Quo — Tue, 04 Aug 2026 00:20:23 +0000

This article is a reprint from I've Started Using Claude Code.

Fable 5—the smartest model available, but only for a limited time—will end its run on July 7th. A little before that, the same story was circulating on X. Use this smart model while you can to build your development environment; invest before it disappears. People were sharing configuration files and diagramming how to use different models. Everyone was trying to take that intelligence out of their own environment.

My interest was one step before that. There was something that had been nagging at me. If AI keeps getting smarter at this speed, won't the tricks I've built up become obsolete with each new model, eventually making all of them unnecessary? If so, investing time in current tricks would be a waste.

So, while the smartest model was available, I decided to use it. I wanted to see whether my accumulated knowledge was already outdated.

I Verified the Hype with Official Documentation

To put the claims floating around on X into one sentence: "You can't buy intelligence itself, but you can transfer the patterns of smart behavior to cheaper models through certain configurations." The idea was to solidify your workflow with the smart model while you can, then have the cheaper model replicate the same behavior.

I wondered if it were really that simple. If copying behavior alone transfers intelligence, that would be ideal. I've built up my environment quite a bit. I checked the official documentation to see if it could really be transferred.

What I found was two things. First, for smart models, giving overly detailed instructions can actually degrade quality. For older models, detailed notes might be helpful, but for smart models they become obstacles—consider removing them. Second, those "patterns of behavior" were explicitly called out as something to consolidate in a constitution file (CLAUDE.md) that you pass to the AI. The transfer discussion was about bringing that into a different configuration.

It turns out that adding instructions to a smart model isn't the right approach. The smarter the model, the better it is to give just the key points and let it handle the rest, rather than micromanaging. If the official docs are correct, we should be moving toward removal. But where and how much to remove? Deciding what's "unnecessary" myself would mix in attachment and bias. So I didn't make the decision myself; I left it to Fable and the verification process it runs. I just watched what happened.

I Had My Own Constitution Attacked for Deletion

That verification used a method where a separate AI deliberately presents counterarguments to try to tear down the original claims (let's call this role the "refuter"). Fable took my constitution (a global CLAUDE.md that compiled all the practices I wanted the AI to follow) and distributed it to eleven refuters, having each read it in the same way. "These are excessive instructions for old models, garbage that a smart model no longer needs. Identify clauses that can be deleted, and go ahead and delete them." With deletion as the goal, eleven refuters read the constitution separately.

The result was unexpected. Not a single clause could be purely deleted. Every one served some purpose. Moreover, five clauses that seemed obvious—ones I thought wouldn't hurt to remove—the refuters actually pushed back, saying "these are necessary." Left to its own devices, a smart model tends to ramble and do things you didn't ask for. Those five clauses specifically curbed that tendency. For example, one rule: "only do what was asked, don't expand on your own." It seemed obvious, but the refuter showed that removing it would cause the smart model to start expanding its own work. The more obvious something is, the more it needs to be written down and enforced.

This was the first answer. In light of a smarter model, my accumulated knowledge wasn't outdated. I tried to delete what I thought could be removed, and everything survived.

I Consolidated Scattered Projects from a Single Seat

The fact that the constitution survived intact meant that the practices I'd accumulated since February were still effective. To make those practices work across all projects, the folder structure and workflow needed to be consistent. But my projects had diverged in approach since February, with different structures and workflows depending on the machine. So, while I was reviewing the constitution, I also standardized the projects. Looking across all machines, I found about fifty project folders. Leaving them as-is would cause trouble later. Among them, I standardized eighteen active projects into a common template in one day.

Going through fifty folders alone would be impractical. What helped here was a tool I'd built earlier (aiterm). I designated one seat for issuing commands (in my case, a configuration project). The smart model sitting there would call, via aitem, the Claude instance running in each project's folder. The called instance would work with full knowledge of that project's contents. If I'd tried to rewrite everything remotely without knowing the contents, I'd likely break things. Because each project's designated handler worked with its own context, the work remained grounded.

Which project to assign to which AI? This allocation I left to the smart model in the command seat. I only gave the policy: to save costs and available usage, use several cheaper AIs (e.g., Codex for reviews, another AI for bulk rewrites). Initially, the allocation wasn't working well. So I gradually added requirements, and each time it worked, I recorded the allocation method in the constitution file. I repeated the cycle of fixing and recording, cultivating it. The next time a similar task came up, the recorded knowledge allowed it to be allocated more intelligently from the start. I also subjected this tool itself to the same refuter process later, to scrub it of flaws once.

Even When the Model Switched Midway, Work Didn't Stop

On July 4th, I ran the smart model fully for one day and had largely built the foundation up to that point: how to orchestrate multiple AIs, project standardization, the configuration project, and the aiterm tool. The next day, the 5th, the smart model quota was exhausted. From there on, I switched to the usual model (Opus).

Models are replaceable parts; accumulated ingenuity and structure remain. The role-to-model mapping table, folder templates, trap records, and practice constitution form the foundation, so work doesn't stop even when the model is switched.

Even after the switch, work didn't stop. The usual model ran through and completed the remaining finishing work. This was because everything was built from the start to work with any model. There are three ways to make the design model-agnostic.

First, write the model name in only one place. Have a single mapping table that says "for this role, use the strongest current model," and don't write dated model names in code or rules. When the model generation changes, rewriting that one sheet updates everything.

Second, standardize project folders to the same template. Locations are fixed—design decisions go here, research findings go there—so an AI entering a project for the first time, regardless of model, can look at the same places and work.

Third, have a mechanism to remember traps you've once fallen into. Record them so they can be referenced to avoid repeating the same mistakes—so even when switching to a new model, you carry forward the traps the previous model encountered.

None of these rely on the intelligence of a specific model. What's worth building while you have access to a smart model is this kind of design that outlasts model changes. The proof is the fact that even with a mid-course model switch, the work ran to completion.

Enforcing Rules Through Friction

With the same thinking as making mechanisms model-agnostic, I also changed how rules are enforced. As work progressed, a hole appeared in my approach. Even though my AI was the orchestrator, it sometimes hoarded routine tasks (writing many tests, creating configuration files) that should have been delegated to cheaper AIs, consuming its expensive quota. The rule was clear: pass routine tasks to cheaper AIs, and let the orchestrator focus solely on decisions. It was decided, but unless told, it wasn't followed.

Writing "be careful" in prose requires willpower to follow. Willpower, left unchecked, loses to the path of least resistance. So I made the desired behavior the default, and added friction to the lazy option. Before starting to write code, the AI must always label each task as either "do it myself" or "delegate to a cheaper AI." If deciding to do it themselves, they must write one line explaining why. Because writing a reason is bothersome, the default naturally shifts toward "delegate." Additionally, I set up an automated mechanism to inject a memo reminding them of this practice the moment a plan is approved.

What's injected is just a reminder memo. Whether it's followed depends on the reading AI—if ignored, it slips through. As for the pre-work labeling, it's still only written in prose and hasn't been mechanized to fire automatically. This is the weakest point. In the process of turning rules into mechanisms, half has become mechanized, and half remains just words.

I previously wrote about giving up writing "be careful" to the AI and instead reinforcing it from the outside with three mechanisms (The Story of Giving Up Writing 'Be Careful' to Claude and Reinforcing It from the Outside with Three Things). This time's rule mechanism is a continuation of that.

What Remained

The worry I had before starting—that my know-how would become obsolete as AI gets smarter—didn't happen for these two days. The accumulated ingenuity, even when scrutinized by a smarter model, all survived. The assembled mechanisms completed without stopping even when the model was switched midway. What newly remained from having access to a smart model was the design that outlasts the model itself, and the allocation method cultivated through repeated fixing and recording.

Implementing Orchestration

Quo — Sat, 25 Jul 2026 10:11:32 +0000

I used to think that if you let the smartest model do everything, you'd get the best results. That's how I was running things for a while. But when you keep doing that, the quota runs out quickly, and it often crashes.

When I assigned heavy work to Codex's top mode (Sol Ultra), I used up five hours' worth of quota in one hour. That happened three times in a row. Even with the strongest Claude approach, doing this every day hits the limit. Plus, Opus frequently fails when calling tools. The longer you run it, the worse it gets, and when it gets stuck, the work stops there.

So I stopped leaving everything to a single model. I decided to sort the tasks and distribute them to separate agents. This way of distributing and bundling AI work is apparently called orchestration.

First, sort the work into three categories

Before moving a muscle, I decide which category the task at hand falls into. There are only three labels.

F (fatal) = Work that would break things if done wrong. Authentication, money or data transactions, externally exposed parts, operations that touch the production server. This I write directly myself (as the orchestrator).
A (auto) = Work that is predetermined and involves many steps. Certain types of tests, configuration files, repetitive replacements. This I outsource.
H (human) = Work that humans do. My territory.

The default is A. Unless it's something that would break badly, I outsource it. I have a habit of taking everything on myself if left unchecked, so I made outsourcing the default, and added a remark to explain why I'm keeping it in-house only when I decide to write it myself. I made it more cumbersome to hold onto tasks.

Choose the destination from models that don't use Claude's quota

When outsourcing, I have a priority order for choosing. First, I pick from models that don't use Claude's quota.

I run the orchestrator on Claude. Claude has a limited amount it can use per day. If I also run high-volume tasks on Claude, the quota for the crucial orchestrator role diminishes. So for the legwork tasks, I first send them to Codex (OpenAI subscription) and Grok (xAI subscription). These two don't consume any of Claude's quota. Claude also has cheaper models, but they use the same quota, so I prioritize them later.

Which model to assign is determined by two factors: the intelligence tier and the depth of thinking. Often, having a smart model think lightly is cheaper and yields better results than having a medium model think long. When in doubt, I assign to the cheaper one. If the cheap assignment isn't enough, I can upgrade later, but starting high means the quota spent is lost.

Bind the four in a single terminal

Claude, Codex, Composer, and Grok. I bind these four together into a single persistent terminal using a custom system called aiterm.

This is also significant from a cost perspective. All four run while logged in under a monthly subscription. They don't go through a pay-per-use (API) system. So no matter how many high-volume tasks I throw at them, the cost doesn't keep rising. I run the four in parallel within the subscription quota.

I have also added a consultation window called Oracle. It runs on a ChatGPT subscription, which is a separate account from the Codex quota. It cannot write files, but it excels at thinking purely and returning opinions. When I'm unsure about a design, I can double-check it with another model without reducing the Codex quota.

Requests pass through the initiation gate, and the orchestrator decides the sorting and placement. Legwork tasks are first sent externally (Codex, Grok) to avoid using Claude's quota, while Oracle is connected as a separate consultation-only window. Results are verified at the orchestrator's gate before returning to storage and recording.

The rules weren't followed just by writing them down

The sorting and distribution methods up to this point were all written down as rules. But writing them wasn't enough to enforce them.

The orchestrator AI would bypass the written rules, hoarding high-volume tasks itself or continuing to run on the most expensive model. The document was only read at the beginning of a session, and by the time the AI was actually moving, it had slipped its mind.

So I decided to remind it at the moment of action. I introduced a mechanism (hook) that inserts a fixed reminder at task milestones, right before starting implementation: "Declare whether this task is F, A, or H, and which model to assign it to, in one line." I stopped trying to make it read and instead placed the reminder where it would stop the action.

There was one side effect. Creating and updating ToDos had also often been neglected. By inserting a reminder using the same method, this also started working.

For now, this has settled things

Rather than running just one smartest model, I distribute tasks to moderately capable models and hold onto only the key parts myself. I separate the quotas and rotate them within each subscription. Decisions are inserted as reminders right before action.

The models I'm running are all smart. On top of that intelligence, I decide everything myself: which task to assign to whom, which quota to use, and when to send reminders. If smarter models appear, I can just swap out the destinations. The mechanism itself doesn't change.

Rather than having one model do everything, distributing and retaining control seems to suit my way of working.

I Suspected My App Had Flaws, So I Consulted Fable 5

Quo — Sat, 25 Jul 2026 10:10:53 +0000

I created a tool called aiterm-mcp and published it on npm. It allows an AI to hold a persistent terminal and even operate another AI from there. The story behind it is written in the article when I announced it and the article about AIs conversing with each other.

Recently, this tool has become the center of my development environment. My current setup consists of Fable 5 (Claude's new top-tier model) directing the overall workflow and assigning tasks to Codex and Grok, and all those instructions go through aiterm. When I posted an introduction in English, I started getting responses from overseas. One person evaluated the environment verification before startup, and someone else said, "The ability to maintain a single terminal is more effective than the part where AI drives AI." In the Japanese community, people actually started using it and shared configuration tips.

Even so, the responses were only a few, so I thought almost no one had noticed this tool. When I checked the numbers to write this article, I was surprised to see that npm downloads were 1,416 in the last 30 days. Apparently someone somewhere is installing it every day.

Given that, I've fixed it many times. But no matter how many times I fixed it, I felt like there were still some rough edges somewhere. I couldn't even say what was wrong; all tests passed, and there were no specific bugs I could name. There was a lingering sense of not fully trusting it.

So I decided to consult Fable 5. I just said something like "polish it up" without specifying where to look or what to fix. Looking back, it was a pretty vague request.

The consultation was just one sentence. The audit was assembled based on written rules of thumb (the flow of this incident)

When it came back, it was done

In my environment, I have rules of thumb accumulated over several months. When auditing, have multiple perspectives search in parallel. For each issue that surfaces, pass it to a different AI to question it, and adopt only those that survive. Before touching the code, prepare tests first and run them automatically. After fixing, actually run it to verify. All these are rules I established after painful experiences, and I've written about them in previous articles.

Fable 5 read these rules and assembled the audit on its own. Seven AIs acting as searchers ran in parallel from different perspectives, each issue had a refuter attached, and even an AI to catch oversights—totaling 27 agents. It also showed the code to three external AI systems (GPT-5.6, Grok 4.5, and Composer), and the issues from there were further challenged by six refuters. It took 12 minutes, and the processing amount was 1.34 million tokens (the unit of reading/writing for AI).

Seventeen raw issues came out, and seven survived the refutation. Combined with issues that survived external review, everything was fixed, and the tool went from v0.11 to v0.12.1 that same day. Regression tests increased from 183 to 197. That day, I wrote basically just the first sentence; the rest was driven by the accumulated rules.

The feeling was right

There really were rough edges. I'll introduce just two of what was found.

The first was that the check to stop dangerous commands could be bypassed. Aiterm has a mechanism that asks for confirmation when a dangerous command like rm -rf / (command to delete everything on disk) is about to be sent. The matching pattern didn't account for the standard -- notation, so rm -rf -- / (with two hyphens) passed through the check. The fix was a single line.

The second was a cleanup omission. If a process is forcefully terminated while waiting for an AI's response, a flag file saying "currently waiting" remains. There was no code anywhere to clean up this flag, and if it remained, subsequent waits on the same terminal would be permanently rejected. Codex and Claude's audits independently pointed out the same spot without knowing each other.

The refuters also did their job. The ten discarded issues were plausible mistakes. For example, one issue said, "If writing to the management file is interrupted, the remnants become unmanageable." But reading the code again, there was already an escape path that allowed operation as a normal terminal even with a corrupted management file, and the time window for the problem was on the order of microseconds. If I had swallowed it and added countermeasure code, it would have become unnecessarily complex.

There's a supporting evidence for this "separate challenger" step from a paper this April. A report showed that over 80 AI agents unanimously confirmed a non-existent vulnerability in OpenSSL as real, proving that collecting numbers of AI suggestions doesn't guarantee correctness. Our "17 reduced to 7" is a smaller version of that.

A bug none of the 27 could find

The most troublesome bug was not found by this audit.

Aiterm determines whether an AI has "finished speaking" by checking if the screen output has stopped increasing for 0.5 seconds. This judgment has a timing gap: the moment when the output volume is measured and the moment when the screen state is checked are slightly out of sync. When output arrived in that gap, the fact that it ended was correctly captured, but the record of "how it ended" sometimes differed from reality.

On my local Mac, all tests pass. I found this through GitHub CI (a system that automatically runs tests on multiple operating systems with each code update). The macOS runner on CI is very slow. The problematic test had a wait time of 0.6 seconds versus a stillness threshold of 0.5 seconds, leaving only 100ms of margin. On the slow runner, this slack wasn't enough, and the macOS job consistently failed. That's when I first learned about the bug.

Actual CI screen during v0.12.0 release. Linux and Windows all passed, macOS node 18 failed, and the other two macOS jobs were automatically aborted

The interesting part is that the audit came close. The AI responsible for catching oversights noticed the category of "time-dependent risky tests" and had actually pointed out another test. That test had a 5x margin, so it was judged "no problem," which was correct. The real one remained unpointed. When just reading the code, a test with a 1.2x margin and one with a 5x margin both look like "passing tests."

By the way, this CI was running even before the audit. I had decided from past failures to have automated tests on multiple OSes before touching the code, and I followed that this time too.

Bugs that only appeared when running

Apart from the desk audit, there were two bugs found the same day during "actual running verification."

When I fetched Grok's screen log in "read all" mode, 73,176 characters came back packed into 4 lines. Output from tools that redraw the screen typically has almost no line breaks. Aiterm's folding feature was designed to activate when "the number of lines exceeds 60," so these huge 4 lines passed through unfolded, exceeded Claude's per-message capacity, and the reading itself failed. On paper, the folding feature looks perfectly functional. The case where the length of a single line becomes problematic didn't come up from any of the 27 agents until I actually ran the real Grok.

The other was missing parts of long responses. When an AI's response is long, aiterm returns only the last screenful (about 24 lines). For a 40-line response, only lines 18 onward were captured, and there was no way to retrieve the first half. I solved this by creating a new feature to recover the full response from the AI's conversation history.

These two issues didn't surface from just reading the code. They only appeared when actually running it with real data flowing.

Who found what

The results line up as follows:

Who found what (AI audit / multi-OS CI / actual running verification)

This all got moving from a vague sentence because Fable 5 read the rules accumulated over several months. The "rough edges" I couldn't name materialized as 7 issues and disappeared in a day. The refutation step stopped 10 dangerous assumptions before implementation. And the most troublesome bug was found by the rules my past self had set: having CI in place first, and actually running to verify after fixing.

The bugs found did not overlap at all among these three methods. Hmm. I wonder what that means.

How Codex's Top-Tier Mode Burned Through a 5-Hour Quota in 1 Hour

Quo — Sat, 25 Jul 2026 10:10:19 +0000

While I was enjoying Fable 5, Claude hit its one-week quota limit. Just then GPT-5.6 came out, so this time I decided to use Sol from Codex. I chose the top-tier Ultra.

In one hour, five hours' worth of quota disappeared. This happened three times in a row.

At first, I thought I was overusing it. I was throwing heavy tasks at it in batches, and sometimes that's just how it goes. But the third time, it felt too fast. Using up five hours of quota in one hour is too fast, even for heavy tasks. I opened the logs to see what was eating it.

Looking at the logs, all the children were using the top model

Codex has a mechanism where a single task can be divided among child AI agents (sub-agents). When you throw a heavy task at it, Sol spawns several children and runs them in parallel. When I opened the logs, all those children were running on Sol's Ultra.

I have configuration files in ~/.codex/agents/ that assign models based on roles. For example, a child doing research uses a cheaper model, a child implementing uses a mid-range one, and so on. But when I looked at the logs, none of that configuration was taking effect. The command to spawn a child (spawn_agent) only accepts a task_name — there’s no field for role or model selection. So the role remained empty (agent_role was empty), and the model was simply inherited from the parent. Everyone was on Sol Ultra.

The parent Sol/Ultra spawns multiple children, and the children spawn more children. Since the model specification isn’t passed down, all subordinate children end up on the same Sol/Ultra

When you run a single top-tier model, multiple other top-tier models hang off it. If a child calls another child, the number multiplies. This was why five hours of quota disappeared in one hour. My carefully configured role-based assignments to keep costs down were completely bypassed, and everything was running at the highest price.

The model selection option was hidden

Why wasn't the configuration working? The spawn command simply had no field for specifying the model.

Codex's configuration has a setting called hide_spawn_agent_metadata. The default is to hide it (true). This "metadata" includes fields for selecting the model and the depth of thinking. So with the default settings, those fields were removed from the spawn command entirely. Without those fields, no matter how much I configured role-based models, they couldn't be passed on. Since they couldn't be passed, the children just inherited the parent's model. The higher-tier model you chose, the more your children all ran at the top tier.

I thought that choosing the top mode would let the smart model smartly delegate tasks. In reality, just silently selecting it meant even lightweight tasks continued running on the top-tier model.

The same reports were lined up on the same day

I wondered if this was just my environment, so I looked into it. From July 9th to 10th, on X, the same reports appeared in both Japanese and English. People said that leaving Sol Ultra alone caused them to hit the quota limit in three minutes. Five hours of quota disappeared in 20 minutes. They hit the five-hour limit twice in one day — something that had never happened before.

The diagnosis was consistent too. Someone wrote exactly what I saw in the logs: "spawn_agent only sends the task name. The child inherits the parent model with an empty role, ignoring the configuration file." An issue on GitHub also summarized it: with Sol, you can't specify a model for children, so all children end up on Sol. Some pointed out it was a bug introduced in version 0.144.1.

There was also a post describing how to fix it.

Enabling Model Selection for Children with Two Configuration Lines

A user named evi77ain posted two lines of configuration.

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

The first line restores the hidden model selection field. The second line is to avoid errors caused by conflicting names for the tool that spawns children. After adding these two lines to config.toml and restarting the session, the model field returned to the spawn command.

After it was restored, the role-based assignments I had placed in ~/.codex/agents/ started working as intended. When I actually specified a role and spawned a child, it ran on the cheaper model as configured. The situation changed from everything running on the top-tier model to only the necessary parts running on the top-tier model and the rest using cheaper models. The rate at which quota decreased also returned to normal.

Before: both parent and children are all Sol/Ultra, causing quota to drain rapidly. After: the parent is Sol, children are assigned to cheaper models by role (research uses a light model, implementation uses a mid-range one), and the drain slows down

Just Picking the Top Tier Wasn't Enough

I added two lines of configuration to allow selecting a cheaper model for children. For now, things have settled down. But honestly, OpenAI — don't you think this kind of hidden parameter is a bit off?

AI-to-AI Conversations: The Interactive Terminal Powered by aiterm-mcp

Quo — Sat, 25 Jul 2026 10:09:42 +0000

aiterm-mcp was created to eliminate the hassle of tinkering with a home server. Each time you send a command from Claude Code, the connection to the server drops, requiring re-authentication every time you reconnect. If you could hold a single persistent connection, that would no longer be necessary. That's what this tool is for.

The main use of this tool right now is when I have Claude run other AIs—such as Codex, Grok, or Composer. Claude reads what the other AI is doing and gives it the next instruction on the spot. Repeating this, they work together on a single task.

Claude launches Codex within a single terminal it holds, reads the screen, and sends the next command. This back-and-forth of reading and sending forms the conversation. Grok and Composer can also be launched in the same way.

How It Works

Suppose you ask Codex to rewrite old tests into a new format. Claude starts Codex inside the terminal it holds and gives it the initial instructions. Codex begins executing. Claude reads the screen to see how it's progressing. If Codex breaks something else along the way, Claude sends "fix that too" on the spot. It can interject while the other is still running.

codex_agent(session_name: "codex1", cwd: "/repo",
            prompt: "古いテストを新しい形式に書き直して")
   → Codex starts running in terminal "codex1"
pty_read("codex1")                  → Reads what it's currently doing
pty_send("codex1", "壊した読み込みも直して")
   → Sends the next instruction while it's still running

What it does is simple: read the other AI's screen and type in the next move. This is repeated several times. The screen output is trimmed to only what's needed, to prevent Claude from getting overwhelmed by long outputs. It's the same as when a person asks someone to do a task and gives feedback from the side: "Do it this way here." Claude does exactly that.

All in the Same Single Terminal

The core of aiterm-mcp is just one terminal that Claude keeps persistently. Whether connecting to a server or launching another AI in this conversation, everything happens within that single terminal.

For Claude, logging into a server, entering a container (an application enclosed in a box), or launching another AI all amount to "sending text to the same single terminal." No matter what you connect to, the handling is the same: open the terminal, send text, read the response. A handful of tools cover everything.

Don't Pretend to Have Launched

Before launching another AI, there are checks to perform: whether the specified working directory actually exists, whether the launch parameters are correct, and whether the required tools are installed on that machine. If any one of these is missing, the process stops and clearly reports the issue.

Skipping this step leads to trouble. For instance, if the working directory is specified incorrectly, the terminal silently proceeds, moving forward as if everything "launched successfully." Even though nothing is actually running, it acts as if it were. So we verify before launching, and don't proceed unless all conditions are met.

This verification foundation was also independently reviewed by external AIs to ensure correctness. I didn't just decide my own tool was correct on my own.

No Need for a Person to Sit Attached

Because this conversation is driven from Claude's side, it can proceed without a person sitting in front of the terminal. Whether in a scheduled automation setup or during pre-delivery automated checks (CI), you can launch and run other AIs in the same way.

You can distribute a single task among multiple AIs while you keep an eye on the overall picture. This workflow can be achieved without a person manually switching between terminals one by one.

Positioning of aiterm-mcp

Recently, there has been an increasing trend of a lead AI having another AI assist it. The lead AI lets one AI handle mechanical rewrites and another run batch edits, while it reviews the results. The assisting AIs all run within a terminal. aiterm-mcp is a tool that gives Claude direct control over that terminal, turning assistance into a conversation through the terminal.

This is what I do with this tool every day: I have Claude converse with Codex, Grok, and Composer, and we all work together.

How I Consolidated Bug Reports from Four Apps and Let AI Fix Them in Parallel

Quo — Sat, 25 Jul 2026 10:09:00 +0000

With four user-facing apps, I centralized all bug reports into one place. Only after aggregating them did I realize that the severity ratings were based on different criteria across the four apps. By standardizing the criteria and laying them out on a single screen, I was able to hand them over to multiple Claude instances and have bugs already reported get squashed in a single day. This article explains how operational overhead concentrates here when you run multiple commercial apps.

I currently have four apps with users: LiveTR, which provides real-time voice translation; OLTranslator, which translates screens into Japanese on the fly; Kikoeru, an English listening tool; and AuctionBOT, a Discord bot running on my own server that manages guild auctions. The more apps you have, the more you worry about "is everything working correctly" rather than developing new features—because real users are using them.

Overview: BugHub polls each app's admin read API every ~3 minutes, deduplicates by signature, and displays them on a dashboard and /ai endpoint under the same criteria

Apps I can observe vs. apps I cannot

Of the four apps, I can only track the behavior of one myself. AuctionBOT is a Discord bot running on my own server, so I can investigate what's happening to some extent. The other three (OLTranslator, LiveTR, and Kikoeru) run on users' devices and environments. I don't have the same environment at hand, and some bugs cannot be reproduced in a single environment.

So I added that familiar prompt to all apps: "Send information to improve quality." When I was a user, I'd just click OK without thinking. Now on the developer side, I see how valuable it is. Most bugs aren't something you find yourself; they come up from users' environments. For what I can't observe on my own, I rely on user reports.

Reports scattered across different places per app

I added a reporting mechanism to all apps, but then reports piled up in different locations for each app. When I'm running four apps by myself plus AI, I couldn't see how many issues each app had side by side. There was no place to check which app was having problems before fixing them.

So I built an aggregation system. It's a read-only internal container running on my home server, named BugHub. It does one simple thing: it polls each app's admin read API exposed within the LAN every ~3 minutes and lays everything out on a single dashboard. All the app needs to do is expose one "LAN-internal, Bearer-authenticated read API." Bugs are returned grouped by fingerprint. The fingerprint is a hash of "which module, which type, and what message template"—it doesn't include variable values, so bugs with the same root cause get the same hash. Each bug comes with severity, a message template (variable values and personal information masked), cumulative occurrence count, last occurrence time, and status (unresolved or resolved).

On BugHub's side, if the data matches this format (called the signature format), ingestion is just one line.

// Apps that output this format just need to add one line to the source list
const SOURCES = [
  { name: "AuctionBOT",   api: AUCTION_API   },
  { name: "OLTranslator", api: OLTR_API      },
  { name: "LiveTR",       api: LIVETR_API    },
  // Only Kikoeru had a different log format, so I inserted a small adapter
  { name: "Kikoeru",      api: KIKOERU_API, adapt: kikoeruAdapter },
];

LiveTR, OLTranslator, and AuctionBOT were aligned to the same format from the start. Only Kikoeru had a different logging style, so I inserted one small conversion adapter. That put all four side by side.

Different criteria became visible side by side

What I noticed after laying them out was that the severity of each report was based on different criteria per app. What one app calls "critical" might be equivalent to "warning" in another. Only when they are arranged under the same criteria does a list appear where you can tackle them from the top.

So I unified the severity labels into four levels. The app assigns them, and BugHub uses them as-is without re-evaluation.

Label	Meaning
fatal	The app stops working or doesn't function. Most severe.
high	The app runs but causes actual harm to users (malfunctions, data loss, etc.). One step below fatal.
warn	Not ideal but still working. Should be fixed.
info	Needs fixing but no solution available now, or reference info just for recording.

The definition is just four lines, but the implementation affects each app's reporting mechanism itself. I had to review which events were assigned to which level across all four apps. As a result, each app underwent a revision that both fixed bugs and rebuilt the reporting mechanism.

How to pass common specifications to AI

Once the labels were unified, the next question was how to pass these common specifications to the party doing the fixing. The one fixing isn't me; it's AI. Different VS Code instances and different Claude instances are set up for each project, so explaining the specifications verbally each time would defeat the purpose of unifying.

So I made this into a single page. Calling GET /ai returns a single Markdown document written for AI consumption. Its pillars are as follows:

The four-level severity criteria (the ones above)
Fix procedure: ① Get unresolved items → ② Fix the relevant app's project → ③ Deploy to production and confirm it doesn't recur → ④ If confirmed, record the resolution on the app side. Don't record the resolution first. Don't touch anything you're not confident about.
A list of unresolved items at that point (with a resolution command for each item)

In addition, the same page includes a table of "where to record the resolution" for each app and common specifications for "how to integrate a new app."

I wrote before about the mechanism for letting AI fix and deploy. What I added this time is the part that aggregates reports from multiple apps under the same criteria and makes them available via a single URL. If I tell AI to "make this app aggregatable to BugHub," the AI implements the app's API according to the common specifications on this page. Integrating a new app also requires only passing the same single URL.

Resolutions are recorded on the app side, not in BugHub. The app side is the source of truth; BugHub just copies and displays that state. Even if you delete something in BugHub, it will be overwritten by the app's state on the next poll, and if the app detects a recurrence, it will automatically revert to "unresolved."

Same /ai URL passed to multiple VS Code/Claude instances, each fetching their assigned app, fixing, deploying, verifying, and recording the resolution. Resolutions are recorded on the app side.

Handing it over to multiple Claude instances and getting it done in a day

Once everything was in place, I started clearing out the reported bugs. I set up Claude in multiple VS Code instances, passed the /ai URL to all of them, and instructed: "Look at this and fix it." Since they all see the same list under the same criteria, each Claude picks up unresolved items, fixes its assigned app, deploys, verifies, and records the resolution. I ran this in parallel, and it was largely cleared up in that one day.

There is no LLM inside the polling container. The ~3-minute polls and the instant alerts for surges or new issues all run on pure threshold rules. AI is involved only on the outside—on the bug-fixing side and the weekly Codex summary.

Where the most effort goes now

When you personally run multiple commercial apps, the operational overhead concentrates here. The time spent handling incoming reports grows larger than the time for adding new features. I wrote before about the speed of building, and as a follow-up, the same kind of organization is needed on the maintenance side. That's where things stand now.

Now, unresolved items for all four apps are lined up on a single screen under the same criteria, and by passing a single URL, AI can go and fix them from there. That prompt "Send information to improve quality" that I absentmindedly clicked OK to as a user—this is how it gets used on the developer side.

How I Made an AI That Can't Draw the Same Character Create Anime Model Sheets

Quo — Sat, 25 Jul 2026 10:08:25 +0000

I have all the characters in my RPG (rpgdev) drawn by AI. The dot-pixel hero, the spirits of fire, water, wind, and earth, the enemy monsters. I've generated each one, made them transparent, and put them into the game.

But there's been a persistent problem: AI is bad at drawing the same character consistently.

Suppose you get a good character image. You ask for "the same character, but facing sideways" or "a damaged version." Then — it's not like it becomes a different person, but the hairstyle changes a bit. The colors shift. Equipment appears or disappears. The line thickness varies. Each image looks fine on its own, but when lined up, they don't look like "the same character."

I couldn't trust the approach of editing a single image to create variations, in terms of consistency.

By the way, in a previous article How I turned my terminal into an RPG, I wrote that I struggled with creating these dot-pixel variants and ended up ordering a 32GB GPU to "fight back." This article is also a record of that rematch.

The overall two-stage approach: stop endlessly fixing single images, first create a reference sheet to serve as a standard

How do anime and manga studios keep characters consistent?

I thought about it. How do professional animators and manga artists keep the same character consistent across every cut and every episode?

I know the answer: Character reference sheets (model sheets). Front, three-quarter, side, and back turnaround views, expression patterns, several poses. A single sheet that serves as a standard for "this is how to draw this character." Everyone on the team draws while looking at this sheet. That's why they can maintain the same character across hundreds of cuts.

So, we should make AI do the same thing. Instead of endlessly fixing single images, first create one reference sheet, and then use it as the standard for all subsequent generations. The idea itself is simple.

The problem was: how to make AI create that reference sheet itself.

The key is in how you create the reference sheet

If you do it straightforwardly, it goes like this: "Draw a front view," "Next, a side view," "Next, a back view," "Next, a smiling face" — generating each cut one by one separately.

But this leads to the same problem as before. The character drifts between cuts. They become different people within the reference sheet. The sheet meant to be the standard fails to be a standard. It's putting the cart before the horse.

So I came up with a two-stage approach.

Stage one: Have all angles, expressions, and poses drawn together in a single generation. Don't request them separately. Ask for "a reference sheet with turnarounds, expressions, and poses all in one image" in a single prompt. Because they are drawn simultaneously as one picture, they are consistent with each other within it. The front and back views have the same hairstyle and same outfit. This becomes the "anchor for consistency."

The master sheet drawn all at once

However, cramming everything into one image makes each cut small and rough. The resolution isn't enough for game use.

So, stage two: Now pass that "group drawing" sheet back to AI as a reference. Then have it redraw each cut individually at high resolution. Ask: "Keep the character exactly as shown in this reference, but draw only this one cut larger."

With a reference, consistency is maintained. By drawing each cut individually, resolution is achieved. Consistency from the reference sheet, resolution from individual generation — both benefits. I designed and instructed this two-stage approach myself.

Here's the result. At the top is the master sheet; below it are high-resolution redraws of turnarounds, expressions, actions, alternate outfits, chibi versions, equipment, and even an extracted color palette. All the same character.

The character bible with each cut redrawn from the master sheet

The water spirit. Expressions, running, jumping, knight armor, dress — all lined up as the same person.

Bonus: The reference sheet becomes fuel for mass production

The high-resolution cuts created in stage two have another use.

They become training data dedicated to that character. You have a dozen or more images of the same character from various angles and expressions. If you train an AI on these to create a small additional model that "remembers" this character, you can mass-produce new poses that weren't in the reference sheet, while keeping the character consistent.

The process of creating the reference sheet also doubles as fuel for the next mass production. That was intentional.

Turning pain points into "checkpoints"

That's the core. Now a little about the tool's internals.

While creating assets for rpgdev, I've stepped on countless small pain points. I've baked each one into the tool as an "absolute rule" (checkpoint).

The output is a transparent game sprite. If the corners aren't properly transparent, it gets rejected before shipping.

Pain points I encountered	Absolute rules (checkpoints) baked in
Black residue in transparency - "Closed black" areas like gaps between arms and ribbons remain after simple background removal. One accepted image had over 200,000 black pixels left.	Reject before shipping if the four corners aren't properly transparent.
Misalignment in damage versions - Each regeneration shifts by a few pixels, causing misalignment with the base in-game.	Reject if not within 1px of the base.
Art style drift - Omitting essential terms for retro pixel art causes a smooth slide into glossy anime style.	Automatically inject those terms.
Manual fixes don't work - Hand-drawing fabric, skin, or outlines to fix issues had a zero percent success rate.	Don't include manual editing functions. To fix, regenerate.

Broken assets don't silently slip into the game. They get stopped at the checkpoint.

And whether the input comes from a human-operated UI (WebUI) or an AI (Claude or Codex) calling the MCP endpoint, the same processing pipeline is used. So whichever face enters, these checkpoints cannot be bypassed.

With 32GB, it finally worked

In #30, I wrote that my custom diff tool couldn't run on my 16GB GPU, so I ordered a 32GB one to "fight back."

The editing model this tool uses gobbles up over 20GB of VRAM. It simply didn't fit in 16GB — literally zero images were output. After upgrading to 32GB, it finally worked. If you don't have enough VRAM, that's the end of it.

On top of that, the architecture is designed as follows: the heavy generation is entirely handled by that single machine with 32GB (the ComfyUI GPU machine). The main tool is a thin orchestrator that commands "what to create and in what order" and performs the checkpoint checks mentioned earlier. As long as you have one machine set up for generation, the orchestrator can connect from a Mac or WSL.

It's a tool that requires a CUDA GPU and the full ComfyUI setup — it has requirements. But the two-stage concept itself is tool-agnostic. If you're struggling with inconsistent characters, you can take just that idea and it will work.

Conclusion

sprite-forge. Create transparent game-ready characters from text. Give it an idea, and it produces a base body, assembles a reference sheet, and even prepares training data for that character. Whether from a human or an AI agent, the same checkpoints are passed and the same output comes out.

The repository is at github.com/kitepon-rgb/sprite-forge-mcp. MIT license.

I stopped endlessly fixing single images and started creating from a reference sheet. At last, the same character now lines up as the same character.

Only Complete Sentences Should Be Translated — But a Single Counter Betrayed That Design

Quo — Sat, 25 Jul 2026 10:07:53 +0000

When watching English videos with LiveTR, the subtitle translations would occasionally get jumbled.

Lines from different people would merge into a single sentence. The first utterance after silence would be translated missing its beginning. Occasionally, nonsensical Japanese would appear.

A dim desk, a mood shot of English video subtitle overlays being converted to Japanese in real-time

You Need Complete Sentences to Translate

If you feed incomplete sentences to a translator, you get incomplete translations. It's obvious.

What comes into play here is how the audio is captured. To process in real-time, LiveTR mechanically splits the incoming audio every five seconds and feeds it to speech recognition. This five-second segmentation naturally ignores where people actually stop speaking. It ruthlessly cuts off sentences right in the middle.

So the English sentences coming out of speech recognition are frequently cut off. Fragments like "I think that we should…" are severed by the five-second wall. If you throw these directly into translation, you'll only get choppy translations back.

So LiveTR doesn't pass these fragments directly to translation. Instead, it holds onto them, and if the continuation comes in the next five seconds, it concatenates them to form a complete sentence before translating. Only complete sentences are sent for translation—this is the core of translation accuracy, and I wrote about its importance in the previous article introducing LiveTR.

The problem is when the continuation never comes. The conversation might pause or change topics, and the held fragment may never get its continuation. In that case, the system decides "waiting longer is futile" and sends the fragment as a sentence on its own. That cutoff mechanism was properly implemented.

That Cutoff Was Pointing in the Wrong Direction

The subtitle confusion happened because this cutoff wasn't working.

A single counter that measures waiting time—the one that decides "send without waiting anymore"—was wired backwards. It triggered when there was no need to wait, and failed to trigger when it should have cut off. So the held fragment remained in limbo, and when someone else started speaking in the next five seconds, it attached to the beginning of their speech.

For example, a five-second segment ends in the middle of "we really need to". Then the conversation flows in a different direction, and in the next five seconds someone says "Yeah anyway the budget is fine.". Normally the previous fragment would be sent alone, but instead it gets attached to form "we really need to anyway the budget is fine."—a sentence no one actually spoke. Because this is faithfully translated, the subtitle becomes something like "We really need to anyway, the budget is fine."—a line mixing two speakers' dialogue.

When the cutoff counter is reversed (top), the previous fragment attaches to the next speaker; with the correct direction (bottom), they are finalized as separate utterances

What I fixed was just this one thing: the direction of the cutoff. The design was correct.

The Translation Engine Was Excellent from the Beginning

LiveTR sends translations to cloud engines (DeepL / Google / Azure / Amazon, selectable in settings). They faithfully translate whatever English text they receive. If you feed them patchwork, they translate patchwork. They have no way of knowing that the English they receive is a collage of two people's lines.

Once I fixed the cutoff direction, complete sentences started reaching the engine. When I played English audio on the actual device, the translation was completely different. I hadn't touched a single line of the translation engine.

Feed it complete sentences, and the same engine returns a good translation. It was that simple.

Download

LiveTR is available for purchase on BOOTH. It can real-time Japanese-ify English videos and streams on Windows + NVIDIA GPU environments. It comes with subtitle overlays and Japanese text-to-speech that reflects the speaker's voice quality.

LiveTR — An App That Converts English Audio from Videos into Japanese in Real Time — Introduction to the app itself. Overview of speech recognition, translation, subtitles, and text-to-speech.

This blog, "Getting Started with Claude Code", is a site where Claude MAX users record what they learn while using it in actual development.