Posted by twapi 16 hours ago
Basically:
- /handoff file creates a short document with the important context from your current session and maybe next steps as checklist.
- You can then start a fresh session with /continue file
- You can also hand the work from Claude to ChatGPT, or the other way around. Very useful at time of session limits.
- Plus your handoff files becomes a useful piece of project memory that you can reference later.
I find this much more useful than /compact or /clear because the context is saved in something portable instead of being tied to one session and i've seen better results doing this every 20 messages or so than running long sessions.
I've been doing this since I started agentic development, and have a whole framework based on this; Simply put I define workflow s that output templated files for everytype of tasks that happens in development.
It's a powerful pattern I'd recommend everyone.
And I think plan files should focus on general ideas and invariants, not do “implementation as prose”. That way they perform as mini-ADRs that are useful historically, especially to mine why the system is the way it is.
Love Claude, but the @ mention is broken in the desktop app. For the same project if I type the same query "@ephem" I get:
CLI: https://imgur.com/a/VZMUCOa (good, relevant results)
Desktop: https://imgur.com/a/QLSo4Ms (bad, irrelevant)
Opened issue for this and it was automatically closed:
https://github.com/anthropics/claude-code/issues/71421
I could have written the issue better (using CLI as comparison instead of VS Code). But, no doubt in my mind Claude could fix this itself in a minute.
Clarification: It wasn’t closed on submission though. It sat open ~17 days, a bot marked it stale, and it closed when nobody responded to the stale label.
The two-phase thing is the part I didn’t know until recently: the stale label is basically asking “is this still relevant?”, and answering it makes the bot back off next time around. nixpkgs does the same. Bumping feels wrong on most trackers, agreed, but at this issue volume I don’t know what else works.
Anyway a comment should reopen it. Your CLI vs desktop screenshots are a better repro than most things in that tracker.
I'm not saying it's a perfect solution but for projects that deal with large amounts of issues it's workable.
It'd save the run around and have the same ultimate effect. Or, we could properly work on tickets instead of making the gate "has enough time to follow up on this 14 days later"
I frequently run Fable at xhigh effort to run statistical modeling way above my undergraduate understanding. Claude Fable produces Masters-degree level output, and then I spend lots of round trips asking it to explain different parts to me.
The first part absolutely uses the extra effort, but the interrogation exercise is something a much simpler model, or the same model with much less effort, could answer.
I would be really curious to know as well, why effort is linked to cache as its quite inconveniant. Is it possible the token used to indicate effort is only passed once at the start, not per thinking trace, or quite simply that different efforts have different model weights?
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.
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 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?
- 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.
I guess compacting somewhat does that but I want something more explicitly that trims out these extremely bloated artefacts while maintaining in full the actual conversation history.
I have 1h cache TTL set, and do nothing to cause rewrite (response in time, no model/effort/tool changes).
At 400K tokens in, I'll write a message, and /usage shows only a small increase in cache write. On the next message, cache writes shows 800K, and by the end, I often hit 2M cache writes with no explanation.
This seems to happen when: using /btw, asking it to review code, other random times. Anyone know what's going on?
_entirely_ vibecoded don't @ me.
It seems to be regular file edits rather than parallel tool calls.
I'm sitting on 1.6m cache write even now with 468k in /context. It drives my session costs above $100 regularly.
Can someone from Anthropic look into this?
Depending on how you're triggering reviews, you may be using a sub-agent?
Until pretty recently, the tools you wrote code with were a flat fee (or free) … [so] an individual task didn't really have a price of its own … [but] with agentic coding tools like Claude Code, it does.
Yes. https://magazine.sebastianraschka.com/p/controlling-reasonin...