Tracking Claude Code token usage in WSL2

If you run Claude Code inside WSL2, you get a real Linux environment on a Windows machine — and with it, a few wrinkles that make token tracking harder than it is on either platform alone. Most existing tooling either assumes native Windows or assumes a Mac, and WSL falls through the crack. Here’s what actually changes.

Your transcripts live in the distro, not on C:

Claude Code writes its session transcripts under the home directory of wherever it runs. Inside WSL2, that’s the Linux distribution’s own filesystem — think ~/.claude/projects/ within the distro — not your Windows user profile. A Windows-native tool looking under %USERPROFILE% won’t find them, and a naive scan of the mounted /mnt/c path won’t either.

That matters for any audit or usage report: it has to know to look inside the distro’s home, using the distro’s real path, to read the JSONL transcripts that hold your token history. Get that wrong and you’ll be told you have no usage at all while your cap quietly drains. (New to WSL? Start with our full WSL2 setup and performance guide, which covers install paths and the placement mistake that quietly slows everything down.)

Mirrored networking changes how a proxy is reached

The second wrinkle is networking. A usage copilot that compresses prompts runs a small local proxy that Claude Code has to reach. On a single OS that’s simple. Across the Windows/WSL boundary it’s not.

Recent WSL2 supports mirrored networking, which makes localhost behave more consistently between the Windows host and the Linux guest. That’s a real improvement, but tooling still has to detect which mode you’re in and wire the client correctly — whether the proxy runs on the Windows host or inside the distro. Assuming plain localhost everywhere is exactly the kind of shortcut that breaks silently on WSL.

Why generic tools miss WSL

Put those two together — transcripts in the distro’s home, a proxy that has to be reachable across the host/guest boundary — and you can see why the Mac-only tools in this category don’t help WSL users, and why even Windows-native tools stumble if they weren’t designed for it. WSL isn’t quite Windows and isn’t quite Linux; it needs to be handled as its own case.

How Hypermile approaches WSL

Hypermile treats WSL2 as a first-class target, not an afterthought. The plan is straightforward: auto-detect a WSL setup, read transcripts from the correct in-distro path, and wire Claude Code to reach the proxy correctly whether you’re on mirrored networking or not — and get out of the way cleanly if anything goes wrong.

WSL users tend to have the same weekly-cap pain as everyone else, just with harder plumbing. Supporting them well is a deliberate priority. If you want the broader picture of the limits themselves, see how Claude Code usage limits work on Windows, and for the biggest sources of waste, where your Claude Code costs go.

Check your WSL usage today

The free hypermile-audit CLI runs inside your WSL distro and reads the transcripts where they actually live. Run it below to see your real token breakdown, then download the app — WSL support included.