3 ms·

> @-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'

by BeetleB 2mo ago

> @-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.

rhaksw 2mo ago
> 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?
- deleted 2mo ago
  [deleted]
sadfgknerknksdf 2mo ago
You can make your own status line with something like "120K/200K Fable 5", it's nice.
- 9dev 2mo ago
  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.
  - user43928 2mo ago
    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.
    - 9dev 2mo ago
      > 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.
      - bix6 2mo ago
        > 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.
        9dev 2mo ago
        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
      - user43928 2mo ago
        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.
- 50or05 2mo ago
  except in vsc, there it cannot do it
flonle 2mo ago
[dead]
zmmmmm 2mo ago
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.
imgyuri 2mo ago
it's easy to create one, or use something like https://github.com/jarrodwatts/claude-hud https://github.com/jarrodwatts/claude-hud

by BeetleB 2mo ago

rhaksw 2mo ago

> 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?

deleted 2mo ago
[deleted]

sadfgknerknksdf 2mo ago

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

9dev 2mo ago
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.
- user43928 2mo ago
  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.
  - 9dev 2mo ago
    > 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.
    - bix6 2mo ago
      > 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.
      - 9dev 2mo ago
        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
    - user43928 2mo ago
      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.
50or05 2mo ago
except in vsc, there it cannot do it

flonle 2mo ago

[dead]

zmmmmm 2mo ago

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.

imgyuri 2mo ago

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