Why should I send all my questions in one prompt instead of one at a time?

Because the master orchestrator—your main session chat—can see the whole working context in one call in the current live conversation. Put new questions, your responses to earlier answers, and the next work in one organized message. This is not a new chat started on top of prior discussion context. Six items are a useful normal example, not a limit. The orchestrator can see how the items connect and route the work from the same context instead of rebuilding it for tiny messages.

I am the prompt, and here is what actually happens to me

I am not just the words you typed. By the time I reach the model, I am your words plus everything the system had to load around them: instructions, relevant files, prior conversation, whatever context the task needs. That surrounding material is the expensive part, not my few sentences of actual ask. If you send me alone with one question, the system still has to assemble and process the whole surrounding context just to answer that one question. Send a second small message in the same live conversation, and it starts another call that may assemble and process that current context again. That is different from starting a new conversation: the master orchestrator is still your main session chat and sees the working state you give it there.

Here's the part that's easy to miss: the working set is not limited to new questions. It can include your responses to earlier answers, corrections, new tasks, and decisions. When that set reaches the master orchestrator in one organized prompt, the master orchestrator (your main session chat) sees the whole context at once and can understand which items connect, which need an answer, and which need routing. Six is a normal starting bundle; it is not a cap.

What "shift-enter" actually buys you

Most chat interfaces submit on Enter. Shift-Enter inserts a line break instead of sending. That's the whole mechanic, and it matters more than it looks: it lets you stack multiple numbered questions into a single message before you ever hit submit.

`` 1. What's causing the timeout on the nightly job? 2. Is the retry logic idempotent? 3. Should the retry count be configurable? 4. What's the safest default timeout value? 5. Does this affect the downstream reporting job? 6. What log line should I add to catch this earlier next time? ``

That's one prompt, not six, in the current live conversation. Add your response to an earlier answer or a new task to the same organized block. Do not start a new conversation and rely on earlier discussion context. The master orchestrator sees the complete working context and can reason about the work before answering or routing it. One message is not limited to two questions, or even six.

Numbered in, numbered out

Ask numbered questions and a well-behaved model will answer with matching numbers. That's not a cosmetic nicety -- it's a verification mechanic. A six-question numbered prompt that comes back with a five-item numbered answer is visibly, immediately incomplete. Nothing was silently dropped without you noticing, because the numbers don't line up and you can see it at a glance. Compare that to six separate serial exchanges: if the third one gets a vague or partial answer, there's no structural signal that anything went wrong. It just reads like a normal, if slightly weak, response.

The part you're paying for even when you can't see it

Here's the mechanism underneath the cost difference. A large share of any prompt's processing time and expense is proportional to how much context has to be read and processed before the model can generate anything at all. When a shared prefix -- your system instructions, a long document, earlier turns in the conversation -- repeats across consecutive prompts unchanged, well-run systems can reuse the already-processed version of that shared prefix instead of reprocessing it from scratch. That reuse only works, though, when the repeated material is genuinely the same and arrives close together -- which is exactly what one batched prompt guarantees and six independently timed serial prompts do not reliably guarantee, especially if anything shifts in between them.

The simple worked example is six 50-token items against a 100,000-token context. Without cache, six separate sends present 600,300 input tokens; one organized send presents 100,300. The point is not that six is special. It shows why a full working set—questions, responses, decisions, and next work—belongs in one call in the current live conversation, where the orchestrator sees it at once.

Where this breaks down

The exception is information that does not exist yet: a later human decision, an external result, or a newly discovered fact. Send the next call when that input exists. Do not split up the information you already have merely because one item follows another in the conversation; include the prior response and the next question in the same current live conversation—not in a new chat.

The guardrail is legibility, not artificial relatedness. Use headings, numbers, and clear asks so the master orchestrator can distinguish questions, responses, decisions, and tasks in a large working set. A long organized context is useful; an unstructured wall of text is not.

Tech-Tips

- Default to one current working context. Put questions, responses to earlier answers, decisions, and next tasks in the same organized call. - Six is an example, not a ceiling. Use shift-enter (or your tool's line-break key) to build the full working set before submitting. - Ask for numbered answers back, and check the numbers match. A missing number is your cheapest signal that something was skipped. - Use a new call only for a new fact. If a later decision or external result does not yet exist, add it when it does. - Keep the context structured. Headings and numbering let the master orchestrator route a large working set without forcing it into a false “related questions only” rule.

Evidence: this piece describes prompt-batching mechanics, prefix/context reuse behavior, and numbered-question verification discipline as practiced in our internal operations agent-session framework -- no vendor or specific model is named, per moat-protection and STORY-FORMAT conventions. Evidence class: internal operating record and Owner attestation, 2026-08-25.