Loadbudget What Claude Code adds
AGENTS.md holds the rules that bind every agent that works here, and the
import below loads it. This file holds what only Claude Code can obey: a hook, a
tool, and the line that ends a background session.
Binds: code, process
@AGENTS.md
A commit and a push run in the background
Run just send --push in the session. AGENTS.md, section “git commit and
git push run the checks”, states the command.
A commit and a push can each take many minutes. Run each one with
run_in_background, and wait for its notification. Do not poll it with a loop
of pgrep -f. That pattern matches the command line of the loop itself, so the
loop never ends.
A question goes through the AskUserQuestion tool
Agent view lists a session that waits on a question it asked, or on a permission
decision, as Needs input. It lists a session that finished its turn as done.
A question in the text of a message leaves the operator to find it.
Do not end a message with a question, an offer such as “want me to…?”, or a list of options in prose. Ask with the AskUserQuestion tool, one question at a time.
A pick approves the choice that its label names, and nothing more. An option description carries no extra work. Name a follow-up apart, with its cost, and start it only on a request.
Auto memory holds no rule
Claude Code keeps its auto memory in the home directory of one account.
autoMemoryEnabled in .claude/settings.json turns it off for this repository.
AGENTS.md, section “A session writes its own files in .scratch/”, sends a
rule from the operator to its page instead.
The pull request watch runs under the Monitor tool
A PostToolUse hook answers each gh pr create. The hook tells the session to
start just lb pr watch <n> under the Monitor tool. Where a session opens a
pull request another way, it starts the same watch without the hook. When the
Monitor stops the watch, start it again. AGENTS.md, section “A session watches
its pull request until the merge”, states how to answer each line.
Work for another machine goes to a session on its bridge
A task that needs another machine goes to a session there. A recipe that needs a
Mac is such a task. infra/docs/usage/CROSS_HOST_HANDOFFS.md states how a
session starts it and reads its reply.
Each subagent call names the model that its task needs
A subagent with no model runs on the model of the session. Explore and Plan do the same. So an Opus session spends Opus on every search. Parallel subagents then reach the session limit of the account.
The Agent tool takes a model for each call, and that value comes first. Name
it on every call:
haikufor a search, a read, a count or a label over a fixed list.sonnetfor an edit that a plan already states, or a review of one file.opusfor a design, a diagnosis with no known cause, or a change across modules.
Give a haiku subagent its inputs as a list of paths, and an exact shape for
its answer. Tell it to copy evidence character for character. Then check its
answer against its inputs, because it can read the wrong file or paraphrase a
quote.
A subagent gets no task that waits on a long command
A subagent keeps its prompt cache for 5 minutes. The session keeps its cache for 1 hour. Each usage record of a transcript names the lifetime of each cache write.
So a wait of more than 5 minutes makes the subagent write its whole context again. A subagent that edited many files carries a large context, and it writes all of it again after each such wait.
Do not give a subagent a task that holds such a wait. A UI test run, a
screenshot run and a build of the app are such waits. Give the subagent the
edit. Then run the long command in the session, with run_in_background.