Notes — Brahim Bousnguar

Counting Claude Code tokens from the logs? You're probably 2.5× too high

2026-09-18T00:00:00Z

If you add up token usage from Claude Code's session logs line by line, your total is wrong. On my machine it was 2.5× too high, and output tokens were 4.4× too high.

The logs aren't lying. Every line just repeats the usage of the whole reply it belongs to. Count replies, not lines: key by the message id.

I hit this building Meterlex, a tool that prices my AI coding usage at API rates. Here's what's going on and the fix.

One reply, many lines

Claude Code keeps transcripts in ~/.claude/projects/**/*.jsonl. A single assistant reply isn't one line. Each part of it is logged on its own line: the thinking, the text, each tool call.

And each of those lines carries the same usage block, for the whole reply. Simplified, with made-up numbers, one reply with a text part and a tool call looks like this:

{"type": "assistant", "uuid": "a1…", "message": {"id": "msg_01X…", "usage": {"input_tokens": 12, "output_tokens": 480}}}
{"type": "assistant", "uuid": "b2…", "message": {"id": "msg_01X…", "usage": {"input_tokens": 12, "output_tokens": 480}}}

Two lines, two different uuids, one message.id. Sum both and you've counted that reply twice. A reply with five tool calls gets counted six or seven times.

How big the error is

On my Mac's transcripts: 44,158 assistant lines, but only 18,701 actual replies.

Counting lines gave 2.5× the real tokens. Output tokens were 4.4× too high.

That matters if you're doing what Meterlex does: comparing a flat subscription with what the same usage would cost on the API. Overcount the usage and the subscription looks like a way better deal than it is.

The fix: key by message id

Use message.id as the key for a reply, and when you see it again, merge instead of adding. The one subtle bit: a reply's numbers can grow while it streams, so keep each count at its largest value, not the first or the sum.

This is the core of it, from the Meterlex collector:

def _merge_max(a, b):
    """Two records of the same reply: each token count at its largest
    (a reply's numbers only grow as it streams), the earliest time."""
    m = dict(a)
    for f in TOKEN_FIELDS:
        m[f] = max(a[f], b[f])
    m["ts"] = min(a["ts"], b["ts"])
    return m

key = (session_id, msg.get("id") or uuid)
replies[key] = _merge_max(replies[key], t) if key in replies else t

Lines without a message.id fall back to their uuid, so nothing gets dropped.

Migrating the rows you already stored

If you've been storing per-line rows, re-sending the same transcript with the new key would just add a third copy. So each reply also carries its old per-line uuids as alt_keys, and the hub folds any stored row with one of those keys into the new one. Old data cleans itself up the next time a file is read.

Gemini CLI does it too

Different tool, same trap. Gemini CLI appends a message again every time it updates it. One project's file had 56,651 lines for 908 messages. Same fix: key by message id.

Codex has a milder version: it can repeat a token_count event with an unchanged running total. Meterlex skips those.

Try it

If you track AI usage from local logs, check your keys. Count distinct message ids against lines on one of your own transcripts. The gap is the overcount.

Meterlex does all of this for Claude Code, Codex, Gemini CLI, Antigravity, Ollama, Copilot CLI and OpenClaw, and it's MIT on GitHub. If your numbers look off in a different way, open an issue.

The official MuleSoft MCP server can't read your logs, so I built one that can

2026-09-18T00:00:00Z

MuleSoft has an official MCP server. It scaffolds projects, generates flows, deploys apps. What it can't do is the one thing I need when something breaks in prod: read the logs.

So I built mulewatch. It's an open-source MCP server that gives Claude, Cursor or any MCP client your Anypoint logs, live and archived. Read-only. One line to run: npx -y mulewatch.

I first built a version of this for my day job. This one is the cleaned-up, works-for-anyone release.

Building vs. running

The official server is for building Mule apps, and it's good at that. But it expects a local Mule project open in your IDE. When a flow fails in prod, you usually don't have one open. You have Runtime Manager in a browser tab.

mulewatch covers the other half of the job: figuring out what happened. Logs, deployed apps, API Manager instances, Exchange assets. Nothing that writes.

The live tail forgets fast

The logs you see in Runtime Manager are a live tail: a small rolling buffer per app. On a busy app it scrolls out in minutes, whatever startTime you pass. If the problem happened last night, it's already gone.

The real history lives in the Anypoint Monitoring Archive API. It stores logs in 10-minute files that land about 10 minutes after each window closes, and keeps them for a long time. You need Anypoint Monitoring enabled on the org.

The fun part: finding the right replica

Here's the catch. The archive isn't indexed per app. It's indexed per replica, as {appName}_{replicaId}, and every redeploy creates new replicas. So you can't just ask for "the logs of order-sync-api on 9 August". You need to know which pod was running that day.

The app I tested on had 669 replica entities in the archive. The API allows 60 requests a minute. Probing all of them is about 11 minutes of waiting before you read a single line.

Turns out you almost never need to. Pods usually live until the next redeploy, so the replica running right now probably wrote the recent logs too. mulewatch does this:

Grab the replica IDs from the live tail and try those first.
No files for that date? The app was redeployed since. Fall back to scanning every replica it ever had, capped by maxEntities.

On that test, searching today probed 1 replica, found 127 archive files and parsed 2,859 log lines. A date from before the last redeploy fell back to the full scan, as it should. The client also stays under the rate limit and backs off on 429, so a long search gets slower instead of failing.

Read-only, on purpose

I don't want an LLM restarting production Mule apps. So there's no deploy, stop, restart or policy tool in mulewatch. None. If you need those, use the official server next to it.

You can also lock the whole server to the environments you trust:

ANYPOINT_ALLOWED_ENVIRONMENTS=Dev,Sandbox

Anything outside the list gets refused, with the reason. Pair it with a connected app that only sees those environments and prod is out of reach twice.

The thing that'll trip you up

Environments live on business groups, not on the root org. Connected-app credentials resolve to the root org, which often has zero environments. So your first call comes back empty and you think the credentials are broken. They're not.

Call anypoint_list_business_groups, grab the right id, set ANYPOINT_ORG_ID. Done.

Same energy for scopes: Anypoint answers a missing scope with a bare 403. mulewatch catches it and tells you which scope you're probably missing.

Try it

Create a connected app ("acts on its own behalf"), give it read scopes, and add this to Claude Desktop, Cursor or OpenClaw:

{
  "mcpServers": {
    "mulewatch": {
      "command": "npx",
      "args": ["-y", "mulewatch"],
      "env": {
        "ANYPOINT_CLIENT_ID": "your_connected_app_client_id",
        "ANYPOINT_CLIENT_SECRET": "your_connected_app_client_secret"
      }
    }
  }
}

Or in Claude Code:

claude mcp add mulewatch --env ANYPOINT_CLIENT_ID=... --env ANYPOINT_CLIENT_SECRET=... -- npx -y mulewatch

Run anypoint_whoami first to see what it's connected to. Then just ask: "show me the ERROR lines of order-sync-api in Prod yesterday between 1 and 3 a.m."

It's v0.1, Apache-2.0, on npm and the MCP registry. Everything is tested against a live org except API Manager, because my test app didn't have the View APIs Configuration scope. If you run MuleSoft, try it and tell me what breaks. Issues and PRs are open on GitHub.

MuleSoft and Anypoint Platform are Salesforce trademarks. mulewatch is an independent project.

My README generator isn't allowed to make things up

2026-09-18T00:00:00Z

Ask an LLM to write a README and you get something long, confident and partly invented: flags that don't exist, env vars nobody reads, a setup step from a different project.

So in vibetidy the LLM doesn't get to decide what's true. A scanner reads the repo, and the model only turns those verified facts into prose.

Funny thing: while building a tool about not advertising what isn't real, CI caught me doing exactly that. Twice.

The scanner is the product

vibetidy readme scans the repository first: the manifest, scripts, dependencies, .env.example, entry points, the folder tree, the existing README. Only those facts go to the model, and the prompt says it plainly: never invent a feature, a flag, an environment variable, a dependency or a version.

When the facts are thin, you get a short README that's right instead of a long one that's plausible. And you can check what the model would see before spending a token:

npx vibetidy readme --print-context

No API key needed for that. It prints the scanned facts and the full prompt, and exits.

Bug one: a flag I documented but never registered

issue-check --help listed --no-changelog. The README's options table listed it too. Using it exited with Unknown option '--no-changelog'.

The flag was never registered in the parser. Node's parseArgs only honours a --no- prefix with allowNegative, which needs a newer Node than the >=20.10.0 the package advertises. So it became a plain --skip-changelog.

The fix was one line. The interesting part is that nothing caught it: the docs looked right, the code read plausibly, every test passed. So I added a test for the whole class of bug. It pulls every flag out of each command's --help output and asserts the parser accepts it:

for (const flag of flagsIn(help)) {
  const res = runCli([command, flag, 'x', '--help']);
  assert.notEqual(res.status, 2, `${flag} is documented but rejected`);
}

To make sure it bites, I planted a fake --phantom-flag in the usage text. The suite failed with the exact rejection message.

Bug two: the tests never ran on Node 20

Opening that PR turned CI red on main: 5 legs out of 9.

npm test ran node --test "test/**/*.test.js". Glob support in node --test only landed in Node 21. On Node 20 the quoted pattern is taken as a literal path, so every 20.x leg failed with Could not find .../test/**/*.test.js. The suite had never run on the Node version engines promised.

The fix is almost funny: plain node --test, with no pattern at all. Default discovery has worked since Node 18. CI went green on all nine legs (Ubuntu, macOS and Windows, times Node 20, 22 and 24).

Same class as bug one: something advertised that didn't work. The 9-leg matrix is why I found both.

npm said no to a name that looked free

The tool started as tidyrepo. npm view tidyrepo returned a 404, so the name looked available.

Then npm publish failed with a 403. npm's similarity check strips punctuation, so tidyrepo collided with an existing tidy-repo. A 404 isn't proof a name is free: check the hyphenated and underscored versions too.

It's vibetidy now, which honestly fits better.

Try it

It's MIT, zero runtime dependencies, and works with OpenAI, OpenRouter, Anthropic, Groq, DeepSeek, Together, or a local Ollama:

npx vibetidy readme --print-context      # see the facts, no key needed
npx vibetidy readme                      # generate, review the diff, confirm
npx vibetidy issue-check --install-hook  # nag on feature commits with no issue

If it writes something your repo doesn't back up, that's a bug. Open an issue on GitHub.