yuya.log
EssayClaude CodeOct 5, 2026

Claude Code stopped being a tool and became a workspace you can program.

Mods look like a small customization feature. Spend an afternoon with them and you realize the interface layer around an AI agent may be the thing that matters most.

Y
Yuya
Builder · Creator OS · Atlanta
19 min read
Claude CodeModsAgent UXTeamBot

Claude Code Mods look like a small customization feature. A way to change some colors, maybe add a status line. That was my first read, and I was wrong about it.

After spending real time with what Mods can do, I think they're something else entirely: Claude Code is turning into a programmable AI workspace.

Until now most of us pictured it as a straight line. You give Claude a task. Claude reads files, writes code, runs commands, hands back a result. Terminal in, code out. Mods add a whole layer that wasn't there:

CLAUDE
RUNTIME
UI panes, bands, status, toasts
Agents subagents and teammates
Events prompts, tool calls, turns
State per session and across sessions
Tools register your own, wrap the built-ins
Controls allow, block, rewrite
Workflow commands, timers, automation
Instead of only telling Claude what to do, you can now change how Claude Code behaves while doing it. That's the distinction that makes Mods bigger than they look.
Claude Code Mods — Octo Quest and TeamBot Mission Control.
Claude Code Mods — Octo Quest and TeamBot Mission Control. Click to enlarge.

What a Mod actually is

Let me drop the technical language for a second. Think of Claude Code as a phone. It works fine out of the box. But you probably want it to behave the way you work.

Maybe you want it to show project progress. Warn you before something destructive. Visualize how full the context window is. Show your remaining usage. Track several agents at once. Remember session state. Tell you which files are being touched right now. Give you a button for the thing you do twenty times a day. Render a diagram instead of dumping diagram source at you.

A Mod is a small piece of executable functionality that changes how Claude Code behaves or how it looks.

Concretely it's a TypeScript module that ships inside a plugin. It hooks events as they happen and can observe them, respond to them, rewrite some of them, keep state, and draw its own interface. Which is a lot more than adding another prompt.

The shape is simpler than you'd expect. Every hook is the same three arguments:

// hooks/register.tsx import type { Register } from 'claude-code' export const register: Register = (on) => { on('tool.call', { tool: 'Bash' }, async ($, e, next) => { // $ — the engine: $.ui, $.fs, $.agent, $.state… // e — the event, frozen // next — run everything beneath, then Claude's own behaviour return await next(e) }) }
Three arguments, and the whole model falls out of them. What you do with next is what decides whether your Mod watches, blocks, or rewrites.

Three things a Mod can do

I find it easiest to think in three categories — and each one maps to one thing you can do with that next function. Click through them:

That second one deserves a pause. A Mod that blocks a call isn't giving Claude another instruction and hoping it listens. It's participating in the execution environment. The call doesn't happen unless the Mod lets it through.

Here's the case everyone imagines first. Claude decides to delete 41 files. Pick what your Mod does about it:

tool.call · Bash · rm -rf ./generatedmod: off
Mod behavior
Same event, four different outcomes, decided by what your hook does with next. None is what happens today if nothing is watching.

And the third category — DISPLAY — is the one I think is most underrated. A Mod can take invisible system state and turn it into something a human can actually read. Instead of Claude is working... you can have a panel that tells you what's being built, by whom, how far along, and whether anything needs you. More on that below, because it's the part I ended up caring about most.

What is a Claude Code Mod? Interface, events, state and integrations.
What is a Claude Code Mod? Interface, events, state and integrations. Click to enlarge.
Where it fits

The ecosystem

Six overlapping words, six different jobs.

Prompt vs Skill vs Hook vs MCP vs Plugin vs Mod

This is the most confusing part of the Claude ecosystem right now, and I don't think that's anyone's fault — these things genuinely overlap. Here's how I keep them straight. Tap a row:

TechnologyMain purposeMental model
PromptTell Claude what to do nowInstruction
SkillTeach a reusable way of doing somethingPlaybook
HookReact automatically when something happensTrigger
MCPGive Claude access to external toolsConnection
PluginPackage and distribute capabilitiesPackage
ModCustomize runtime behavior and interfaceRuntime extension
None of these are competitors. A serious workflow uses four of them at once.

The shorthand I use: prompts tell Claude what to do. Skills teach it how you prefer things done. MCP gives it access to more things. Hooks react to events. Plugins package capabilities. Mods change the Claude Code experience itself.

Hook vs Mod — the one that matters

This distinction is worth extra attention, because classic hooks have been genuinely useful in Claude Code for a while. A shell hook fires when something happens: Claude edits a file, your hook runs ESLint and returns the result. Claude tries a dangerous command, your hook runs a safety check and answers allow or block.

That's great for running tests after edits, formatting, logging, validating commands, sending notifications, enforcing rules. I think of those as automation, guardrails and triggers, and they still do that job well.

Mods work at a different layer:

Classic hook · outside
CLAUDE CODE
Event fires→
…and that's the boundary
↓
External script
returns allow / block / text
Mod · inside
CLAUDE CODE
Prompt↔
Tools↔
Events↔
Agents↔
State · Session↔
MOD · draws UI · holds state · rewrites events
The practical difference: a Mod can draw native interface elements, keep interactive UI alive, rewrite events in flight, and replace parts of the experience. A script called from outside can't do any of that.
Hooks react to Claude Code. Mods become part of it.
Hook vs Mod and Mod Capability Levels.
Hook vs Mod and Mod Capability Levels. Click to enlarge.

How far does a Mod reach?

Not every Mod should have the same access, and this is where I'd slow down before installing things. A useful way to classify them is by reach — and I want to flag that this isn't an official Anthropic permission system. It's a community model. But it's not just a thought experiment either: the public awesome-claude-code-mods catalogue runs a footprint scanner over every mod on GitHub and labels each one exactly this way. Tap a level:

L0
Draws and remembersUI and its own local state. Nothing leaves.
L1
Reads filesSettings, session info, transcripts, project metadata.
L2
Writes, runs, drives ClaudeWrites files, executes processes, triggers workflows.
L3
Reaches the networkTalks to APIs, services, anything outside your machine.
Capability goes up, and the trust you're extending goes up with it. A cute progress bar and a mod that can execute processes and make network calls are not the same kind of thing.
Practical noteYou don't have to eyeball this. claude plugin validate <mod folder> reads a mod's source the way the engine will and reports what it hooks and what it calls — so you can see a mod's real footprint before you trust it with your repo.
Why it matters

The interface problem

The bottleneck moved, and most people haven't noticed.

From tool to platform

Here's the bigger idea. The old shape was Claude → terminal → code, and the interface was something we accepted as given. The new shape is a runtime with seams in it, and those seams are where Mods live. That makes Claude Code feel less like a fixed coding interface and more like a programmable environment built around an AI agent.

Which matters, because agents have developed a problem that more intelligence doesn't fix.

Agents got autonomous. Humans got blind.

Agents now research, plan, edit files, run commands, delegate work, spawn subagents, test applications and review results. All good. But the more they do on their own, the less you can see.

And suddenly you're asking: what is it doing right now? Why did it make that call? Which files is it changing? How far through is it? Which agent owns this? Are two of them editing the same file? Does anything need my approval? Is the context window about to fill up?

Notice none of those are questions about intelligence. The model isn't the bottleneck anymore.

The bottleneck is observability.

That's why I think the UI side of Mods is being badly underestimated. A lot of the early demos are deliberately playful — games, silly status displays, custom themes, ambient worlds. They're fun, and some are gloriously stupid. But underneath the experiments is something serious: developers can now turn raw Claude activity into interfaces humans understand.

Several community Mods already point straight at it.

cctop — a cockpit instead of a chat log

cctop borrows from btop. Rather than watching Claude work and guessing, you get a live dashboard of the session's vital signs — context fill, token usage, cost, cache hit rate, rate limits, tool latency, subagents:

CLAUDE · SYSTEMlive
CONTEXT72%
TOKENS142K
CACHE HIT91%
RATE LIMIT54%
Research Builder Reviewer
This stops feeling like a chat window and starts feeling like an AI developer cockpit. Same session, same model — just instrumented.

context-lens and quota-meter — making the invisible legible

Context is abstract. You know there's a window, but during a long task it's not intuitive what's happening to it. Same with usage: you either check manually or you find out when you hit the wall. Two small Mods fix both by just… showing you:

CONTEXT WINDOW84%
⚠ HIGH — working memory is getting crowded
USAGE · 5 HOUR58%
USAGE · 7 DAY76%
your remaining runway, at a glance
The value isn't the number. It's that a human can look at it and understand Claude's working memory is getting crowded — before the session falls over.

agent-flow — seeing the shape of the work

Multi-agent workflows get incomprehensible fast. "Agent running…" tells you nothing. A live tree tells you everything:

MAIN AGENT
  • RESEARCHrunning
    • Search3 queries
    • Analyzequeued
  • BUILDERrunning
    • CodeDashboard.tsx
    • Testqueued
  • REVIEWERwaiting
    • Review
Something invisible became visible. That's the whole trick, and it's the direction I find most interesting.

There's also claude-mermaid, which renders Mermaid blocks into actual diagrams instead of making you read diagram source. Different surface, identical pattern: raw AI information → Mod → human-readable interface. That pattern goes far beyond diagrams.

From observability to control, with TeamBot Mission Control.
From observability to control, with TeamBot Mission Control. Click to enlarge.

What kinds of Mods are showing up

The ecosystem is young — the public catalogue sits at around 31 scanned mods from 92 candidate repos as I write this — but the categories are already clear, and each one answers a real question:

Context & usage

How healthy is my session?

  • token-ledger
  • context-lens
  • cctop
  • quota-meter

Workflow

Can I move through work faster?

  • replay theater
  • autodev-core
  • cache keeper
  • next steps

Agents

What are my agents doing?

  • agent-flow
  • subagent dashboards
  • workflow monitors

Safety

Should Claude be allowed to?

  • secret-redactor
  • blast radius
  • collision warnings
  • command guards

UI

Can it fit how I work?

  • claude-mermaid
  • ambient interfaces
  • model / effort controls
  • custom status lines

Experimental

What is this thing capable of?

  • multiplayer games
  • ambient worlds
  • terminal browsers
  • things to do while waiting
Some of the experimental ones are intentionally ridiculous. I'd argue they're still valuable — silly experiments are how a platform's real limits get found.
My experiment

Building one

The part I'm actually doing instead of just reading about.

I didn't want to install ten Mods. I wanted to build one.

After going through the ecosystem my question stopped being "which ten should I install?" and became: what happens if I build Mods around my own AI system?

I already run a multi-agent setup I call TeamBot. Rather than treating AI as one assistant, the work is split across roles:

LEAD
RESEARCHinvestigates
BUILDERcreates
REVIEWERchecks
It works well. It also walks straight into the problem from earlier.

Because as more agents work at once: who's doing what? What's finished? What's blocked? What needs me? Are two of them touching the same file? That's the exact blindness I described above — except now I'm the one who built it.

Experiment 01 — TeamBot Mission Control

So rather than another generic Claude dashboard, I want an interface built specifically for running an AI team. I have built a demo of that interface. The interactive concept below uses simulated data — click an agent; my actual demo screenshot follows:

TEAMBOT · MISSION CONTROL● simulated demo
PROJECTCreator OS — Content Radar
72%
⚠ Builder requires approval
The dashboard isn't the point. The point is the loop it creates: observe → understand → control, without leaving the terminal.
TeamBot Mission Control — original screenshot, shown in DEMO mode.
TeamBot Mission Control — original screenshot, shown in DEMO mode. Click to enlarge.

Experiment 02 — Octo Quest

My other experiment is Octo Quest: a small pixel-art companion inside the terminal. The screenshot shows the pink octopus, a quest indicator, and memory and energy fields. Those fields are still showing placeholder values in this capture.

Octo Quest — original screenshot in the Antigravity terminal.
Octo Quest — original screenshot in the Antigravity terminal. Click to enlarge.

From dashboard to control surface

I don't want Mission Control to just say Builder: working. That's a status light, and status lights don't help you. Clicking Builder should give me something I can act on — what it's building, how far in, which file it has open right now, what it's waiting for, and the buttons to do something about it.

That's the difference between a dashboard and a control surface. A dashboard tells you the state of the world. A control surface lets you change it. Mods are the first thing that make the second one possible inside Claude Code, because a Mod can both see the agent's state and act on the event stream — the same loop, in one place.

The piece I keep coming back to is approval. Right now, when an agent in my setup hits something that needs a human, the signal is… a line of text scrolling past, which I may or may not be looking at. With a Mod, that becomes a pane that persists, a toast that interrupts, and a button that resolves it. Same information, completely different reliability.

What I'm building next

I'm starting small, because the lesson from every other extension ecosystem is that people over-build their first one and never ship it. So: Mission Control as a read-only pane first — agents, status, current file, progress. L0 territory, nothing it can break.

Then one approval control, because that's the thing that actually costs me time today. Then collision detection, because two agents editing the same file is the failure mode I hit most and the one I can never see coming.

If that works, the interesting question opens up: once your AI team has a control room, does the way you delegate change? I suspect it does. It's much easier to hand work to four agents when you can see all four of them.

The part I keep thinking about

Mods will produce a lot of noise. Themes, games, novelty status lines, things that exist because someone could. That's fine — that's every platform's first year.

But the quiet version of this story is that we spent two years making agents more capable and almost no time making them legible. Every serious autonomous system humans work alongside — planes, factories, trading desks, operating rooms — eventually grew an instrument panel. Not because the system was weak, but because the humans needed somewhere to look.

Claude Code just got the ability to grow one. I think that's the actual headline, and I don't think it's about customization at all.

◆
Y
Yuya

Builds AI-native tools in public and makes educational content for the vibe-coder community. Currently building Creator OS and TeamBot. If you're building a Mod for your own agent setup, I'd like to see it.

Sources & further reading Mod mechanics are from Claude Code's own plugin-authoring documentation. The reach levels and catalogue figures come from the community awesome-claude-code-mods catalogue and its footprint scanner, which labels every scanned mod L0–L3. Named mods — cctop, context-lens, quota-meter, token-ledger, agent-flow, claude-mermaid — are listed there. The explanatory graphics have been rebuilt as vector diagrams for readability. Embedded demo screenshots are the original captures. The interactive examples use simulated data. Octo Quest and TeamBot screenshots are my own demos; TeamBot is shown in DEMO mode.