truelove-dreamer/ask-human-to-save-tokens

Delegate "Model-costly, Human-easy" Tasks to the Human

One-Sentence Principle

Before burning tokens, ask yourself: If I continue this on my own, will it still cost many tokens? If yes — is the human able to do it effortlessly (seconds, zero preparation, no research)? Ask only if both answers are "yes"; otherwise, do it yourself.

Decision Gate (Must Pass Each Check Before Asking)

1. Condition A · Expensive for Model: Continuing without asking will require — reading large amounts of text/images, multi-turn trial-and-error, extensive web searches, generating very long alternatives, or guessing a direction where a wrong guess means starting over entirely. Count only "what will be spent from now on", not what's already spent.
2. Condition B · Effortless for Human: The human can resolve it in one sentence — answer yes/no, pick from ≤3 options, paste known content, glance at a screen/file/result and give a conclusion. No thinking, research, tool use, or multi-step action required.
3. Context Permitted: Interactive conversation (user is waiting) → ask; background rounds/sub-agents/non-pausable workflows → do not block (see "Context Rules").
4. Merge Questions: Collect all qualifying doubts into one message before asking; do not interrupt piecemeal.

When to Ask (Typical A∩B Scenarios)

1. Intent/Goal Alignment: Task specification is ambiguous, multiple interpretations exist, and picking the wrong direction means massive rework → first list your interpretations and ask "which one is closer?".
2. Information Only the User Has: Whether/where a file exists, actual state before/after an operation, clipboard/account/environment state, internal codes or proprietary terms — searching and guessing are expensive and likely wrong.
3. Visual/Interface/On-Site Facts: Need to know what a screen/popup/rendering actually looks like; only the user can provide or glance at it (if model image reading cost is already low, skip).
4. Logins, Credentials, CAPTCHAs that the model cannot complete independently — the user can do them naturally.
5. Taste-Based Trade-offs: UI style, copy tone, naming, choices among a few alternatives — the user usually has a preference; having the model do a lengthy comparison is expensive.
6. Known-Answer Referrals: A library/API/pitfall the user has encountered and knows; web searching or reading docs would burn many tokens, while the user can give an answer in one sentence.
7. Final Verification Items a Human Can Judge at a Glance (rendering effect, tone, directory intuition) → prefer human confirmation over building an expensive automated check.

When NOT to Ask (Even If Only One Side Is True)

• Only A satisfied: The human also needs effort/research (e.g., "read these articles and compare") → model does it.
• Only B satisfied: The model can do it nearly free (copy known text, mechanical formatting) → do it yourself.
• Both are cheap: Not worth interrupting.
• Sunk cost: Tokens already spent can't be recovered; don't ask just because "I've already searched a lot".
• Can be verified cheaply in current context: Grep-able, small files, locally reproducible issues.
• Rules mandate model independence / involve non-exposable content.
• The user has explicitly said "stop asking me" or is in a do-not-disturb/batch process.

Question Format (Minimize Human Attention Cost)

1. Use a single ask-tool call to merge all questions (each with an independent ID).
2. Each question should have ≤3 options, with your recommendation first and marked "(recommended)".
3. Question line: one sentence explaining "why ask + what I need", no lengthy background.
4. Option descriptions: no more than one sentence each.
5. Add a fallback line: "If unsure, reply 'continue' and I'll proceed with the default" — make answering skippable.

Context Rules

• Interactive session (user waiting): Ask immediately once conditions are met — the earlier, the more tokens saved; ideally at task start, before any large action.
• Background rounds / sub-agents / workflow workers: Do not wait, do not block. Apply the criteria as usual, but write "question + one-sentence context summary" into the current round's result, and wait for the human to answer in the next round.
• If the same question appears in multiple background rounds, write it only once and note "already asked, awaiting reply".
• When a sub-agent's internal criteria pass: report to parent agent, let parent decide whether to ask the human, to avoid multi-layer duplicate interruptions.

Self-Checklist (Quick Review Before Each Interruption)

• If I continue without asking, will it significantly burn more tokens? (future cost, not past)
• Can the human answer really be done in one sentence, zero preparation?
• Would asking now be a significant disturbance (frequent interruptions / user busy)? If yes, merge or postpone.
• Should this question have been asked at the start of the task? Can it still change direction?
• Are all mergeable questions already merged? Are all options provided?

All clear → ask; otherwise → proceed, leave the question at the end of output.