lot-map Shows What Claude Code Is Actually Doing, Live

A free Claude Code mod draws your agent's session as a map beside the chat. Here is how to read it, and what to check before you trust it.

A coding agent's session is a wall of scrolling text. Tool calls, file edits, shell commands, subagents spinning up and finishing, all flying past faster than anyone reads.

So most people stop reading. They glance at the final diff and hope the middle was fine.

That is a strange way to supervise something that can run commands on your machine. The question you actually want answered is simple: right now, is the agent in my files, on the network, or off running something I didn't expect? The transcript has the answer. It just hides it in line 400.

lot-map, a free, MIT-licensed mod for Claude Code that shipped version 0.5.3 on November 12, answers that question with a picture. It draws a live map in a pane beside the chat, and every action your agent takes sends a pulse from the center to a labeled station.

The shift is small but real. You stop reading the session and start glancing at it, the way you glance at a car's dashboard instead of reading the engine log.

There's a catch worth knowing up front. To draw the map, lot-map's hooks receive the full input of every tool call your agent makes, shell command lines included. That makes it exactly the kind of add-on you should read before you install. More on that below.

What lot-map is

Claude Code is Anthropic's command-line coding agent. It supports add-ons, installed through its plugin system, that can add commands, panes and hooks (small pieces of code that run when something happens in the session, like a tool call). lot-map's README calls itself "a mod for Claude Code: a live map of the work, in a pane beside the chat."

The map is a hub with spokes. The center is the agent (it reads CLAUDE by default). Around it sit ten stations: You, Model, Memory, Files, Shell, Network, Browser, Agents, Skills and Hooks. When the agent reads a file, a pulse runs to Files. When it fetches a web page or calls an MCP server (an external tool server), a pulse runs to Network. When it starts a subagent, Agents lights up.

According to the README, the map also carries a few signals worth learning:

Worn spokes. Spokes get thicker and brighter the more they're used, so after ten minutes you can see where the session has spent its time.
The route. A line joins the last few stations the agent visited. Each leg stays for 40 seconds, then fades over 20.
Errors. A red dot with a count marks a failed or blocked action.
Parallel work. ×3 means three calls running at once.
The context ring. It turns amber when the context window (the agent's working memory for the session) is 70% full and red at 90%. Those are lot-map's own display thresholds, not the point where Claude Code compacts the session (summarizes older parts of the conversation to make room), but they're a fair warning that the session is getting crowded.
Model switches. A row like opus 5.5 → fable 5.2 shows up when the session changes models.

Under the map, a feed lists the last 16 actions with simple markers: ● running, · done, ✕ failed or blocked, ◆ model change.

Why a picture beats a transcript

The value isn't prettiness. It's that the shape of a session is information.

If you asked for a refactor and the Network station keeps pulsing, that's a question worth asking. If the Agents station lights up five times, you've got subagents running and a bigger bill coming. If the red dot on Hooks climbs, your own safety rules are blocking the agent over and over, which usually means it's stuck trying the same thing.

Here's how a glance might read in practice (an illustration, not a recorded session). You ask the agent to rename a function across a project. You look over after a few minutes. The Files spoke is thick and bright, which is what you'd expect. Shell has a few pulses, probably tests. Then you notice the route line just ran from Model to Network and back twice. That's the moment to scroll up the feed and see which host it hit. Maybe it looked up documentation, which is fine. Maybe it ran an install you didn't ask for, which is a conversation you want to have now, not after the diff lands. The context ring sitting at amber tells you something else: this session is near the point where older details start getting squeezed out, so it might be a good time to wrap up and start fresh.

None of those are hidden in the transcript. They're just slow to find there. The map turns them into something you notice from the corner of your eye while you do other work.

What it can't tell you

Here's the part to understand before you rely on it. lot-map sorts commands into stations by name, not by what they do. The README says so directly: classification goes "by the command's name, not by what it does."

In practice:

curl, gh, ssh, git push and npm install light up Network.
cat, grep, sed and rm light up Files.
Everything else lands on Shell. So python -c "…" shows as Shell even if that Python opens a network connection.
npx only counts as Network when it runs with -y.

Version 0.5.3 made the sorting smarter. A command wrapped in sudo, env, timeout, xargs or similar is now read as the command it runs, and more installers (uv, pipx, poetry, go get, apt install) count as Network, per the release notes.

That makes lot-map a dashboard, not a firewall. It shows you what the agent appears to be doing. A determined or confused agent can do network work that looks like Shell. If you need enforcement, that's a job for Claude Code's permission rules and sandbox, not for a map.

The trust question

To draw a pulse, lot-map's hooks receive each action as it happens. The README is upfront about what that means: "it is handed every call's whole input, including command lines and the text written to files. It takes names from that and nothing else."

The author makes several specific promises in the README:

"The mod makes no network requests, reads no files, runs no processes, calls no model and adds nothing to the conversation."
Labels hold names, never content: the last two parts of a file path, the host of a URL, and for shell commands the model's own description or the command name, "never the command line."
Between sessions it keeps one thing: the last model used in each folder.
Its hooks change nothing: "it changes no input, no result, no context and no permission decision."

Those are good promises. They're also promises. The README points you to the code that keeps them, the classify function in hooks/map.ts, so you can check.

And there's one sentence every user should read twice: "A marketplace added from this repository follows its main branch, so an update brings whatever is there: read the diff before updating if that matters to you."

In plain words: when you update, you get whatever is on the author's main branch that day. Today's code might keep every promise above. An update is new code with the same access. That's true of most plugins. lot-map is just honest enough to say it.

Put this into practice

Here's the low-friction way to try it, with the trust steps built in.

1. Read the classifier first. Open hooks/map.ts (pinned here to the reviewed release) and find classify. Before any later update, look at the same file on main. You're checking one thing: that it only pulls names out of each action. Ten minutes, well spent.

2. Install it. Inside a Claude Code session:

/plugin install lot-map --marketplace alexeyw/lot-map

Answer y to add the marketplace, then pick a scope (where the plugin applies, for example just for you or for the whole project). From a regular shell, the same thing is claude plugin install lot-map --marketplace alexeyw/lot-map. In the Claude desktop app, use +, then Plugins, Add marketplace with alexeyw/lot-map, then Add plugin.

3. Open the map. It opens by itself when a session starts, if your terminal is at least 144 columns wide. If not, type /lot-map.

4. Turn on hook reasons if you use safety hooks. By default a blocked action shows only the tool's name. The hookReasons option shows the first line of why it was blocked, up to 72 characters. Options are set through /config or claude plugin configure, then a new session. The README's example for setting values from a shell:

echo '{"language":"ru","memoryServers":"my-memory"}' | claude plugin configure lot-map@lot-map --values-stdin

Swap in the options you want, such as {"hookReasons":true}.

5. Update on purpose. Don't let updates be a background event. When you want a new version, read what changed on the repo first, then run:

claude plugin marketplace update lot-map
claude plugin update lot-map@lot-map

and start a new session.

What to expect: the first session feels like watching someone else's screen. By the second, you'll notice you check the context ring and the Network station without thinking about it.

Honest limitations

Young and narrow. It's "built and tested on Claude Code 2.1.321 on macOS"; Windows support is only "users report it working." The releases feed shows a single release, 0.5.3.
Terminal width. The terminal view needs 144 columns and draws text only.
Name-based sorting. As covered above, it can mislabel what a command really does.
No removal instructions. The README doesn't explain how to uninstall. Claude Code's own plugin manager (/plugin) handles that.
Popularity is unclear. Star counts for the repo disagreed between sources when checked on November 12, so treat any number you see as rough.
Unpinned updates. The marketplace follows main, per the README.

The real point

Agents are getting faster and running longer on their own. Reading every line of what they do stopped being realistic a while ago. Not looking at all is the worse option.

lot-map is a small, honest answer: a picture you can read in a second, built by someone who tells you exactly what the code can see. Read the classifier, install it, and watch your next session instead of scrolling it.

Sources: alexeyw/lot-map README and releases, reviewed at v0.5.3 (November 12, 2026); hooks/map.ts; LICENSE (MIT).