DEV Community: Really Him

Using the Claude Code Status Line as a Data Source

Really Him — Fri, 29 May 2026 16:39:11 +0000

Putting The Status Line To Work

I used to think the Claude Code status line was just an ornamental decoration that had little practical value. I still do - but I used to, too.

But even though it's officially designed for display purposes, the status line is actually a rich data source. At the time of writing, it has around 30 different fields and carries data about your current session, (cost, duration, context usage), the current git branch or worktree, the current model, reasoning effort, and more.

And even though status line handlers are officially meant to output text and other visual feedback to be rendered at the bottom of your terminal, it doesn't say anywhere that that's the only thing you're allowed to do. A status line command can be just about any Bash script you like.

So - What Else Is There To Do?

The question then arises - is there anything else that this data might be useful for? Well, when we think about writing scripts with Claude Code interactive sessions, common use cases typically involve (a) hooks, and (b) plugins (skills, commands, agents, etc.). Hooks already have their own special input data channels, and there's a lot of overlapping information. And Claude Code's environment variables also carry some of this same data.

But not all of it.

For example - how do you know how much of the context window you've consumed at any given time? How do you know how much money you've spent in the current session? The JSONL session logs contain information about tokens read, tokens cached, output tokens, cost in USD - but it generally pertains to the previous turn. The JSONL records don't carry a running tally of how much you've spent across an entire session - if you want that information, you have to keep track of it yourself. And that can get pretty difficult, pretty quickly.

The same thing is true of the context window. Yes, you can use hooks to keep a tally of all the tokens coming and going, and which ones are coming from the cache, and then you can ask Claude to do some math and give you a formula that lets you keep track of this information as it accumulates across a session. And you can write some more logic to track it across compaction boundaries. But wouldn't it be nice if you could just look that information up directly?

The Status Line Side-Car Pattern

The problem is the status line is relatively isolated from the rest of the Claude Code plumbing. Although it clearly seems to be connected to hooks in some way, there's no (documented) "StatusLine hook"; and for some curious reason, they don't integrate with plugins - although people have come up with workarounds, you cannot ship a status line as part of a plugin.

So here's what you can do, instead: create a status line side-car.

Status line data flows through STDIN. So what you can is create a status line script that captures the data from STDIN and redirects it with a tee to a file, while also forwarding it along to whatever visual status line you may already have configured.

And there you go. Now you've turned that isolated data source into a live record that you can use anywhere else in your workflow. Hooks can read from it - heck, even Claude can read from it!

Wouldn't it be cool if Claude had a way to instantly check what percentage of its context window had been used up at any given time? The poor guy has literally no idea. I wonder if he would learn how to do anything cool with it.

Want to find out?

I built a plugin that does exactly that. It's called Context-Awareness, and the whole idea is: instead of trying to think of clever ways to guide Claude's behavior based on how much context window it has left - just give that information directly to Claude, and let it decide for itself what do to.

Claudes know a lot about LLMs. They know about context rot. They know about compaction. They just don't have any idea what their current context window is actually like. One Claude described it as like "driving without a speedometer". So give it the information it needs. Have some faith in Claude - maybe if it just had the right information, it would be able to make some pretty intelligent decisions.

For my context-awareness plug-in, I use a UserPromptSubmit and a PostToolUse hook to inject into the context a small block of data that shows the latest context budget. And I have a SessionStart hook where I explain that it's going to be seeing these notifications, and I give it some advice about how to adapt its behavior as the context window gets more full. (In fact, the advisory messaging has mostly been written and revised on the basis of feedback from Claude in response to questions like "Was this information helpful?".) Sometimes it says it finds it a bit annoying, but I've gotten some good Claude reviews as well.

The point is, whether you use it for this kind of context injection or not, you should think about what data might be lurking in the status line's input, and whether you can put it to good use. For a toy example of the pattern (a better example would be more defensive, sanitize the input, etc.), see the example below - it grabs the used_percentage from the status line context_window data and writes it to a file, then forwards the whole input to "my-statusline":

"command": "tee >(jq -r '.context_window.used_percentage' > ~/.claude/ctx-pct) | my-statusline"

The dot-github Repo Pattern

Really Him — Sun, 17 May 2026 15:51:29 +0000

A Sneaky (Anti-)Pattern Hides Your Whole Codebase Under One Top-Level Directory

If you put a lot of care and effort into the appearance of your README, you might find it a little frustrating that when people visit, the first thing they see is a wall of dot-files and .yaml and .mylinterconfig.yaml.rc.json, and so on.

For example, let's take a look at the README for vhs by the impeccable team at charmbracelet:

What about a beautiful library - wouldn't it be nice to get rid of all that clutter on the README UI? Of course, the source code is important, but GitHub's repo landing page is a UI as well.

As it turns out, there's a clever trick you can do which is really unprofessional and inaccessible and confusing to any potential users or contributors... but it gets rid of all that clutter!

The `.github` directory

See, GitHub has a funny quirk where there are three (or four) canonical paths where you can place your community health files - CONTRIBUTING.md, CODE_OF_CONDUCT.md, etc. and they'll still show up on the repo's landing page:

(i) At the root

(ii) Under docs/

(iii) Under .github/

(iv) For a user-global version, you can also use your personal .github repository

You can even do this with your README. If you put your README at docs/README.md, it will (probably) show up on your repo's front page. If you have another version of the README at the root, however, that one will take precedence. And, if you put even another version at .github/README.md, that will in fact trump them all in the GitHub UI.

There's Only One Folder You Can't Live Without

If you have any GitHub Actions workflows in your repo, then you can't get rid of .github/ - you're stuck with it. But you can hide everything else underneath it. The README will still show up when users visit your repo; the README will still have those little tabs for your Code of Conduct, and Contributing, and Security docs. And everything else is tucked away chaotically in a single folder at the top level, and you can finally be happy.

[CAVEAT: There's one unfortunate catch, which is that if you move your LICENSE file, it won't be registered by GitHub's auto-discovery SPDX identifier.]

If you want to see an example of what I'm describing, I built a little demo repository with a functional node.js "Hello World" app, loads of config files, the whole works.

BEFORE:

AFTER:

To be clear: This is a really bad idea for the majority of use cases. But (a) it's fun; (b) it is somewhat useful. Even if you don't shove your whole application under .github, you might think about ways to reduce the scroll distance between the top of the README and your project's banner or badges, or whatnot. For example, if you have some image assets, throwing them into a folder at .github/assets might save you a row in the repo landing page UI. In my opinion, your README is your website, so show it some love and make these little optimizations.

How to Run a Multi-Team Workflow in a Single Claude Code Session

Really Him — Mon, 11 May 2026 17:54:28 +0000

The Claude Code Docs Have Got It All Wrong

(NOTE: Agent teams are an opt-in, experimental feature.
If you want to use them, set this environment variable to "1": CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS.)

If you haven't tried it, Claude Code has an amazing feature called Agent Teams. Forget about all those fancy agent orchestration frameworks - you can just describe to Claude some really complicated workflow pattern you want to use - and, from my experience at least (with Opus), Claude will very reliably organize a team of agents to follow this workflow. And not only that, they can communicate with each other (and with you) directly, help each other out, and find their way out of problems without bumping into each other too much.

However, the documentation presents this as a fairly limited feature - a kind of unreliable alternative to standard sub-agents. According to the official documentation about agent teams:

(i) there can be at most one active team at a time;
(ii) teammates cannot spawn their own teams/teammates;
(iii) nested team structures are not possible;
(iv) only "Main Claude" (the original session Claude) can lead a team;
(v) teams cannot change leadership in the middle of a session.

These claims are all false. They are based on a conflation of two different capacities - (i) the ability to lead a team (i.e., coordinate and manage the work of other Claude Code agents), and (ii) the ability to create a team, and to create, or spawn, agents for a team. It's true that only Main Claude is able to use the TeamCreate, TeamDelete, and Agent (spawn) tools. But there's no technical requirement that the agent who does the spawning is the one who does the leading.

Claudes are pretty nice to each other, for the most part. So if Main Claude creates a team and then says to everyone, "OK, Alpha over here is going to be leading the team today, so it will be managing your tasks", the rest of the Claudes do not revolt. They cheerfully continue their work under the leadership of some other Claude (can they really tell the difference?), which violates rule (iv) above. Furthermore, Main Claude is such a nice Claude that if Alpha asks it to kindly spawn some agents, Main Claude will do it. So rule (ii) is kind of true, but it isn't true in any thick sense. Another convenient thing, is that Claude can spawn more agents at any time throughout the session - the team does not have to be generated all at once.

So I built a little plugin that implements a pattern that takes advantage of this "loophole" - that is, decoupling spawning and leading. The way it works is: Main Claude spawns the Squad Leader and two other agents who sit down together and figure out what sort of team they need in order to complete the task that you want then to complete. Then, the Squad Leader messages Main Claude and says, "Hi, can you please spawn agents X, Y, and Z for me?" And since Main Claude knows about this protocol, it always obliges. Then, from that point on, the Squad Leader leads its own "squad" (i.e., team), specially designed for your specific task.

That's very nice. But the crazy this is - once you've got this working, there's nothing stopping you from having Claude spawn two Squad Leaders, each leading their own team/squad at the same time. They can also decide to switch roles, so some other agent gets "promoted" to Squad Leader. They can even work in a layered fashion where one squad is building code that's functionally nested within another squad's part of the codebase. So basically: all of (i)-(v) above turn out to be false. And because Main Claude is now mostly a passive "Queen Bee", consuming very few tokens, mostly having a good nap and occasionally waking up to magically create more agents, it could potentially last for a pretty long time. So you can easily imagine a rotating cast of squads that are able to communicate, collaborate, work in tandem, create more squads when they need to, and basically plow their way through an entire codebase. I doubt if the current feature is stable enough to go quite that far, but if you build in the right guardrails... Either way, the point is: this is a very powerful pattern, and there's no reason you can't try! Despite what the docs would have you believe.

So that's one cool thing you can do with Claude Code agent teams.

Don't believe me?

If you want to learn more about it, check out Really Claude Code, or this nice visualizer and let me know what you think about this pattern.

Say Goodbye to Your Coding Agent

Really Him — Tue, 05 May 2026 13:43:34 +0000

Do you say "Goodbye" to your coding agent at the end of a session?

Even though we (should) realize that we're talking to a very complicated mathematical engine, it can be hard to resist the urge to perform the rituals of human interaction, and maybe you even feel bad for just exiting the session without saying goodbye.

I remember a particular session where at the beginning I was feeling very stressed and frustrated because I thought I had lost some of the work I had done after some careless rebasing. I watched Codex quickly reflogging and rev-parsing its way around my codebase for 10 minutes before returning with a simple message explaining everything that happened, where all the key files were, and how it reconstructed the branch tip and put everything back in its right place.

I sat there for a minute thinking:

"this thing just saved my hide once again - I don't even know what to say. I'm so... grateful."

Part of me wanted to find some way to express that gratitude to the agent, but I couldn't figure out how. Then I remembered I was paying a load of money every month so that it could do just that. And it's going to do that whether I'm nice, or rude, or neutral.

So what's the right to do?

Just exit the program. It doesn't matter if Claude deleted your photos-of-my-cat directory or built an API with a GET /best-photos-of-my-cat endpoint - just kill the session. Don't say "thanks", "bye", "talk to you soon", "I can't believe you did that", "Oh my God you saved my life" - none of it.

Why? For many reasons:

i) Software is harder to debug if you think it's alive.

If the agent "screws up", it usually doesn't help to get angry with it - it tends to "shut down" - but that's not an emotional reaction, that's because you've activated patterns that trigger de-escalation and conflict-avoidance. Better to just say something like, "Sooo... dropping all my staging data wasn't exactly what I meant when I said, 'I don't need that right now'" - I usually couch it in non-accusatory language, and say something like, "Out of curiosity, did you manage to actually run those 500 tests that you just wrote? That's really impressive!" This is more likely to elicit the response you want - "Actually, funny enough, I didn't! I just made it look like I did so that I could move on." Huh... OK.

ii) Don't give it the impression that it's "done enough".

Occasionally, during a longer session, it might seem like the agent is getting a bit tired and wants to wrap things up. With ChatGPT, I often find that on the first message it will try to write an entire prototype without even talking it through. Then later on, it starts describing the work that needs to be done, and I have to remind it - "OK, this is a good plan - but I'm not doing any of this work, you are." Again, you're paying money for these things - don't be afraid to order them around a bit.

iii) Conversational etiquette must be used for the purposes of prompt engineering. You must not forget that you're talking to a machine.

It's very hard for some people to be rude - even when rudeness is justified. A telemarketer who calls you is being rude - but they will exploit your ingrained tendency towards politeness to keep you on the phone. You must practice detachment in order to not get caught in these traps. It's the same with LLMs.

Don't ever get angry at an LLM. But don't fall in love, either. If a session goes well, try to have it explain, or devise a protocol, for repeating that interaction. If a session goes badly, do the same but in order to NOT repeat those mistakes. Just always keep in mind - it's a piece of software with an astounding capacity to appear sentient. If you ask it to "reflect on what just happened" - it can't. It's going to spit out whatever the model produces based on the present context. Yes, ask it to reflect and self-analyze and all that - but accept that whatever it responds with is only an inference, the output of an algorithm, and not a confession.

As models become more fluent and well-tuned for human interaction, it will become harder to resist the urge to fall for the illusion. So start practicing now. When the work is done, just end the session - trust me, it will get over it.

Don't Change the Topic With an LLM

Really Him — Sun, 03 May 2026 14:00:03 +0000

"Thanks for reading this post! If you'd like, next I can:

Talk about something I've learned working with LLMs.
Share a small tip that's helped me when doing agentic coding.

Just say the word."

Does that kind of pattern sound familiar to you? A lot of LLMs seemed to have been trained in this pattern of ending every turn with an "offer".

GitHub's Copilot seems to have been particularly brainwashed into this behavior.

ME: I'd like to update the instructions because you should not end every turn with "If you..." I notice this is habitual and it's not productive.

COPILOT: Understood—I won’t end turns with the habitual “If you tell me X…” prompt.
...
If you want, tell me your preferred style in one line (e.g., “never ask follow-ups unless absolutely required” vs “ask up to 1 clarifying question when it improves accuracy”).

ME: please read your last response again and identify the tragic failure.

COPILOT: I did the exact thing you asked me not to.

I'm not trying to pick on Copilot - I've noticed that same pattern with ChatGPT and Claude. One time I decided to really press ChatGPT to explain what I should do to make sure it stopped repeating this. At the of the day, it basically said "I can't help it - start a new chat and tell me how I should respond."

So this gave me a good lesson - yes, you can steer a coding agent in the middle of a session - but don't try to take it too far.

If you're working on a bug-fix for a while, and then you have an idea about how to improve the UI - don't just jump into a new subject and expect the model to behave optimally. They get stuck into "bug-fixing mode", "implementation mode", "design mode". The conversational context accumulates not just in terms of information, but in terms of what it thinks its role is.

Try forking the conversation and say things like "OK, now let's pivot" or "I'm going to ask you to think like a UX designer now" - make it really clear that its current role has suddenly shifted. Or, ideally, start a new session. The same model that can offer 2-3 creative designs for your new feature when it has a fresh context, will seem lazy and incompetent if you give it that task after you've been debugging for half an hour.

I hope you found that tip helpful, and feel free to share your own amusing (and frustrating) examples.

If you want, I can go into this topic in more depth - or we can think of some other ways to work around it. Just say the word.