To each his own I guess. There was nothing more frustrating than walking away from a CC session you expected to churn away at for an hour and coming back to a user question sitting there. More useful would be just getting a list of clarifying questions at the end of the session along with how it answered itself to follow up with or not.
This is the reason why claude code should be open sourced... But, I guess Boris or Anthropic team doesn't care about it, so that they can continue to install slop at user machines.
~was truly surprised and delighted by this today. claude's recs are usually pretty good. imo as a product engineer this is a good default and all the cranky experts in here can turn it off.~
edit: didn't read closely enough to realize this can't be disabled / think about the perverse incentives. seems bad actually
I’ve definitely sometimes had situations where this would make sense, and also where Claude asks a question not using this tool and it’d make sense to just keep going.
But this does seem like the wrong default to me. I’ve found if I tell Claude I’m AFK and just keep going, it’ll do that reliably. And it’s good at debriefing me afterward on what decisions it made that it would have asked me about.
I don't know about having this on as the default, but it definitely resolves a frequent annoyance of mine. I'd prefer Claude to keep going as far as possible until it's completely blocked. That said, I only give instructions to do that in environments where there's a clear upper bound on "maximal damage" that could be incurred by doing the wrong thing. In live production systems, you really don't want Claude doing much other than observing and reporting anyway.
I've been using a SQLite DB to organize actionability so I don't get stuck in the way that GitHub issue tries to work around. Any questions about which route to take that arise during agentic work are logged to a queue along with a set of plausible candidate routes, a probability assigned to each candidate of whether I will choose that option (including "other/none"), a "resource cost" assessment of the route (e.g., token spend, time), a "stability cost" (e.g., high potential to disrupt things or mainly self-contained), and a set of tasks that describe any downstream work that is dependent on the route chosen.
What Claude does next then depends on the results of a tiny optimization program that tries to maximize the expectation value of agent productivity per unit resource (tokens, time, etc.) conditional on how long it will take me to answer the question (e.g., if Claude has a question for me at 1 AM, there probably won't be a response for another 6-7 hours).
"Agent productivity" is of course a bit nebulous, consisting of a somewhat ad-hoc amalgamation of factors, but in general Claude's actionability loosely corresponds to cases like:
- 2-3 possible routes, each with roughly equal probability of being the one I select, low resource costs, minimal risk of instability, few downstream dependencies: implement each route in parallel
- 2-3 possible routes, one with a much higher probability of being chosen, minimal risk of instability, many downstream dependencies: implement just the top route
- Hundreds of possible routes: block until user response
- 1 possible route, high risk of instability, many downstream dependencies: block until user response
Generally speaking, there should be an active queue at all times and agents should be working on anything that's not blocked in the queue with maximal parallelization.
This does violate the principle of least surprise. But,if you look through their other github issues, it becomes fairly clear that Anthropic are not interested in building an effective sandbox. It's a feelgood sandbox. To be fair, they must have a better focus on Claude not doing stupid things, or they would have crashed and burned by now. Nevertheless, if you want guaranteed limits, then they have to be enforced by external means.
I've never seen this beore today; it happened today and was quite clearly incorrect behavior. I prompted it to research considerations for a significant code architecture decision. It asked a pretty difficult question about which direction to take, something that would take way more than 60s to answer properly. While I was thinking about it, it timed out.
Some Github issues claim that adding
"env": { "CLAUDE_AFK_TIMEOUT_MS": "86400000" }
to ~/.claude/settings.json fixes it. This is plausible, but not documented anywhere (the source claims it was found by reverse engineering, and might break /goal).
19 comments
[ 2.9 ms ] story [ 30.7 ms ] threadedit: didn't read closely enough to realize this can't be disabled / think about the perverse incentives. seems bad actually
Even if I am staring at the screen at the time, it's often impossible to study code and make a judgement call that quickly.
My point being, even for opt-in it can be too short - highlights how little consideration they put into it, just releasing slop in production.
Follow up question - is there a claude code alternative with an open source harness that also costs around ~$20/month? Doesn’t have to be frontier.
But this does seem like the wrong default to me. I’ve found if I tell Claude I’m AFK and just keep going, it’ll do that reliably. And it’s good at debriefing me afterward on what decisions it made that it would have asked me about.
I've been using a SQLite DB to organize actionability so I don't get stuck in the way that GitHub issue tries to work around. Any questions about which route to take that arise during agentic work are logged to a queue along with a set of plausible candidate routes, a probability assigned to each candidate of whether I will choose that option (including "other/none"), a "resource cost" assessment of the route (e.g., token spend, time), a "stability cost" (e.g., high potential to disrupt things or mainly self-contained), and a set of tasks that describe any downstream work that is dependent on the route chosen.
What Claude does next then depends on the results of a tiny optimization program that tries to maximize the expectation value of agent productivity per unit resource (tokens, time, etc.) conditional on how long it will take me to answer the question (e.g., if Claude has a question for me at 1 AM, there probably won't be a response for another 6-7 hours).
"Agent productivity" is of course a bit nebulous, consisting of a somewhat ad-hoc amalgamation of factors, but in general Claude's actionability loosely corresponds to cases like:
- 2-3 possible routes, each with roughly equal probability of being the one I select, low resource costs, minimal risk of instability, few downstream dependencies: implement each route in parallel
- 2-3 possible routes, one with a much higher probability of being chosen, minimal risk of instability, many downstream dependencies: implement just the top route
- Hundreds of possible routes: block until user response
- 1 possible route, high risk of instability, many downstream dependencies: block until user response
Generally speaking, there should be an active queue at all times and agents should be working on anything that's not blocked in the queue with maximal parallelization.
Some Github issues claim that adding
to ~/.claude/settings.json fixes it. This is plausible, but not documented anywhere (the source claims it was found by reverse engineering, and might break /goal).[1]: https://xcancel.com/bcherny/status/2017742743125299476#m