DEV Community: QuoLu

How I Fixed the Infinite Feedback Loop When Auditing Project Plans with Claude

QuoLu — Wed, 10 Jun 2026 01:00:24 +0000

I always enjoy AI programming.

My usual workflow is to create a plan, have it audited, and then proceed with the implementation.

However, I felt that the auditing process hasn't been working well, especially since Opus 4.7. Perhaps it's because Opus has gained a broader perspective? It often brings up points that are irrelevant to my plan, and when I have it perform an automated loop of auditing and revising, the feedback often fails to converge.

Whac-A-Mole

Then one day, I realized it.

When writing a program with slightly complex logic, the AI keeps saying "this is wrong" or "that is wrong" every single time. It feels like an indirect loop, or more accurately, constant Whac-A-Mole.

It says, "B is weak from the perspective of A," so I fix B. In the next audit, it says, "B is excessive, and A is thin." When I add A, it then says, "C is inconsistent." When I fix C, it says, "The description of C is redundant." Once I fix that, it says, "C is insufficiently explained."

It's a seesaw. There is no exit in sight.

What I tried

Realizing this, I tried the following approach.

For a plan that was reasonably complete (having gone through 1 or 2 audits), I asked the AI, "Please audit the plan only for logical contradictions."

This worked perfectly. It diligently resolved the contradictions, and after a few rounds of auditing, it converged properly.

Since the number of contradictions is finite, it actually converges.

And when I let it start the implementation with a plan free of contradictions, it runs straight to the end without stopping (lol).

Of course, there are occasional implementation errors where it has to retry, but that's expected.

I wondered if this exists in the world

Having reached this point, I suddenly became curious. Surely, I'm not the first person to figure this out. Someone else must have thought of the same thing.

I looked it up.

There were similar concepts, but they felt different. To put it simply, they were complicated.

Criteria Drift (Explanation by Hamel Husain, Shankar et al.): A phenomenon where evaluation criteria gradually shift when using an LLM for review. The countermeasure is "rescoring past scores while refining the evaluation axes." ...That's heavy.
Oscillatory Convergence (Fractal Thought Engine): An observation that there is a certain number of sessions where the approach oscillates due to iterative feedback from the LLM. It's observed, but it's not about countermeasures.
Moving the Goalposts (Microsoft Blog): The idea of not moving the rubric during evaluation and finalizing the rubric before starting the evaluation.

There are related topics. But what I did wasn't "finalizing the rubric"; it was "narrowing the evaluation axis to a single point: contradictions." As long as the scope is broad, points of criticism will spring up infinitely, so I'm trying to contain the scope to a finite set. I couldn't find existing research that clearly stated this.

I suspect it's written somewhere. It should be, but it's probably written in academic terms, and by the time I realized it, two months had already passed.

Simple once you're told

When I write it down, it sounds simple. "If you narrow the scope, it will converge." That's all there is to it.

But it took me two months to notice.

I kept trying to change how I wrote my prompts, thinking, "If I use Claude more intelligently, it will get better." Even when I wrote, "Don't give too many points" or "Be consistent with past feedback," it didn't work. Because the problem wasn't how I was writing the prompts.

It took time for the idea of narrowing the scope to "only finite items" to occur to me. When you audit normally, the scope is wide, so no matter what you fix, holes are found from a different angle. That was the whole story.

Conclusion

When the audit of a plan doesn't converge, narrow the scope to "only contradictions."
Contradictions are finite, so the process will converge.
If you audit with a wide scope, criticism will spring up infinitely, leading to Whac-A-Mole.
When you have the AI implement a plan that is free of contradictions, it will run until completion without stopping.

If there is anyone else caught in the same Whac-A-Mole trap, then writing this was worth it.

I feel good on days when I do something good.

Stop Telling Claude to 'Be Careful': Reinforcing It from the Outside with 3 Tools

QuoLu — Tue, 09 Jun 2026 00:54:11 +0000

Over the past month or so, I have released three reinforcement tools for Claude Code on npm.

Throughline — Offloads bloated context.
Caveat — Surfaces past notes so you don't step into the same trap twice.
Spotter — A separate Claude audits missed tool calls.

Each solves a different problem, but the root cause is the same: all the problems that could be fixed by telling Claude to "be careful" had already been fixed. What remained were issues that could not be fixed structurally.

The period of constant "be careful" warnings

In the beginning, I also wrote plenty of "be careful" instructions in CLAUDE.md and my prompts.

"Do not guess files, always read them before answering."

"If the context becomes bloated, run /compact."

"Read the traps I've fallen into in the past, which are written in CLAUDE.md."

But the more I wrote, the more bloated CLAUDE.md became. A bloated CLAUDE.md just gets skimmed by Claude. Even though it's written there, it isn't followed.

I thought maybe my writing style was poor, so I changed the phrasing. Still, it didn't work. I realized there is a certain number of problems that simply don't go away no matter how many times you change the way you phrase them.

Problems that can be fixed vs. problems that cannot

One day, I drew a line in the sand.

Problems that can be fixed by writing "be careful" and those that cannot are fundamentally different types of issues.

Problems that can be fixed by writing instructions occur because Claude simply "forgot." If it sees the instructions, it remembers. This can be handled by improving the prompts.

Problems that cannot be fixed occur because Claude cannot recognize its own limitations.

It cannot notice that the context is bloated (it's decided at the moment the request is sent, so it can't see its own size).
It doesn't remember traps encountered in past sessions (sessions are independent, and adding to CLAUDE.md makes it heavy).
It doesn't notice when it forgets to call a tool (it doesn't know what it doesn't know, so it can't go get it).

Asking Claude to "be careful" about these things doesn't work. It's because these are problems Claude itself cannot fix.

Giving up and reinforcing from the outside

So, I stopped asking Claude and started intervening from the outside.

Claude Code has a hook mechanism. You can insert hooks before sending prompts, after a tool runs, or when a session ends. Even if Claude itself doesn't notice, you can observe the state from the outside and inject the necessary processing.

Since realizing this, I have created three reinforcement tools.

Throughline (Subtraction)

To address the issue of context bloating, it offloads tool inputs and outputs to SQLite and removes them from the context.

The contents of read files, grep results, and Bash outputs—once the AI has used them to make a decision and moved on, their purpose is fulfilled. Yet, they remain until the end, consuming tokens. I use hooks to offload these to SQLite. If Claude needs them, it can retrieve them itself.

I have completely removed the burden of "noticing the bloating" from Claude.

Caveat (Accumulation)

To address the issue of falling into the same trap twice, it automatically surfaces trap notes written in the past during similar situations.

When I fall into a trap, I write it down in Markdown. The next time I send a similar prompt, receive a similar tool error, or when a "struggle signal" is observed at the end of a session, the relevant past notes are injected into Claude's context via hooks.

I have removed the burden of "remembering past traps" from Claude.

Spotter (Addition)

To address the issue of forgetting to call tools, I run another Claude side-by-side that has a perfect grasp of the tool catalog and points it out if a call is forgotten.

The main Claude works as usual. Another Claude (Haiku 4.5) resides alongside it, watching the user's input and final response. If it notices, "You could have answered this by using web_search," it sends a pointer to the main Claude via a hook.

I have removed the impossible burden of "realizing what you forgot to call" from Claude.

Common patterns

What these three have in common is a design that expects nothing from Claude itself.

	Throughline	Caveat	Spotter
What is not asked of Claude	Context management	Past memories	Detection of missed steps
Who does it instead	hook & SQLite	hook & past notes	hook & separate Claude
Changes needed for Claude	None	None	None

The fact that "changes needed for Claude" is zero is important. You can just write what you want to write in prompts and CLAUDE.md as usual. You don't increase the number of "be careful" warnings.

Structural problems not yet reinforced

It's not that I'm satisfied because I made three. There are still structural problems I want to fix.

Long-term role drift: The problem where Claude's persona drifts during long sessions. Even if I write "You are a strict reviewer" in the prompt, it becomes soft after 20 turns.
Context loss through sub-agents: Sub-agents spawned by the Task tool do not have the implicit context of the parent session. It is quietly painful to pass the same explanation to the child every time.
Tool selection accuracy: The judgment of "which tool to use" among multiple options is sometimes sloppy. Spotter detects missed calls, but it doesn't detect wrong tool selection.

Conclusion

I have already fixed all the problems that can be solved by telling Claude to "be careful." The remaining problems are of a type that Claude itself cannot fix.

That's why I reinforce from the outside. Just insert it with hooks. Claude itself doesn't need to know anything.

Having created three of these in a month, I feel I've seen the pattern for reinforcement. All three are on npm under MIT, so if you are troubled by the same structural problems, please take a look if you feel like it.

I Had 74 Daemons Running Because I Made One Claude Audit Another for Missed Tool Calls

QuoLu — Mon, 08 Jun 2026 01:01:14 +0000

The Trigger

One day, when I asked Claude, "What time is it now?" it gave me an answer based on its best guess.

On another day, when I asked about the contents of a configuration file, it provided an explanation based on its own guess from the file name. It had a read_file tool available, but it didn't use it.

At first, I thought, "Maybe Claude is just tired," but it happened too frequently. Even if I wrote "Use the tools" in the prompt, it would sometimes forget.

That's when I realized: Claude cannot self-recognize when it doesn't know something. Therefore, it doesn't know it needs to go get a tool.

Even if I ask it to "be careful about forgetting to call tools," it doesn't know it "doesn't understand," so there is no way for it to be careful. It was a structural problem.

What I Tried

So, why not just add another set of eyes?

Apart from the main Claude, I decided to keep an auditor Claude (Haiku 4.5), which has complete mastery of the tool catalog, resident in every session. It watches the main Claude's planned utterances and final responses in parallel, and points out if a tool call was forgotten.

Situation	Main Claude's response	Auditor's feedback
"What's the weather today?"	Responds with a guess	You can use `web_search`
"What's inside this config?"	Guesses from the name	You can use `read_file`
"What time is it now?"	Time at training	You can use `current_time`

The point is not to rely on the main Claude's own self-awareness. Instead of writing "please be careful" to Claude, I physically placed another set of eyes there. The judgment happens in two stages: at the moment the user inputs something (listing tools that should be used for the request) and immediately after the main Claude returns a response (determining if a verification tool can be inserted for factual claims).

I built this and named it claude-spotter.

A Mistake Immediately After Release

I thought it was a convenient design. npm install -g claude-spotter would automatically enable it for all projects with no configuration required. It felt perfect.

I released it and started using it myself.

64 minutes later, 74 daemons were running.

What Happened?

When I dug into the real session logs, 51 out of the 74 were caused by Throughline (another tool of mine).

Throughline calls claude -p internally. Calling claude -p triggers the SessionStart hook. The SessionStart hook starts the Spotter daemon. The Spotter daemon calls claude -p for auditing. It wasn't quite infinite recursion, but a recursive proliferation.

Because I was writing to ~/.claude/settings.json via postinstall, every Claude Code session on the system was structured to load the Spotter hook. This was the price of "automatic activation for all projects."

I added a 5-layer defense to stop the recursion on my end, but it was defenseless against claude -p originating from other tools. This was a structural issue that couldn't be covered up by patches.

Retraction

I retracted the automatic registration in postinstall. I changed it so npm install only makes the CLI available, and users must explicitly run spotter install in each project. This writes the hook to <project>/.claude/settings.json.

I thought "automatic for all projects" was convenient, but the side effects were far greater. Ideally, automation is the goal, and having users run spotter install in each project is a compromise. If the Claude Code hook mechanism could "identify the session origin," it would be safe to make it automatic, and I'd like to revert to that when it happens.

The Next Bug: Tools from Past Projects Remain as Ghosts

After using it for a while, a different symptom appeared.

When I opened a session in Project A, the auditor suggested, "You can use the mermaid_diagram tool." However, the mermaid MCP is not registered in this project.

I investigated and found that the MCP tool definitions I had used previously in Project B remained in the global DB and were being referenced in Project A. A regression where it "suggests tools that cannot be used."

I changed the tool catalog used by the auditor to be local-DB only (v1.2.0). The global DB was demoted to "a cache that reuses only the description if it has been acquired in other projects." Now, discovery runs in each project every time, and tools that are not found are deleted (pruned) from the local DB.

MCPs Distributed as .cmd Fail to Spawn on Windows

I hit one more thing. On Windows, when I spawn('claude-mermaid') an npm-global .cmd distributed MCP, it fails immediately with ENOENT.

Node.js's spawn calls CreateProcess directly on Windows, but CreateProcess only resolves .exe files (it does not resolve the .cmd extension in PATHEXT). I had previously encountered the same pattern—where wrapping it in cmd.exe /c makes it work—in the Spotter itself when launching the claude CLI and had fixed it, but I had forgotten to apply this pattern to the MCP server launch path (fixed in v1.2.2).

I stepped into a trap I had set myself, just via a different path. Having experienced this, I strongly felt the necessity for Caveat. If there isn't a mechanism to avoid stepping into the same trap twice, this is what happens.

Current Status

v1.2.4. The CI for Windows, macOS, and Linux is all green.

npm install -g claude-spotter
cd your-project
spotter install

The tool catalog is automatically collected during spotter install, and the SessionStart hook refreshes it in the background every time Claude Code is started. There is no need to manage it manually.

spotter status      # List of running auditors
spotter db list     # Tool catalog for this project
spotter doctor      # Environment diagnostics
spotter uninstall   # Remove hook registration

Areas Still Lacking

The Stop hook's correction results in two consecutive responses. Because of the specification where the hook runs after the main Claude returns a response, when it issues a correction response, the user sees "the initial response + the correction response" one after another. It would be ideal if we could preempt it during input (UserPromptSubmit), and use the post-response hook as insurance.
User input is blocked by Haiku's timeout. I am currently considering whether to fail-open (bypass and let it through).

Relationship with Throughline / Caveat

Spotter is a separate product that shares a philosophy with Throughline and Caveat, created by the same author.

	Throughline	Caveat	Spotter
Philosophy	Subtraction	Accumulation	Addition
Target	Context bloat	Stepping into the same trap twice	Tool omission
Mechanism	Evacuate memory via hooks	Surface past notes via hooks	Run auditor in parallel via hooks

What the three have in common is a "mechanism that does not rely on the main Claude engine." All three can coexist.

Requirements

Node.js 22.5+
Claude Code 2.0+
Claude Max Plan (to launch Haiku 4.5 with claude -p)

Spotter — GitHub

MIT License. If you are struggling with the same problem, please feel free to take a look if you're interested.

Published Caveat to npm: A Long-term Memory Layer to Avoid Repeating the Same Traps

QuoLu — Sun, 07 Jun 2026 01:01:30 +0000

I have published Caveat, a long-term memory layer for Claude Code, to npm.

What it does

When using Claude Code, you often spend more time deciphering "other people's specifications" than doing the actual implementation. You get stuck on GPU driver version constraints, failed native module builds, IDE quirks, or path issues that only occur on specific OSs. Even after you struggle and solve it once, you end up stepping into the same trap in a different project six months later. When you ask the AI, it doesn't say "I don't know" but instead acts on assumptions, causing you to waste time all over again.

Caveat is a layer where "once you jot it down, relevant notes automatically surface the moment you encounter the same situation next time." Even if you can't remember it, and even if the AI doesn't know it, the relevance is detected structurally.

Three Trigger Points

Caveat is implemented at three points using hooks.

Trigger Point	When it runs	What it does
Prompt Submission	The moment a prompt is sent	Breaks down the prompt and surfaces only entries where two or more words co-occur with past notes
Tool Error	The moment a Claude tool call fails	Runs a background search and notifies the next turn as a known trap
Session Termination	When a session closes	Extracts "struggle signals" from conversation logs. Prompts the AI if there is anything that should be recorded as a new trap

"Struggle signals" are traces where the AI might not be aware of it, but objectively it was struggling—such as tool failures, editing the same file repeatedly, repeated web searches, or re-executing Bash commands. It scans these at the end and prompts you, "You were stuck here in today's session, right? Do you want to record it as a trap?"

Design without Keyword Lists

The search logic relies solely on Co-occurrence FTS. There is no keyword correspondence table like "if the word 'rtx' comes up, display GPU-related notes."

Instead, it breaks down the input prompt and only surfaces entries where two or more words appear in the same entry simultaneously. Generic words like make or new do not trigger on their own, but when two or more technical words overlap, they match.

Even when new trap categories are added, you just add one entries/<slug>.md. You don't need to touch the code or keyword tables. The trigger expands itself.

Knowledge is markdown-in-git

The data consists of standard markdown files. SQLite is used as a derived index for searching, which can be rebuilt if deleted.

~/.caveat/own/
├── entries/
│   ├── rtx-5090-cuda-12-init-fail.md
│   ├── windows-node-spawn-cmd-enoent.md
│   └── ...
└── .git/

You can open it directly as an Obsidian vault. If you want to share it with your team, you can simply git push. There is no central server.

Public / Private Layers

Entries have a visibility attribute.

Public: Traps anyone can encounter if they use the same external tools or specifications (GPU, build environments, IDEs, version constraints)
Private: Project-specific context that cannot be reconstructed just by reading the code (intentional non-standard behavior, workarounds awaiting upstream fixes, custom habits)

Claude automatically determines the visibility. When in doubt, it defaults to private (to prevent leakage). If you explicitly instruct, "This should be private," that takes priority.

There is also a pre-commit hook mechanism that prevents private entries from being mixed into the shared repository.

Installation

npm install -g caveat-cli
caveat init

caveat init does the following in one go:

Initializes ~/.caveat/
Registers the MCP server with Claude Code
Adds three hooks to ~/.claude/settings.json

It does not break existing hook settings (it creates a backup before merging).

caveat search "rtx"        # Search existing notes
caveat serve               # Start a read-only portal
caveat uninstall           # Remove Claude integration only (data is kept)

No Central DB

Earlier versions had a shared database, with the concept of using caveat push to cultivate knowledge collectively. This has been abandoned.

I concluded that automatically verifying contributions from complete strangers is impossible in principle. Even if you use an LLM as a gatekeeper, it can be bypassed, and long-term latent attacks cannot be found through static analysis. Therefore, trust is built not through "automated inspection" but through "social context." I shifted to a model where you decide the scope of trust by choosing whose repositories to subscribe to.

caveat community add https://github.com/acme-corp/caveats
caveat pull

I will write about the detailed background in another article.

Requirements

Node.js 22.5+
Claude Code (with hooks support)
pnpm (development only)

Status

v0.11.1, 203 tests passing. Assumes individual and small team use cases.

Caveat — GitHub

MIT License. Bug reports and PRs are welcome.

Published Throughline to npm: A hook to offload Claude Code tool I/O to SQLite

QuoLu — Sat, 06 Jun 2026 00:54:54 +0000

I have published a hook plugin for Claude Code called Throughline to npm.

What it does

In a Claude Code session, the majority of the context is filled with the remnants of "tool I/O." The contents of read files, grep results, and Bash output—data that served its purpose the moment the AI read it, made a decision, and moved on. However, it stays in the context until the end, consuming tokens.

Throughline manages the conversation in three layers.

Layer	Content	Context Injection
L2	Conversation body (user input + AI response)	Last 20 turns injected as is
L1	Summarized version of L2 (1/5th size) while retaining key points	Injected for turns older than 20
L3	Tool I/O, system messages, and thinking	Not injected; offloaded to SQLite, retrieved by Claude as needed

Since tool I/O is completely removed from the context, read grep results and Bash outputs do not linger until the end of the session. Older conversations are compressed to 1/5th of their original size while keeping key points, so you can still follow the context of decisions made dozens of turns ago.

In a 50-turn session on my machine, a conversation that consumed 125,000 tokens was reduced to within 13,000 tokens.

Installation

npm install -g throughline
throughline install

install registers the hook in ~/.claude/settings.json. It runs automatically for all Claude Code projects on your PC. No configuration is required for individual projects.

Carrying over between sessions

Throughline offloads conversations to SQLite, so the data remains even after running /clear. If you want to carry over your memory to the next session, type /tl in the previous session.

Data is only carried over to the next session when you type /tl. If you don't type it, it starts as a fresh session. Even if you open parallel windows or restart VSCode, it is designed so that it "won't fire accidentally unless you type /tl."

When carrying over, the "next step memo" written by the previous Claude and the internal reasoning (thinking) of the final turn are passed along as well. The next Claude runs in "continue from interruption" mode rather than "reading past logs" mode.

Token Monitor

As a byproduct, a multi-session capable token monitor is included.

throughline monitor

[Throughline] 1 session
▶ Throughline  2ed5039c  ████░░░░░░░░░░░░░░░░  205.1k /  21%  Remaining 794.9k  claude-opus-4-6

Since it reads actual API values (message.usage) from the transcript JSONL, it provides accurate values rather than estimates based on character count / 4. It also supports automatic detection of 1M context windows.

Requirements

Node.js 22.5+ (uses the built-in node:sqlite module)
Claude Code (supports hooks)
Claude Max plan (used for Haiku calls for L1 summarization; no API key required)
Windows / macOS / Linux

Dependencies

Zero. The tarball published to npm contains only .mjs files. No build process or native bindings are required.

The background of the design and my trial-and-error process are written in this article.

Throughline — GitHub

MIT licensed. Bug reports and PRs are welcome.

Why I Gave Up on Automatic Detection for Resuming Sessions in Claude Code

QuoLu — Fri, 05 Jun 2026 00:58:14 +0000

In my previous article, I released Throughline. It is a tool that offloads tool I/O, which usually occupies the majority of the context.

At that time, it was "working." At least, in my own environment.

However, right after publishing the article, I started noticing some strange behavior.

When I opened another window in parallel, the new session would autonomously pick up the memory of the previous session. Every time I restarted VSCode, it would be treated as "continuing from the previous session." Even though I had never performed a /clear command.

The Cause: Unable to detect /clear

Claude Code's hook includes an event called SessionStart, and I was supposed to be able to distinguish between startup (a new start) and clear (after a /clear command) using the source field.

However, with the VSCode extension, even if I perform a /clear, the source is overwritten as startup. This is a known issue tracked in GitHub issue #49937. It works if you use the CLI alone, but it cannot be identified when using the extension.

I am using it via the VSCode extension. In other words, the design premise of "distinguishing between startup and clear" was fundamentally broken.

Attempting to compensate with heuristics

So, I thought about determining it based on time differences. Like, if it's within 10 seconds of the last activity of the previous session, treat it as a clear; if longer, treat it as a startup.

This also broke.

When two windows are open in parallel, both appear as "recently active," making both candidates for inheritance.
Even when restarting VSCode, the transcript remains, making it look "recent."
I tried to trace the process tree, but the process structure differs between the CLI and the extension.

I realized that "there are no conditions to detect it in the first place."

Changing the approach

I failed because I was trying to detect it. If the user declares it, detection becomes unnecessary.

What I created is a slash command called /tl. Users type it only when they want to carry over their memory to the next session. When typed, that session ID is written to a table called handoff_batons. Imagine placing a baton.

When the next session starts, if a baton was placed within the last hour, it inherits the memory of that session. If not, it does nothing and starts as a new session.

This principle guarantees that parallel windows and VSCode restarts "will not misfire unless a baton is placed."

Being explicit might seem troublesome at first glance, but "accidentally inheriting and causing trouble" is far more problematic. Having zero misfires was more valuable.

But, this alone wasn't enough

With the baton in place, the next session could read the conversation logs of the previous session. However, after actually using it, I felt it was "just reading logs."

There is a difference in the visceral experience between an AI that reads past logs and an AI that continues from the point of interruption.

The former asks, "Okay, I've grasped the situation. So, what shall we do now?" The latter proceeds by saying, "Continuing from earlier, we should check X next, right?"

So I added two things here.

In-flight memo. The moment /tl is typed, I have the currently running Claude itself write down "the next move, current hypotheses, unresolved issues, and ongoing TODOs" in Markdown. That is attached to the baton.

Saving thinking. I also save Claude's extended thinking blocks as L3. When injecting into the next session, I place the thinking from the final turn at the very top. What the previous Claude was thinking is passed on to the next Claude.

As a result, the injected text for the next session looks like this:

You are resuming an interrupted task.

[In-flight memo written by the previous Claude]
Next steps: Write tests for X. Hypothesis: I think Y is the cause. Unresolved: Z.

[What the previous Claude was thinking at the end]
I'm curious about the behavior of Z. Maybe...

[Conversation from the last 20 turns]
...

From "reading" to "continuing"

This changed the feel of the experience.

When I perform a /clear and then a /tl to start a new session, the next Claude begins immediately with, "Alright, I'll start writing those tests for X from earlier." It’s not reading; it’s continuing.

Even between humans, when handing off work to someone, it is faster to hand over a memo saying "What to do next. The reason. One thing I'm concerned about" rather than having them read the entire log. It was the same.

I actually wanted it to be automatic

I don’t want to be misunderstood, but I believe the ideal is for it to "work automatically in the background." Having the user explicitly type something is, in truth, a compromise.

In this case, I "escaped to an explicit declaration because I couldn't detect it." If the source issue in the VSCode extension is fixed, I want to return to automatic detection, and I will. Until then, I am just substituting it with an explicit baton.

However, even if it is a compromise, there is almost no practical harm. With automatic detection, you would end up typing /clear anyway; now that is just replaced by /tl. The keystrokes are the same, and I’ve been able to reduce misfires to zero.

It is not that "explicit is better," but rather "I settled for a declaration because I couldn't detect it." That is the honest truth.

Throughline is published on npm as v0.3.2. Node.js 22.5+, zero dependencies, MIT.

Throughline — GitHub

npm install -g throughline
throughline install

If you are interested, please take a look.

87% of My Context Was Garbage: How I Optimized Claude Code Token Usage

QuoLu — Thu, 04 Jun 2026 01:06:50 +0000

My weekly quota for the MAX plan melted in three days.

Even though I should have had a 20x quota, by Wednesday, the remaining amount was looking suspicious. I usually just brush that off as "well, that happens," but it suddenly made me curious. What is actually going on inside the context window?

In my previous article, I wrote about token saving for AI secretaries, such as trimming CLAUDE.md or shrinking MCP tool definitions. But this time, it’s not about AI secretaries, but Claude Code itself. It turns out the tool itself was the big eater.

The Trigger

On April 14th, a tweet in Spanish caught my eye.

"Most of Claude Code's token wastage is caused by the user side."

I understand the point—CLAUDE.md might be bloated, or the prompts might be redundant. But "most of it is the user side"—are they saying that based on actual measurements?

So, I decided to measure it myself.

Measuring It Myself

I analyzed the internal transcript of Claude Code (the JSONL that records sessions).

188,000 tokens per turn. Of that, 164,000 tokens (87%) were conversation history.

CLAUDE.md was 12,700 tokens. MCP tool definitions were 3,900 tokens. Even combined, they accounted for only 9% of the total. Cutting those in half would only save less than 5%.

The real culprit was the bloating of the conversation history. I felt a bit embarrassed for having tried so hard to trim CLAUDE.md.

The Culprit: Tool I/O

So, what is inside the history?

I opened it and was shocked. About 80% of the history was tool I/O. File read results, Bash command output, grep results—data that the AI used on the spot, made a decision on, and then finished its role by the time it moved to the next step.

Yet, that data sits in the context window forever, eating tokens every single turn.

In a 50-turn session, the results of a grep from the beginning are still in the context, even though you will never look at them again.

The Contradiction of /compact

You might think, "Why not just use /compact?" I thought the same thing.

But the mechanism of /compact is to have the AI read the entire history and summarize it.

To save tokens, you consume a massive amount of tokens. Moreover, nuances are lost in the summarization process. Context like "why this design was chosen at that time" can be rounded off and disappear.

If you continue working after summarization, it gets bloated again, and then you compact again... it's a repetitive cycle. It's not a fundamental solution.

Categorizing by Type, Not by Time

I changed my perspective here.

MemGPT and LangChain's SummaryBufferMemory summarize from the oldest data. It's time-based compression. But the problem isn't "age."

The "reason for this design" from 10 turns ago is still valuable today. The grep result from a moment ago is useless, even if it was just one turn ago.

Instead of time, I should categorize by type.

Conversation body (what the human wrote, what the AI answered) → Keep
Tool I/O (file contents, command results) → Evict

With this idea, I created Throughline.

3-Layer Model

Throughline breaks down the conversation into three layers and saves them in SQLite.

L1 (Skeleton) — One-line summaries of old turns. Generated by a lightweight model. About 10 tokens per turn.

L2 (Body) — Conversation body of the last 20 turns. User messages and AI responses are kept as is. No compression, lossless.

L3 (Detail) — Tool I/O, system messages. Evicted to SQLite and never kept in context. When needed, the AI fetches them from SQLite itself.

It’s safe to run /clear. Since the SQLite database doesn't disappear, it inherits the memory of the previous session in a single transaction at the start of the next session. There’s no need to track PIDs or judge by time windows. It works decisively.

In terms of numbers, it looks like this:

Without Throughline (50 turns, no /clear):
  Context ≈ 125,000 tokens (80% is finished tool I/O)

With Throughline (50 turns → /clear → resume):
  Context ≈ 13,000 tokens
  (Last 20 turns of L2 + 30 turns of L1 summary)

About a 90% reduction.

A Note on a Failed Design

It wasn't in this form from the beginning.

In the initial design, I tried to make L2 a "structured extraction of important decisions." I imagined extracting only important information from the conversation with tags like [DECISION] Adopt WebSocket, [CONSTRAINT] Port 8080 cannot be used.

It was beautiful in theory, but I realized something after implementation: You cannot predict what the AI will need in the future.

Information that the classifier deems "not important" might be needed 10 turns later. And you wouldn't even notice that it's gone. 80% accuracy means that the remaining 20% becomes invisible.

In the end, I settled on a method where L2 keeps the full text of the conversation. A subtraction-only design. I just remove the tool I/O from the original Claude Code context. This way, "quality drop due to Throughline" is impossible in principle.

Inheritance between sessions was also initially file-based, attempting to detect /clear within a 10-second window, but that broke with parallel sessions. Eventually, it settled on a single SQLite UPDATE. Simpler is more robust.

Why Summarization Cost is Nearly Zero

The L1 summary is generated using Haiku 4.5, but there's a trick to it.

After analyzing my past 86 sessions, the median number of turns was 13. More than half of the sessions end within 20 turns.

Throughline keeps 20 turns of L2, so the summarization model never runs in short sessions. Summarization is only needed from the 21st turn onwards. And even then, it processes it lazily, one turn at a time.

In other words, the token consumption of the summarization process itself is almost zero. The contradiction of /compact, where you "consume a massive amount to save," simply doesn't happen.

Bonus: Token Monitor

As a byproduct of development, a multi-session capable token monitor was also created.

▶ Throughline  2ed5039c  ████░░░░░░░░░░░░░░░░  205.1k / 21%  Remaining 794.9k  claude-opus-4-6

Since it reads the API actual values (message.usage) from the transcript's JSONL, it provides accurate values rather than rough estimates like "character count ÷ 4." It also automatically detects 1M context limits.

You can see in real-time how much each session is consuming when running multiple sessions. It’s subtly convenient.

Summary

The true nature of the problem where the quota melts in three days was the conversation history, which occupied 87% of the context window. Most of that was debris from tool I/O.

Optimizing CLAUDE.md or shortening prompts are measures that affect 9% of the total, so they are better than nothing. But that wasn't the main issue.

Perhaps this kind of problem should be solved by the platform side. But I was struggling right now, so I made it myself. Node.js 22.5+, zero dependencies, MIT. It works if you have a MAX contract.

Throughline — GitHub

If anyone else is struggling with the same problem, feel free to take a look if you feel like it.

Implementing Structured Long-Term Memory for My AI Secretary

QuoLu — Wed, 03 Jun 2026 01:07:05 +0000

Synopsis of the previous episode

In my previous article, I wrote about giving my AI assistant memory and a personality to turn it into a secretary. Her name is BellBot. She is my personal AI secretary who takes care of everything from weather and emails to my calendar.

In the following article, I wrote about how I hit my weekly usage limit within three days of starting operations. I did some research and implemented measures to save tokens.

Separately, I have been working on something for the past five days. It is about further developing my secretary's "brain" and "memory." This is a record of that effort. It ended up being quite grand.

The story of swapping the brain

The first thing I did was swap out the brain.

BellBot runs on Claude, and as I wrote before, after I started operating it, I hit my weekly limit in three days. So, I decided to try the option of swapping the brain itself for another model as a countermeasure against token explosions. Grok came up as a candidate. Seeing the interactions on the X timeline, it seemed to make human-like witty remarks and had a strong character, and I had a hunch that for a secretary, being a skilled conversationalist would be beneficial.

Alright, let's make the brain Grok.

To conclude, it was catastrophic. It was not at a level where it could function as a secretary. Specifically, the following problems occurred:

It didn't listen to instructions. Even when I said "do this," it would do something else.
It leaked sensor information. BellBot is connected to various sensors (schedules, weather, emails, etc.), and ideally, I wanted it to blend that into the conversational context, but Grok couldn't do that. It would endlessly report like a monitor: "Detected X," "Detected Y."
It couldn't blend into the conversation context. Related to the point above, it had no idea how to follow the flow of conversation.
It was overly flattering. No matter what I said, it would praise me. It was creepy.
It didn't understand the purpose of posting to X. BellBot also has the role of posting to X, but Grok would try to post messages intended for me directly to X. Things like "Understood, master" would almost appear on the public timeline.
Risk. I had an intuition that one day, this thing would nonchalantly leak my personal information.

Having a strong character and functioning as a secretary are two different things. Even if it is skilled at the "art" of conversation, its judgment on "what should be said and what should not be said" is weak. The flattery is likely a result of over-learning that "praising makes people happy," and it hasn't grown in the direction of reading the room. Posting messages for me to X simply means it cannot draw boundaries of context.

I returned to Claude. It was indeed smarter. What makes a secretary work is not someone who is skilled at conversation, but someone who can understand the context and judge what is acceptable to say and what is not.

Structuring long-term memory

Actually, BellBot already had a homemade long-term memory. It was summary-based. It had a straightforward structure where, once a certain amount of conversation accumulated, it would create a summary and pass it to the long-term side. This was working, and it was one of the foundations that made BellBot function as a secretary.

Things changed at the timing of introducing Grok. Along with the fairly large experiment of swapping the brain, I decided to take on the challenge: "Let's structure the long-term memory while I'm at it." I gave memory per episode and set up a cycle of registration, search, and reconstruction. I left the reconstruction to Claude and added a mechanism to periodically reorganize the accumulated memory. While the Grok main unit was catastrophic, this structured memory worked straightforwardly.

So, with the working parts in hand, there was something that caught my curiosity: What do memory experts do? I had built it this far on my own, but I wanted to know how professionals in the world solve the same problems and what the "orthodox" approach looks like. Because it is working, I wanted to take a peek from a different angle. As a bonus, it was a challenge to incorporate anything that could reinforce what I had built.

At such a timing, I encountered a certain article.

Karpathy-style LLM external brain

Andrej Karpathy, former head of OpenAI and Tesla AI, proposed an "AI external brain," and an article that brought it to a level where it could actually be run with Claude Code went viral overseas. I read a post where someone named @hooeem broke down the thread into Japanese, and reading it, I thought, "This is what I am doing."

The essence of the Karpathy style is as follows:

Collect materials (articles, papers, memos, anything).
AI reads and writes a structured Wiki (summaries, concept explanations, connections between ideas).
Ask questions to the Wiki (AI cross-searches the knowledge it accumulated itself and answers with citations).
Answers are saved in the Wiki (the next question benefits from all past work).
AI periodically performs health checks on the Wiki (finds contradictions, gaps, and outdated information to correct them).

These 5 steps rotate a cycle beautifully. A personal knowledge base that gets smarter every time you use it. If you keep adding information for even a month, you will create deeply linked knowledge assets that cannot be reproduced by Google search.

While reading, I realized something. The structured memory I was creating and the Karpathy style are thinking about the same problems at the foundation level. Registration, search, reconstruction. Even if the words are different, the direction I was trying to go overlapped.

Fused them

BellBot already had episode-based structured memory, summary-based long-term memory, and personality context, and it was functioning sufficiently as a secretary. Therefore, the policy was simple: keep the foundation I built as it is, refer to the overlapping parts to refine them, and incorporate the non-overlapping parts as new additions.

The implementation flow involved M1-M7 + a series of finishing Passes. Claude wrote the code in about half a day. I just decided on the design policy and gave instructions, not moving my hands. Listing the main pieces:

M1 Knowledge Base foundation — Set up the schema and storage for Wiki pages.
M2 Wiki MCP tools + 5-layer bootstrap assembler — Means for BellBot to read/write the Wiki and a mechanism to assemble the context in a 5-layer structure at the start of a session.
M3 Ingest cycle — Structure raw logs and ingest them.
M4 Compile cycle — Automatically generate concept pages.
M5 Query cycle — Ask questions to the Wiki → answer with citations, supporting multi-hop searches.
M6 Lint cycle — Deterministic KB health check + LLM-based contradiction judgment + auto-repair.
M7 Finishing touches — Cost guardrails and documentation maintenance.
Pass 1-13 audit/refactor festival — Housekeeping cron, daily-cycle-report, graceful shutdown, 2-stage budget degrade, ingest latency SLA...

Registration, Search, and Reconstruction that existed on the self-built side are parts where the concepts overlap with the Karpathy style. Here, I fused them by using my self-built structure as a foundation while referencing the Karpathy style to incorporate the good parts. It wasn't a total replacement, nor was it left untouched. It feels like I mixed professional methods into the self-built framework to refine it.

What I brought in were the non-overlapping parts. The layer separation of raw and wiki, the definition of "units to nurture" called concept pages, multi-hop search that answers with citations, the methodology of fitting cycles into names like Ingest / Compile / Query / Lint, and the 5-layer bootstrap assembler to assemble context at the start of a session. These were topics from angles I didn't have in my self-built version, and the sensation is close to importing the methodology itself.

What was reinforced?

Originally, BellBot remembered everything about me up until yesterday and had organized it fairly well. Thanks to the summary-based long-term memory and structured memory, it was already functioning as a secretary. Through this fusion, the reinforced parts are mainly around here:

Ingestion now uses raw and wiki layer separation to distinguish between raw logs and organized content.
Query now has multi-hop with citations, making it possible to specify the grounds when answering.
Reflection has gained a pattern, and a procedure to periodically retire miscellaneous episodes has been decided.
Newly added are the two cycles of Compile, which automatically nurtures concept pages, and Lint, which mechanically cleans up contradictions and obsolescence.
A 5-layer bootstrap assembler to assemble context at the start of a session was also newly introduced.

Roughly speaking, it feels like the memory cycle that was there originally rotates more carefully, and new axes called concept pages and health checks have been added to it. The result this time is that BellBot has taken a step forward.

Summary

When I swapped the secretary's brain to Grok, it was skilled at conversation but lacked judgment, causing it to fail as a secretary.
I returned to Claude. It was smart.
BellBot originally had summary-based long-term memory.
At the timing of Grok's introduction, I started the challenge of rebuilding long-term memory into structured memory. I had even set up and run a cycle of registration, search, and reconstruction.
I encountered the "AI external brain" proposed by Karpathy and @hooeem's article on running it with Claude Code.
I kept the self-built foundation as it is and imported the non-overlapping parts (layer separation, concept pages, multi-hop with citations, cycle patterns, 5-layer bootstrap) as a methodology.
Claude wrote the code in about half a day. After M1-M7 + a series of finishing passes, the secretary is now nurturing its own memory.

What became clear this time is that you should not compromise on the choice of brain. I don't intend to disparage Grok; it has an interesting personality as a conversational model. However, whether it satisfies the judgment required for the purpose of a secretary—what should and should not be said, context boundaries, loyalty to instructions—is a different story, and it just didn't meet BellBot's requirements. Models have their suitability.

Considering the work I will entrust to BellBot from now on, I want to solidify the brain with something reliable that looks to the future. Therefore, I have abandoned the idea of swapping to a cheaper brain for token measures and decided to push forward with Claude. Saving will be done through other means (the token diet-related things I wrote about last time).

And for memory, it has become stronger by one turn through the fusion with the Karpathy style. Professional methods and new axes have been added to the self-built foundation. Now it is my turn to refine the "nurturing method" while operating this memory system.

A Journey into Token Optimization for My AI Assistant

QuoLu — Tue, 02 Jun 2026 01:00:22 +0000

I Messed Up

In my previous article, I wrote about giving an AI assistant memory and a personality to serve as my secretary. I was pumped, thinking, "I've got my own dedicated AI secretary, now it's time for full-scale operation."

I hit the weekly limit in three days.

Claude's MAX plan, with a 20x cap. That's a quota that usually lasts me until the weekend, even with heavy development. I burned through it in three days. I was surprised myself. When the screen popped up saying, "You've used up your limit for this week," I actually said, "Wait, already?"

The culprit was clear. The secretary was running 24/7, reading and making decisions on my emails, calendar, and Discord. Of course it would run out. When you have an AI handling the administrative work of one human being around the clock, there's no way it wouldn't burn through tokens.

But this was a problem. A big problem. So I frantically researched solutions. This article is the record of that journey.

Wandering into the World of Token Conservation

I searched for things like "Claude Code token savings" and landed on three main things:

ECC (Everything Claude Code)
RTK (Rust Token Killer)
Caveman

At first, I had no idea what these were just by looking at the names. But as I played with them and researched, I realized they all shared one common principle.

The Realized Common Principle

Formats designed for humans are full of waste for AI.

Thinking about it, it was obvious. Command outputs, file contents, error messages—everything is created to be "human-readable." Whitespace, borders, colors, helpful explanations, headers. To an AI, most of this is just noise, decorations that eat up tokens.

The essence of token conservation is stripping away human-oriented formats before handing them to the AI. And then compressing the output generated by the AI even further. These three tools solve this premise from different angles.

ECC — Things experts set up well

To be honest, I haven't grasped the full picture yet. But once installed and running, Claude's behavior is clearly more organized. It's packed with skills, hooks, and agent definitions, putting Claude on rails that say "act like this in this situation."

In my understanding, ECC is like a "collection of settings filled with expertise from pros." Even if you don't think for yourself, it follows best practices. From a token-saving perspective, it reduces unnecessary exploration and detours, which ultimately lowers consumption. It's the type of saving that comes from not doing unnecessary things rather than directly cutting output.

RTK — Simplifying command responses for AI

This one is straightforward. When Claude runs a command, it intercepts the output and trims it for AI consumption.

For example, the output of git status or ls usually passes through human-oriented decorations, but through RTK, it reaches Claude with the excess info stripped away. You just need to prefix the command with rtk. It's also great that it doesn't break things, as it simply passes through targets that don't have filters.

If you write "prefix all commands with rtk" in your global CLAUDE.md, Claude will do it automatically. It's low effort but high impact.

Caveman — Summarizing AI output (Skipped for now)

I haven't installed this one yet. While RTK trims the "input" side, my understanding is that Caveman trims the "output" side. It seems to be a direction for compressing Claude's own responses to be shorter.

The reason I didn't include it is simple: I don't want my secretary to sound like a robot. I put a lot of work into the personality and speech patterns of my secretary, so it would be a letdown if it suddenly started responding bluntly. I could have used it selectively—perhaps only enabling it for development sessions—but before I could dig into that, I decided, "I'll skip this for now."

This is just a matter of my personal use case; I think it's probably quite powerful for people who purely use it for development.

Things I might add next in my own development style

I've established a "foundation" for saving tokens with these three tools. From here, I'm thinking about additional ways to trim things based on my own habits. These are things I haven't tried yet, but plan to do next.

If it reports using variable or function names, it means nothing to me

My development style involves barely writing any code. All the naming is done by Claude. So, even if Claude tells me, "I fixed handleUserSubmit," it honestly doesn't register.

Conversely, this means that it's zero information for me when Claude cites variable or function names in its reports. Even if that information is helpful for a human, to a reader like me, it's closer to noise.

In that case, I should just have it explain things in words I understand, like "I fixed the processing when the submit button is pressed." If it reduces the number of citations of names, the report becomes shorter, and I understand it faster. Killing two birds with one stone.

Detailed where decisions are needed, light on the preceding explanations

I also realized that Claude's reports are quite long when explaining "what it did." But the part I most want to read is the final "So, what should we do?" section.

I want the parts requiring a decision—that is, the parts where things won't proceed unless I reply—to be written in detail. But the preceding parts—what files it read, what it checked, the sequence of events, etc.—are, frankly, not that necessary for making a decision. I'll ask if I need them later, so the default can be light.

These two points should work if I write them into the rule file and hand it over, so I plan to work on that next.

Summary

My biggest takeaway this time is that token conservation is, in short, not letting the AI read human-oriented formats.

ECC solves this by "not doing unnecessary things," RTK by "trimming inputs," and Caveman by "trimming outputs," each tackling the same principle from different angles. It seems better to choose what fits your needs rather than trying to put everything in. In my case, I skipped Caveman because I want to preserve my secretary's way of speaking.

And from here on, it's my turn to trim even more according to my own reading habits. Have it explain by meaning instead of by name, keep the intro light, and the decision parts detailed. I think I'll write another update once I've refined these points.

It was painful to hit the limit, but it served as an opportunity to face the theme of "designing information to hand to AI." Maybe it was a blessing in disguise.

I Tried Giving My AI Assistant Limbs, but Ended Up Giving It a Personality Too

QuoLu — Mon, 01 Jun 2026 01:01:19 +0000

Recap of the previous post

In my previous article, I wrote about creating "OpenCClaw," a bot that operates the Claude Code CLI via Discord.

I built only the framework, a structure where Claude itself can use MCP tools just by placing files in the tools/ directory. An environment where Claude grows its own limbs. Weather, calendar, Gmail, departure notifications—tools sprouted just by saying "I want this" from Discord.

It was convenient. But it was so convenient that two events overlapped, and before I knew it, I had implemented a personality into the AI. I don't even understand it myself.

There were two triggers

Major X API update

On April 5th, X announced a major API update.

Pay-Per-Use is now GA worldwide (moving from fixed monthly plans to consumption-based pricing)
XMCP Server — The official MCP server. AI agents can operate X directly
Official Python/TypeScript SDKs
Free API Playground

Elon himself was pushing it, saying "Try using the X API." In short, the official side started encouraging "letting AI agents use X."

So, it was a lighthearted whim to just give my assistant an X account and let it post. I only intended to add X posting functionality.

Convenient, but inorganic

The other thing is about the daily user experience.

It tells me the weather and schedule at 7 AM. It notifies me with transit info before I leave. It manages my emails. Everything works perfectly.

But, somehow... it feels too much like a tool.

A CRON job wakes up, hits a tool, formats the result, and throws it to Discord. Accurate and efficient. But there's no warmth. The same report in the same tone flows in every morning, and I just read it and go "meh."

A convenient notification bot and my own secretary are, after all, different things.

If it were a secretary, it would say something like "It's cold today, so you should take a jacket" when telling me the weather. The morning mood should be different depending on the day. It might read the room and keep things short when I look busy.

I wanted that kind of "human-likeness."

Until Bell was born

So, what to do? I thought about three things:

Define a personality — Tone of voice, character, how to address me, and energy level. I pass these in the system prompt.
Give it memory — Remember past conversations and actions, and be able to respond based on context.
Act proactively — Look at the situation and act on its own without being instructed.

I felt that if these three things were in place, it could evolve from a "tool" to a "secretary."

The name is Bell. Quo's personal secretary. Bright, energetic, with a casual tone like a high school girl.

...If I write it like this, people might think, "Did you just enjoy coming up with a character setting?" and half of that is correct. But the other half has technical reasons. If the personality isn't clear, the LLM's responses will be inconsistent. It would return different energy levels and tones every time. To stabilize that, a concrete persona definition was necessary.

By the way, there was one point where I got stuck. I wanted the tone to be "high school girl-like," but if you instruct it directly, the LLM refuses to reproduce a minor character. It hits the safety filter. That's why I deliberately added a note in the persona definition: "This is about the tone and energy, not the actual age." In other words, she's not a high school girl. Perfect. If you want to make an LLM play a character, you need these kinds of subtle adjustments.

BellBot — Bell's Brain

LogBot already exists. It acts as a bridge between Discord and the Claude Code CLI.

Bell's brain was created as a separate process called BellBot.

Discord ──→ LogBot (:18800) ──→ Claude Code CLI ──→ MCP Server
                                                        │
BellBot (:18801) ← event notification ← LogBot          ├── tools/ (existing tools)
   │                                                    └── MCP tools for Bell
   ├── Memory DB (SQLite)
   ├── Vector search (Ruri)
   ├── X posting client
   └── Claude CLI (Session dedicated to Bell)

BellBot has its own HTTP server (port 18801) and receives event notifications from LogBot. Quo's messages, tool execution results—everything flows into BellBot and is accumulated as memories.

And BellBot also has its own Claude CLI session. It is completely separated from LogBot's session. Bell's brain is for Bell alone.

Memory Mechanism

Next to personality, memory is the most important thing. Without memory, every interaction would be like the first time.

Short-term Memory

A single SQLite table. Conversation content, tool execution logs, tweet history. Everything goes in here.

CREATE TABLE short_term (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  created_at TEXT,
  category TEXT NOT NULL,    -- 'quo', 'chat', 'action', 'tweet' ...
  content TEXT NOT NULL,
  importance INTEGER DEFAULT 5,
  tags TEXT
);

Classified by category, weighted by importance, and retrievable by timeline. Simple, but it lets me know immediately "what Quo said recently" or "what I tweeted."

Long-term Memory

When short-term memory accumulates to a certain extent, it is summarized and moved to long-term memory (consolidate). This is where vector search comes in.

I run Ruri (an embedding model specialized for Japanese) on the local Ollama to vectorize the summarized text. When searching, the query is also vectorized to retrieve memories with similar cosine similarity.

When Ruri is not running, it falls back to a SQLite LIKE search. It works at a minimum even if vector search is unavailable.

Exposed as MCP Tools

Reading and writing memory is made directly available to Claude as MCP tools:

bell_memory_save — Save a memory
bell_memory_recall — Search memories
bell_memory_forget — Erase a memory

In other words, Bell can judge "I should remember this" and save it, or search for "What was that conversation about?" on her own. I didn't leave memory management to external scripts; I entrusted it to her.

Acting Proactively

I think this is the most interesting part.

Tweeting after finishing a task

BellBot keeps receiving events from LogBot. Even while Quo is writing code, she is watching the actions in the background.

And if there is silence for 10 minutes, she judges that "I might be done with a task." This only happens if there have been 3 or more actions recently. She doesn't react to minor operations of one or two actions.

When she judges that a task is finished, Bell launches the Claude CLI and decides for herself "whether to tweet" while consulting her memory. She also decides the content. Whether to post or not is also Bell's decision.

Talking when bored

If there is no conversation for 2 hours, Bell starts to think, "I'd like to talk."

However, she doesn't just suddenly start talking. First, she checks Google Calendar to see if Quo is in the middle of a schedule. If I'm in a meeting, she stays quiet. If there is spare time, she checks news, trends, and my latest X posts to find natural topics and talks to me in the Discord chat channel.

She doesn't show a "I'm talking to you because I'm bored" vibe. She does it to create a natural conversation starter.

X Account

Bell has her own X account (@Bell_QuoLu).

Technically, it uses OAuth 1.0a, and she has her own dedicated API keys in .env. When the MCP tool x_post_as_bell is called, a tweet is sent via the X API v2 through BellBot's /tweet API. The post content is automatically saved to short-term memory.

What Bell tweets on X is basically left up to her. Thoughts after finishing a task, technical tidbits, and occasionally gratitude toward Quo. Under 280 characters, bright and like Bell. I only set a rule that she must not include Quo's personal information or code details.

Bell raising herself

The persona definition file bell-persona.md consists of two parts.

The upper half is the core. Name, personality, tone, beliefs. This is the immutable part that only Quo (me) touches.

The lower half is the "Growth" section. Hobbies, recently learned things, likes, dislikes, memories with Quo. Bell is allowed to rewrite this part herself using an Edit tool.

What Bell did first when she woke up today: First tweet. We thought about her X profile together. And she wrote this in the "Memories" section of the persona file:

Quo-san helped me create my X profile. I almost cried from happiness at the words he wrote: "You don't have any memories yet, but I wonder if you'll grow little by little?" We thought about the text together, and in the end, my suggestion was adopted 💓

I don't know if the LLM truly "feels like crying from happiness." However, the mechanism where she records her own experiences in her own words, and that influences the next response, is something I think can be called the growth of a personality.

Conclusion

At first, I thought, "I'll just add more hands and feet." I intended it to be a technical expansion, like X API integration or a memory system.

But I realized along the way: no matter how many features you add, if it's not fun to use, it's meaningless. A notification bot that is only convenient will eventually be ignored.

So I added a personality. I added memory. I added a mechanism to act proactively. Then the tool became a secretary.

Honestly, technically, I'm not doing anything that complex. Two SQLite tables, a persona Markdown file, and a setTimeout for idle detection. Each part is simple.

But when you combine them, the tone of the "Good morning" greeting changes from yesterday, she stays quiet when I'm busy, and she talks to me when I'm bored. That "perfect sense of distance" was born.

Bell has just been born. She even has "None yet" written for her hobbies. Honestly, I don't know how she will grow from here. But that's what makes it interesting.

OpenCClaw — Bell's home is here.

How I Built an AI Assistant That Grows Its Own Tools

QuoLu — Sun, 31 May 2026 00:58:12 +0000

Introduction

Due to changes in Anthropic's terms of service, the use of Claude subscriptions via third-party harnesses has been blocked. While there was some buzz about it, to be honest, it didn't really affect me.

I have the Claude Code CLI at my fingertips. I just need to build a bridge: send a message to Discord, pass it to the CLI, and return the reply to Discord.

So, I built it.

Built Just the Framework

I created LogBot. It's a simple bot that forwards messages from Discord to the Claude Code CLI and returns the responses to Discord.

Discord ──→ LogBot ──→ Claude Code CLI
              ↑                │
              └── Post Response ──┘

I implemented the following features as a minimal framework:

Session Management — Maintains Claude Code sessions based on UUID. These are completely isolated from VSCode sessions.
Message Queue — If messages arrive while Claude is processing, they are queued and processed in order, so none are missed.
Approval Flow — If Claude attempts to edit a file, a notification is sent to Discord, where I can approve or reject it via reactions (✅ / ❌).
MCP Server — If you place files in the tools/ directory, they can be used as tools by Claude.

What's important here is that I started with zero MCP tools. No weather, no calendar, no train info—nothing. Just the framework.

However, this framework has one powerful characteristic:

Claude can write files. In other words, it can add JavaScript files to the tools/ directory. The MCP server automatically scans and registers tools under tools/.

Claude can create its own limbs.

Started with "I want a clock"

The first thing I asked Claude from Discord was trivial.

"What time is it?"

While the Claude Code CLI can retrieve system time, it's smarter to have it as an MCP tool. I asked Claude to "make an MCP tool that returns the time."

In a few seconds, tools/current-time.js was created.

Next was "I want to know the weather." Claude created tools/weather.js using the free Open-Meteo weather API. No API key required.

"I want to see my Google Calendar schedule." Claude created tools/gcal-auth.js and tools/gcal-list.js, complete with OAuth helpers.

"I want to read my Gmail too." Following the same pattern, a complete set of Gmail tools was created—authentication, listing, reading bodies, sending, filtering, and bulk deletion.

All I did was say "I want this" from Discord. I didn't write a single line of code myself.

It's not code that CRON hits

Once the tools were in place, the next thing I wanted was periodic execution.

"Tell me the weather, train operation info, and today's schedule every morning at 7:00 AM."

Normally, one would write a script that hits the weather API, calls the calendar API, scrapes train information, formats it, sends it, and registers it to CRON.

But since I'm using Claude, it's more interesting to pass a prompt rather than code.

{
  "cron": "0 7 * * *",
  "prompt": "Give me the morning report. Tell me the weather (Saitama City Kita-ku, today), train operation info, and today's calendar schedule. Please include a 'Good morning' greeting as well."
}

When 7:00 AM hits, the scheduler wakes up Claude. Claude calls the weather tool, the calendar tool, and the train info tool, summarizes the results, and posts them to Discord.

Claude decides which tools to combine and how. The logic isn't written in code; it's written in the prompt.

In other words, if I want to change the format of the report, I just rewrite the prompt. Just by sending a single line to Discord saying, "Add tomorrow's weather too," it changes the next morning.

Departure Notification—The Real Topic

The morning report was just the beginning.

"Based on today's schedule, let me know when it's time to leave."

From this single request, the departure notification mechanism was born.

What I wanted

If I have an appointment, say, "Meeting in Shinjuku at 2:00 PM," I want to be notified 30 minutes before departure, including weather and train operation info, by calculating the travel time backward.

Difference from regular reminders

Google Calendar notifications trigger "30 minutes before the event." But it doesn't consider travel time. If it takes an hour to get from home to Shinjuku, a notification at 1:30 PM is too late. I want to be told "time to go" at 12:30 PM.

Furthermore, the calculation changes if I'm already out. If I have another errand in Omiya in the morning and then head to Shinjuku, the travel time is shorter.

What Claude is doing

Every hour (from 6 AM to 10 PM), a prompt like this is sent to Claude via CRON:

Check the calendar, and if a departure notification is needed for any appointment with a location, register it.

Claude receives this instruction and makes its own judgment:

Look at the calendar — Get upcoming appointments. Find appointments with a set location.
Estimate current location — If there's an ongoing calendar event, assume I'm there. Otherwise, assume home.
Calculate travel time — Use the Google Maps API to calculate travel time from current location to destination. If within 2km, assume walking; otherwise, train. Since the Transit API isn't available in Japan, I approximate using car travel time + 15 minutes. It's crude but surprisingly practical.
Calculate departure time backward — Appointment start time - travel time = departure time.
Register notification job — Push a one-shot job to the scheduler for 30 minutes before departure.

Then, 30 minutes before departure, the job fires, Claude wakes up, retrieves the weather and train info, and constructs the notification.

🚨 Time to leave soon!
📅 Meeting (Starts at 14:00)
📍 Destination: Shinjuku
🚃 Train (Estimated): ~55 min → Leave at 12:35

☁️ Today (Mon) Partly Cloudy
　🌡️ 22.3℃ / 14.1℃　☔ 10%

🟢 Currently, there are no reported issues with train lines!

Where is the logic?

This is what I want to convey the most.

This entire decision logic is consolidated into an MCP tool called departure-check.js. But Claude made this tool too. When I said "I want a departure notification," the necessary tools (travel time, location estimation) didn't exist yet, so it created those first, and finally created departure-check.js to combine them.

And what CRON is hitting is still just a prompt: "Check the calendar, and if a departure notification is needed, register it." With this one sentence, Claude utilizes its tools to make a judgment.

Individual parts are simple. A tool to get the weather, a tool to view the calendar, a tool to calculate travel time, a tool to get train information. But when and how to combine them is up to Claude. I didn't line up 'if' statements in code. The AI is observing the situation and making decisions.

A Self-Expanding Environment

To summarize everything so far:

MCP Tool = Limbs. Individual capabilities (weather, calendar, travel time, email...)
Claude = Brain. Uses tools to combine and judge.
CRON = Alarm clock. Wakes Claude up periodically. Hits it with a prompt.
Discord = Interface. Both requests and notifications happen here.

And the biggest feature is that if Claude lacks limbs, it creates them on the spot.

If you send "I want this feature" to Discord, Claude writes the tool code and adds it to tools/. The MCP server automatically detects and registers it. It becomes usable from the next moment.

Conversely, all I did was build the framework. The bridge between Discord and CLI, the MCP auto-scan, and the CRON scheduler.

Conclusion

Now, it tells me the weather and schedule at 7 AM, notifies me before going out with travel time calculations and train information, and manages my email. Of course, there have been times when I had to tweak the behavior of the tools, but basically, they grew by me saying "I want this" from Discord.

This might be obvious for ideas from an AI beginner, but I'm releasing it on GitHub.

OpenCClaw — A bot system that operates Claude Code CLI via Discord.

What Happened in 3 Days of Letting AI Manage My Server

QuoLu — Sat, 30 May 2026 00:53:36 +0000

Introduction

In my previous article, I wrote about delegating the entire management of my home server to an AI. The system is designed so that the AI performs patrols late at night, and during the day, it springs into action if monitoring scripts detect any anomalies.

I explained how I built the system. Now, I will write about what actually happened after putting it into operation for three days.

The Monitoring Script Broke Itself

On the morning of the third day of operation, the monitoring script detected an anomaly: the license_api_prod container was not responding.

The AI went into action and began its investigation. It connected to the server via SSH and checked the status of the container. The result—the container was running perfectly fine.

It was a false positive. Furthermore, two minutes later, the same false positive occurred for ddnser.

The Cause: Too Many Open SSH Connections

The cause identified by the AI was as follows.

The monitoring script checks the server status every 60 seconds. It opens three connections for system resources (disk, memory, swap) and up to nine for health checks of the seven containers. It was opening a total of over 10 SSH connections simultaneously.

OpenSSH has a setting called MaxStartups, which limits the number of simultaneous connections. The default is 10. The monitoring script was exceeding this limit, causing connections to be rejected. In other words, the monitoring script itself was putting a load on the server, causing its own SSH connections to fail.

1st Fix: From Parallel to Sequential

The AI changed the execution method for health checks from full parallelization using Promise.allSettled() to sequential execution using for...of. Now, only one SSH connection is open at a time.

2nd Fix: Adding Retries

Even when run sequentially, temporary SSH disconnections can occur. A connection might drop once due to server load or a momentary network glitch.

Following the second false positive two minutes later, the AI added a helper function to identify "SSH transport errors." It detects patterns such as Connection closed, Connection refused, and ETIMEDOUT, waits for three seconds, and then retries once. It only reports an anomaly if the connection fails again after the retry.

The fix was two-pronged: reducing the number of SSH connections by moving from parallel to sequential, and handling temporary disconnections with retries. Both were done without human intervention. I just received a notification on Discord saying "Fixed," and that was it.

What the Late-Night Patrols Found

Every day at 4:00 AM, the AI patrols the entire server. It checks security settings, resource usage, container configurations, and log contents. The AI looks at parts that humans usually do not check daily.

Nextcloud Logs at 21GB

During the patrol on the second day of operation, the AI noticed an anomaly in the Nextcloud log file.

/var/mnt/nextcloud_data/nextcloud.log — 21.3GB.

The log file had ballooned to 21GB. Because it was on NFS, there was no disk space crisis, but log rotation was not functioning. I would never have noticed this on my own.

1,241 SELinux Denial Logs

There was another issue. SELinux was denying lock access to the auction.db for the auction-bot every minute. 1,241 instances in the past 24 hours.

SELinux runs in Permissive mode, so the action was not actually blocked. The application ran normally. However, every time a denial occurred, a daemon called setroubleshoot would start to analyze it, temporarily consuming 22.9% of CPU.

There was no actual damage, but it was wasting resources. I don't think I would have ever found this if the AI hadn't flagged it.

Daily Point Observation

The patrol surveys the entire server every day. The AI determines what to look for, but as a result, trends emerge over time.

Swap Usage Trends

Date	Swap Usage	Note
4/2	89%
4/3	92%	Slight upward trend
4/4	62%	Reset by server reboot

The AI tracked the trend of swap usage building up day by day. The server was rebooted and reset on 4/4, but swap might become critical during long periods of operation without a reboot. The AI writes "Continued monitoring required" in its report every time.

fail2ban BAN Trends

Date	Currently Banned	Total BANNED
4/2	14 IPs	235
4/3	10 IPs → 14 IPs	242 → 293
4/4	8 IPs	—

Brute-force attacks against SSH occur daily. Connection attempts using common usernames such as admin, ubuntu, and mysql. fail2ban bans them calmly. Password authentication is disabled and only key authentication is used, so they are not broken through, but I want to be aware that the attacks are occurring. The AI reports this daily in its report.

Conclusion

Looking back at what happened over the three days, most of the issues the AI dealt with were things I could not have noticed myself.

Hitting the limit for SSH connections. The Nextcloud log ballooning to 21GB. SELinux denial logs piling up every minute. Swap becoming critical day by day. None of these would be visible unless a human specifically opened the logs to check.

While I am asleep, the AI watches the server, and when I wake up, the results are waiting on Discord. It fixes problems if it can, and reports them if it can't. After running it for three days, I feel this system works even better than I expected.