How I Batch My AI Prompts So I'm Not Paying to Re-Read the Same Context Six Times
The hands-on version of the single-prompt batching rule: the exact prompt shapes I use, the CLI flags and system-prompt guardrails I set so an agent stops mid-batch and asks instead of guessing, and the failure I hit before I learned this the hard way.
How should I actually structure a batched prompt instead of asking one question at a time?
Short answer from twenty years of paying for compute one way or another: number every sub-question, put them in one message, and tell the model explicitly it may answer them out of order if that's more coherent. Here's the exact shape I use for a real multi-part ask against a codebase:
Looking at the auth module in src/auth/:
1. Does the refresh-token rotation handle a race between two concurrent
refresh calls from the same client?
2. Is there a test that exercises that race today? If not, what would it
look like?
3. Should the fix live in the token store or the middleware layer?
Answer all three against the same read of the code -- don't re-derive
context between them.
That last line matters more than it looks. Without it, some agents will still process each numbered item as if it were its own mini-task and re-verify assumptions three times. Say it explicitly the first few times until the pattern is established in your own working style.
What actually goes wrong if I send my questions one at a time instead?
I found this out the expensive way on a client engagement: I was debugging a Hyper-V cluster failover issue and firing questions at an agent session one at a time as they occurred to me -- "check the event log," then five minutes later "now check the cluster validation report," then "now compare against the last known-good config." Every single one of those messages paid the full cost of re-loading the surrounding context: the repo state, the prior exchange, the constraints I'd already stated. Three questions, three full context loads, and the agent lost the thread between question 1 and question 3 because nothing forced it to hold all three in view at once. When I went back and re-ran the same three questions as one batched prompt, the agent caught something it had missed the first time: question 1 and question 3 were pointing at the same root cause. That correlation is only visible when all three questions sit in the model's attention at the same moment, in the same pass -- which is exactly what a single batched prompt buys you and three serial ones do not.
What CLI/config setting do I use to make an agent stop and ask instead of guessing mid-batch?
This is the part most people skip and then get burned by: batching six questions into one prompt is not permission for the agent to silently guess on the one it's unsure about. I set an explicit escape hatch in the system prompt or CLAUDE.md-equivalent instruction file:
When a batched question can't be answered with confidence from what's
in context, don't guess -- state which numbered item is blocked and what
single piece of information would resolve it, then answer the rest of
the batch normally.
Concretely, in a Claude Code session this looks like an instruction block in CLAUDE.md or AGENTS.md (not a CLI flag -- there isn't one for this, it's a prompting discipline, and treating it as a config toggle is the mistake I made the first few times). The failure mode I hit before I learned this: I batched five questions, the agent had high confidence on four and fabricated a plausible-sounding but wrong answer on the fifth rather than flagging it, and I shipped a change based on that wrong answer. The fix isn't fewer questions per batch -- it's making "I don't know, here's what would tell me" an explicitly sanctioned response inside the batch, not a fallback the agent has to invent for itself.
What's the actual cost/latency difference I've measured?
I don't have a controlled lab benchmark to cite here, but the practitioner pattern I've settled into after a lot of real sessions: on any task with more than two related sub-questions against the same context, one batched prompt consistently reads and processes the surrounding material once instead of once per question. If you're paying per-token or watching a session budget, that's the lever -- not model choice, not prompt wording tricks, just not paying for the same context load N times over N serial messages.
*Read the underlying mechanism -- why one batched prompt is cheaper and more coherent than six serial ones -- in the companion piece on danstolts.com: [Why should I send all my questions in one prompt instead of one at a time?](https://danstolts.com/writing/why-should-i-send-all-my-questions-in-one-prompt/)*