Hacker News Reader

Comment by BeetleB | Hacker News Reader

> @-mention files instead of naming them. The file gets attached to your message directly, which saves a Read call, or a search if Claude has to go find it.

I've heard it argued that this is an antipattern. If the file is large, it will read the whole file. With Read or something similar, it can do a targeted search and read only the relevant portion.

Is this still not the case?

Also, since they mention /context: Can anyone explain why /context takes so long to run? It usually takes several seconds, and I've had cases of it taking over a minute.

And why don't they just show the basics in a status line somewhere? Just a plain: "120K/200K tokens" I hate having to type /context just to get this. And I shouldn't need to install an extension.

View on HN

You can make your own status line with something like "120K/200K Fable 5", it's nice.

You can do tons more, really. There’s even a built-in /statusline command to modify it; mine shows both context window usage alongside session and weekly limit, all of them as progress bars. Just ask Claude to do it.

That's what is shown by default in the app.

I'll never understand why anyone would want to restrict themselves to a terminal interface instead, and I say this as a Vim user.

> That's what is shown by default in the app.

It is shown in Claude Desktop if you care to check in Settings > Usage, sure - but not in Claude Code, updated as you work with it.

> I'll never understand why anyone would want to restrict themselves to a terminal interface instead, and I say this as a Vim user.

I usually work with Claude in tandem, that is: The agent is actively working while I am either reviewing code or making changes myself in other places. So this means I want to work within my IDE. If you use Claude Code to vibe-code without interacting with the codebase at all, the Desktop app is probably fine, but for all other purposes, you'll need to run it either in the CLI or integrated into your editor.

And since I use different editors and don't like using either a sub-par U integration or locking myself into the harness of my IDE's vendor, I prefer the CLI as a universal way of running Claude Code.

Claude Desktop also contains Claude Code that you need to select specifically over the default or Cowork. I would refer to it as Claude app vs Claude (Code) CLI.

The app has a context wheel on the right of the chat box, showing both current conversation context breakdown and 5h as well as weekly limits.

> It is shown in Claude Desktop if you care to check in Settings > Usage, sure - but not in Claude Code, updated as you work with it.

What? Claude Code shows you context window and session limits right next to the text input box.

The default status line doesn't do that, but admittedly it has been a while since I used vanilla Claude Code. Either way, it definitely does not display weekly limits out of the box

except in vsc, there it cannot do it

it's easy to create one, or use something like https://github.com/jarrodwatts/claude-hud

> I've heard it argued that this is an antipattern. If the file is large, it will read the whole file. With Read or something similar, it can do a targeted search and read only the relevant portion.

I suspect you're right and that's why they haven't fixed @-search in the desktop app.

I actually don't find myself using it anymore since moving to the desktop app. I went from using various AI extensions in the IDE to Claude Code desktop.

But if that's accurate, why mention it in this post? Maybe because that's the first thing developers will try when moving away from a code editor?

so i actually read beyond the TLDR and the reasons are:

- it gets attached early so fully cached, even if later cache is busted

- it gets included in every request automatically, so if your following requests are going to keep triggering File Read requests it will be much cheaper and faster to keep sending it

My main question is how this works if Claude itself keeps editing the file. Surely then you are sabotaging your own cache rather than helping it.

The things to add this way would be static files that you don't expect to change and to be highly relevant to the following requests. Especially if you want them to be mandatory reading and not just hope the agent will read it.

Reply on news.ycombinator.com