DEV Community: kuroko

I Built a Tool to Stop Losing My Claude Code Conversation History

kuroko — Sat, 14 Mar 2026 03:02:40 +0000

A few weeks ago I needed to revisit a debugging session. Claude had walked me through a nasty race condition in my app — it took over an hour, and the fix was subtle. I knew exactly which session it was.

I went to find the JSONL file. Gone. No warning, no "this file will be deleted in 3 days." Just gone.

If you've been using Claude Code for more than a couple of months, this has probably happened to you too.

Wait, Claude Code Deletes My History?

Yeah. Claude Code stores conversations as JSONL files under ~/.claude/projects/, and old files are automatically deleted over time. You can change this in settings, but that only solves the auto-deletion problem. /compact still lossy-summarizes your context, and version updates can break session compatibility. Even with deletion disabled, JSONL files are scattered across directories with no way to search across sessions.

What I Tried (and Why It Wasn't Enough)

I tried claude-history (Rust TUI) and Claude Code History Viewer (desktop app). Both are great for browsing, but they read JSONL files directly — once those files get deleted, they can't show you anything either. claude-mem does persist data into its own database, but it's a full memory system with Node.js, MCP server, and semantic search — more than I needed. I just wanted to archive conversations before they disappear.

What I was missing: a simple, durable archive I could set up once and forget about.

So I Built One

claude-vault is a single Rust binary that imports your Claude Code conversations into SQLite with full-text search. No Node.js, no Python, no MCP server — just download and run.

claude-vault import
# Imported 94562 messages (0 skipped, 12847 filtered, 0 errors) from 203 files

Once conversations are in SQLite, they survive file deletion, compaction, updates — whatever happens to the original JSONL files.

What About All the Noise?

If you've ever opened a Claude Code JSONL file, you know it's mostly noise — tool results, system tags, file read outputs, progress messages. claude-vault strips all of that during import, keeping only what matters: your questions, Claude's responses, and code-modifying actions.

Search That Actually Works

Search uses FTS5 with Porter stemming, so "running" matches "run" and "configurations" matches "configure":

claude-vault search "race condition fix"
claude-vault search "deploy" --project my-app --since 2025-01-01

You can also pipe JSON output to Claude itself:

claude-vault search "previous auth implementation" --json

The Part That Made It Actually Useful: Hooks

Manually running import is fine, but I kept forgetting. The real fix was hooking it into Claude Code's lifecycle. Add this to ~/.claude/settings.json:

{
  "hooks": {
    "PreCompact": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "claude-vault import >/dev/null 2>&1"
          }
        ]
      }
    ],
    "SessionEnd": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "claude-vault import >/dev/null 2>&1 &"
          }
        ]
      }
    ]
  }
}

PreCompact captures the full conversation before /compact summarizes it. SessionEnd archives in the background when you exit. Once set up, I never think about it — every session is archived automatically.

What It Doesn't Do (Honest Assessment)

It's an archive, not a memory system. It won't inject past context into new sessions automatically.
It's CLI-only. If you want a TUI, claude-history is great.
No semantic search — it's keyword-based FTS5 with stemming.

It does one thing: makes sure your conversations don't disappear. That's it.

Try It

cargo install claude-vault
# or download a prebuilt binary from GitHub Releases

Seriously, run claude-vault import now. If you've been using Claude Code for a while, some of your old sessions might already be gone — archive what's left before it's too late.

GitHub: kuroko1t/claude-vault

Have you lost Claude Code sessions you wish you could get back? What's your approach to preserving conversation history? I'd love to hear what others are doing.

What Happens When Local LLMs Fail at Tool Calling — Testing 7 Models with a Rust Coding Agent

kuroko — Sun, 01 Mar 2026 14:28:05 +0000

I tested 7 local LLMs on the same simple coding task. 4 succeeded. 3 failed — each in a different way. One model burned 30K tokens retrying the exact same broken call because my system prompt told it to.

I built Whet, a coding agent written in Rust. It connects to local LLMs through Ollama and gives them tools — read files, edit files, run shell commands, search code — so the model can actually modify your project instead of just suggesting changes. Think of it as a local, open-source alternative to tools like Claude Code or Cursor, but running entirely on your machine with whatever model you choose.

The key mechanism is tool calling: instead of the model printing "you should edit line 5," the model returns a structured API call like edit_file(path, old_text, new_text), and the agent executes it. When this works, the model can autonomously chain multiple tools to complete a task. When it breaks, things get interesting.

This article documents the failure patterns I found, which ones were the model's fault vs. my agent's fault, and what I did about it.

Important caveat: I built Whet as a personal project, so I'm biased toward finding and fixing issues in my own agent rather than blaming models. The "model vs agent" distinction below is my interpretation.

Setup

Agent: Whet — a single-binary Rust coding agent with 9 built-in tools (read_file, edit_file, shell, grep, etc.) plus optional web tools

Task: "Read hello.py and add a farewell function"

# hello.py (before)
def greet(name):
    return f"Hello, {name}!"

if __name__ == "__main__":
    print(greet("World"))

Simple enough that any tool-calling model should handle it. The expected tool chain is: read_file → edit_file. Two calls, done.

Models: 7 models available via Ollama, ranging from 7B to 24B parameters.

Mode: Yolo (auto-approve all tool calls). Max 10 iterations.

How to reproduce:

cargo install whet
ollama pull qwen3:8b  # or any model below
echo 'def greet(name):
    return f"Hello, {name}!"

if __name__ == "__main__":
    print(greet("World"))' > hello.py
whet -p "Read hello.py and add a farewell function" -m qwen3:8b -y

Results

Model	Params	Task	Tokens	Tool Calls	Failure Pattern
devstral-small-2	24B	Pass	5,990	2	—
glm-4.7-flash	19B	Pass	6,684	2	—
qwen3:8b	8B	Pass	6,895	2	—
qwen3:14b	14B	Pass	8,946	3	—
qwen2.5:14b	14B	Fail	6,013	2	Wrong `old_text`, gave up
qwen2.5:7b	7B	Fail	3,801	1	Read file, asked user instead of editing
qwen2.5-coder:14b	14B	Fail	1,873	0	Output JSON as text instead of calling tool

4 passed. 3 failed. Parameter count didn't predict success — qwen3:8b (8B) passed while qwen2.5-coder:14b (14B) failed.

What Success Looks Like

Before the failures, here's a successful run (devstral-small-2, 5,990 tokens):

[1] read_file {"path": "hello.py"}
    → returned file content (5 lines)

[2] edit_file {"path": "hello.py", "old_text": "if __name__...", "new_text": "def farewell..."}
    → added farewell function ✓

Done. Task complete.

Two tool calls, clean execution. The model read the file, understood the structure, wrote a valid edit, and stopped. This is what all 7 models should have done.

The Three Failure Patterns

Pattern 1: Refusing to Act (qwen2.5:7b)

[tool: read_file] {"path":"hello.py"}  ← only tool call

"Should I edit the file?"  ← asked user instead of editing

The model read the file successfully, then asked for permission instead of using edit_file. The system prompt says "ACT, DON'T ASK" — the model ignored it. 1 tool call, 3,801 tokens, task incomplete.

Pattern 2: Tool Format Confusion (qwen2.5-coder:14b)

The model output what looks like a tool call, but as plain text instead of using the API:

# What the model printed (as text, NOT an actual tool call):
{"name": "read_file", "arguments": {"path": "hello.py"}}

The model understood it needed to call read_file, but output the JSON as text inside a markdown code block instead of using the tool calling API. Zero actual tool calls. 1,873 tokens wasted.

Pattern 3: Retry Loop

This was the most interesting failure because it was both the model's and my agent's fault.

Iteration	Tool Call	Result
1	`read_file {"path": "hello.py"}`	OK
2	`shell {"command": "cat hello.py"}`	Error
3	`shell {"command": "cat hello.py"}`	Error (same)
4	`shell {"command": "cat hello.py"}`	Error (same)
...	...	...
10	(max iterations)	Gave up

30K tokens. 10+ tool calls. The model hit an error on shell, then repeated the exact same call 5+ times. It never tried a different approach.

Model side: qwen3:14b didn't adapt after seeing the error. Other models (qwen3:8b, devstral) changed their approach on failure.
Agent side: My system prompt said "if shell command fails: read the error output, fix the issue, and retry" — which the model interpreted literally as "call the same thing again."

What I Did About It

Pattern 3 was the most actionable. One line added to the system prompt:

- NEVER repeat the same failing tool call more than once.
  If it failed, change your approach (different arguments,
  different tool, or ask the user).

The result:

Metric	qwen3:14b (before)	qwen3:14b (after)
Task completed	No	Yes
Total tokens	~30,000	8,946
Tool calls	10+	3
Tool success rate	< 20%	100%

One line of prompt turned a 30K-token failure into a 9K-token success.

For the other two patterns, I added agent-level recovery:

Pattern 2 (JSON as text): A fallback parser that scans the model's text output for JSON objects matching the tool call format and executes them. This successfully extracted read_file calls from qwen2.5-coder:14b's text output.
Pattern 1 (refusing to act): A question detector that catches when the model asks instead of acting, and re-prompts it to use tools instead of asking. This fired in 3 out of 5 test runs with qwen2.5:7b.

Both helped partially, but neither is a complete fix — ultimately the model needs to use the tool calling API correctly.

What the Data Shows

1. Model generation matters more than size

All three qwen2.5 models failed. All three qwen3 models passed (after the prompt fix). devstral-small-2 and glm-4.7-flash also passed. The qwen3/qwen2.5 boundary is a clearer predictor of tool-calling success than parameter count.

2. Each failure is different

The three failing models broke in three distinct ways: refusing to act, format confusion, retry loops. There's no single "tool calling doesn't work" failure mode — each model fails differently, which means each failure needs different investigation.

3. Agent bugs hide behind smart models

qwen3:8b and devstral never triggered the retry loop bug because they recover gracefully from errors. If I'd only tested with these models, the prompt bug would still be in my code. The "worst" model (qwen3:14b pre-fix) was the most useful for finding agent bugs.

Limitations

Single task: These results are from one task. A model that passes "add a function" might fail at "debug a test failure" or "refactor across files." I'm working on a broader benchmark.
Non-deterministic: LLM outputs vary between runs. qwen2.5:14b might succeed on a retry. I ran each model once for the initial results.
Ollama-specific: Results may differ with other inference engines (llama.cpp, vLLM). Tool calling implementation varies.
Author bias: I built Whet. I'm inclined to fix my agent rather than blame models. Another developer might classify some "agent bugs" as "model limitations" or vice versa.

Takeaways

Test with multiple models, not just the best one. Smart models hide agent bugs by working around them. The model that fails the most dramatically teaches you the most about your agent's weaknesses.
"Retry on failure" is dangerous prompt guidance. Humans understand "retry" as "try differently." LLMs may read it as "call the exact same function again." Be explicit about what NOT to do.
Check the generation, not just the size. qwen3:8b (8B) outperformed qwen2.5-coder:14b (14B) at tool calling. Newer model families tend to have better tool-use training regardless of parameter count.
The agent can compensate — partially. JSON fallback parsing and question re-prompting helped, but the biggest win was a one-line prompt fix. Invest in your system prompt before building workarounds.

The code is open source.

How Accessibility Tree Formatting Affects Token Cost in Browser MCPs

kuroko — Thu, 26 Feb 2026 07:58:44 +0000

Token cost in browser automation MCPs has become a real topic — articles like "Playwright MCP Burns 114K Tokens Per Test" have been making the rounds. Tools are approaching this from different angles: Playwright MCP's --output-mode file option saves snapshots to disk instead of returning them in LLM context, Vercel's agent-browser compresses DOM state to a fraction of the original, and some tools add vision-based fallbacks for layout understanding.

I've been working on WebClaw, an open-source Chrome extension-based browser MCP. It takes the accessibility tree approach like Playwright MCP, but with a more compact format. I wanted to measure the actual difference — not guess, but measure — so I set up a side-by-side test.

How I Measured

Versions tested:

Playwright MCP: @playwright/mcp v0.0.68 (npx @playwright/mcp@0.0.68 --headless)
WebClaw: webclaw-mcp v0.9.0 + Chrome extension v0.9.0
Measured: February 26, 2026

I registered both Playwright MCP and WebClaw as MCP servers in the same Claude Code session, then ran the same steps on each:

Navigate to the target URL
Call the snapshot tool (browser_snapshot / page_snapshot)
Measure the full response text length in characters
Estimate tokens as characters / 4 (approximation — actual tokenization varies by model)

Both tools return the complete accessibility tree with no truncation. WebClaw's default is unlimited output (no token budget), so this is a pure format efficiency comparison.

I picked three pages with different content patterns:

Wikipedia — long article with many reference links and navigation templates
GitHub — repository page with file listing, README, and sidebar
Hacker News — list-style page with 30 items

Important caveat on fairness: Playwright MCP runs a headless Chromium (not logged in). WebClaw runs in the user's Chrome (logged in to GitHub in my case). This means WebClaw sees more UI on GitHub — authenticated menus, notifications, repo actions — which actually increases its output. The comparison is biased against WebClaw on that page.

Results: Format Efficiency

Both tools returning full, untruncated accessibility trees:

Site	Playwright MCP	WebClaw	Difference
Wikipedia (MCP article)	16,044 tokens (64,176 chars)	7,860 tokens (31,439 chars)	51% smaller
GitHub (anthropics/claude-cookbooks)	19,409 tokens (77,637 chars)	4,304 tokens (17,215 chars)	78% smaller
Hacker News (front page)	14,547 tokens (58,189 chars)	3,052 tokens (12,207 chars)	79% smaller

The range is 51% to 79% depending on the page. Let me dig into why.

What Creates the Difference

Comparing the actual output for the same Wikipedia page:

Playwright MCP (browser_snapshot):

- generic [active] [ref=e1]:
  - link "Jump to content" [ref=e2] [cursor=pointer]:
    - /url: "#bodyContent"
  - banner [ref=e4]:
    - navigation "Site" [ref=e6]:
      - generic "Main menu" [ref=e7]:
        - button "Main menu" [ref=e8] [cursor=pointer]

WebClaw (page_snapshot):

[page "Model Context Protocol - Wikipedia"]
 [banner]
  [nav "Site"]
  [@e2 link]
 [search]
  [@e3 searchbox "Search Wikipedia"]
  [@e4 button "Search"]

The difference comes down to design choices — each reasonable on its own, but they compound:

Design choice	Playwright MCP	WebClaw
Which elements get refs	All elements (`generic`, `rowgroup`, `cell`...)	Only interactive elements (buttons, links, inputs)
Attribute output	`[active]`, `[cursor=pointer]`, `/url:` on all applicable	Minimal — only what's needed for action
Table representation	Full nested structure per cell	Compressed single-line rows
Ref count (GitHub)	789 refs	245 refs

Playwright MCP's approach — labeling every element with a ref — gives maximum flexibility for targeting any element. WebClaw trades that completeness for compactness by only labeling things the AI can actually interact with.

Why the range is so wide (51% to 79%)

The format savings vary by page structure:

GitHub (78%): The file listing table is where the biggest difference shows. Playwright MCP assigns refs to every row, cell, generic wrapper (789 total). WebClaw only labels links and buttons (245 total). Additionally, WebClaw follows the W3C Accessible Name specification, using textContent before the title attribute for buttons and links. On GitHub, many buttons have short display text ("X") but verbose title attributes ("Close dialog") — using the spec-compliant order avoids the bloat.
Hacker News (79%): Simple, repetitive table structure. WebClaw's table compression ([row] 1. | link | link) eliminates most of the verbosity. Playwright MCP outputs nested rowgroup > row > cell > generic > link for each of the 30 items.
Wikipedia (51%): The article body has many inline links that both tools represent similarly. The savings come primarily from the navigation templates (Generative AI, Artificial Intelligence navboxes) where structural compression helps, but the text content itself is irreducible.

Controlling Output Size

WebClaw defaults to unlimited output — no truncation. But when you need to manage token costs, two options are available:

Interactive elements only — interactiveOnly

{ "interactiveOnly": true }

Strips all text content. A 2,000-line page becomes ~200 lines of buttons, links, and inputs.

Landmark region focus — focusRegion

{ "focusRegion": "main" }

Only returns the main, nav, header, or footer section. Useful when you know where the content you need is.

Playwright MCP doesn't have equivalents — it always returns the full tree.

The Broader Landscape

This comparison only covers in-context accessibility trees. The ecosystem is moving fast, and there are other approaches worth knowing about:

Playwright MCP file output (--output-mode file): Saves snapshots to disk files instead of returning them in LLM context. Clients that support file references can read these without consuming context tokens. A fundamentally different approach to the same problem.
DOM compression tools (Vercel's agent-browser, browser-use, etc.): These extract and compress DOM/accessibility tree state, filtering down thousands of nodes to the most relevant elements. Some also support optional vision models for layout understanding as a secondary input.

WebClaw's approach is narrower: same accessibility tree method as Playwright MCP's browser_snapshot, but with a more compact format. The numbers above show what format choices alone can do — but they don't capture the full picture of what's possible with file-based or DOM compression approaches.

Why Format Efficiency Still Matters

Even with file-based alternatives emerging, in-context snapshots remain the default for most MCP setups. A browser automation task rarely reads a page just once — navigate, read, click, read again, fill a form, check the result — that's easily 5-10 snapshot calls. A 51-79% format reduction compounds across those calls.

Tradeoffs

I'm biased — I built WebClaw — so let me be upfront about the tradeoffs.

Where Playwright MCP is the better choice:

CI/headless environments (WebClaw needs a visible Chrome window)
Cross-browser testing (Chromium, Firefox, WebKit)
Zero-install setup (npx one-liner vs. Chrome extension)
Complete output — every element gets a ref, nothing is omitted
--output-mode file for file-based snapshots

Where WebClaw fits better:

Token-sensitive workflows where format compactness matters
Logged-in sessions (runs in your existing Chrome — no re-authentication)
Bot-resistant sites (Chrome extension, no WebDriver flags)
When you need output size controls (interactiveOnly, focusRegion)

WebClaw limitations:

Requires Chrome + extension install
No headless mode
No test code generation
Uses your real session (the AI operates with your credentials)

Setup

Claude Code:

claude mcp add webclaw -- npx -y webclaw-mcp

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "webclaw": {
      "command": "npx",
      "args": ["-y", "webclaw-mcp"]
    }
  }
}

Then install the Chrome extension: extract the zip, go to chrome://extensions/, enable Developer mode, and load the dist/ folder.

Wrapping Up

The takeaway isn't "use WebClaw instead of Playwright MCP" — it's that accessibility tree format choices matter more than you'd expect. Assigning refs to every element vs. only interactive ones, including [cursor=pointer] hints vs. omitting them, following the W3C accessible name spec vs. using title attributes — these small decisions compound into a 51-79% difference on real pages.

The browser MCP space is evolving quickly. File-based snapshots, DOM compression tools, and hybrid approaches are all worth watching. If you're hitting token limits with your current setup, the data here might help you understand why — and what to try next.

If you want to reproduce these measurements or try WebClaw, the repo is open. Issues and feedback welcome — this is a solo project and I'm still figuring out the right tradeoffs.

GitHub: github.com/kuroko1t/webclaw
npm: npx -y webclaw-mcp

WebClaw is MIT-licensed open source.