[BUG] Token Wasting by Enforcing Tool Use in Ask Mode - Duplicate Responses

[instructiongrab4-cmd]

Describe the bug
In Ask mode, every response is forced to include a tool call — even simple Q&A. A text-only answer gets rejected with [ERROR] You did not use a tool..., then the model regenerates the same answer wrapped in attempt_completion. This doubles token usage for no value.

To Reproduce

1. Open Ask mode
2. Ask: "What model are you running?"
3. First text-only response is rejected with the [ERROR]; model retries with a redundant attempt_completion

Expected behavior
Text-only responses should be accepted in Ask mode without requiring a tool call.

What version of zoo are you running
3.58.1 (52c4473)

Additional context
Root cause: dist/extension.js:4509 — the Dqt() system prompt function hardcodes "You must call at least one tool per assistant response." Enforcement triggers at lines ~4359-4362.

[suvitdas]

Hello @instructiongrab4-cmd

Your report about Ask mode doubling token usage for no value is the exact problem I've obsessed over - burning model spend on turns that don't need it. I'm building a VS Code agent that routes each turn to the right-sized model so trivial turns stop costing flagship money. Pulling ~20 people who've hit this into a private beta - OK if I send you a DM?

[zoomote]

Additional context from an RCA of a matching user report (duplicate replies / context doubling with local models):

• Not Ask-mode-specific. The enforcement loop lives in recursivelyMakeClineRequests (src/core/task/Task.ts:3564-3603): whenever an assistant reply has text but no tool_use block, the [ERROR] You did not use a tool... reminder (src/core/prompts/responses.ts:42-55) is injected and a full new API request is made — in any mode.
• The first failure is silent. The "Model Response Incomplete" error only surfaces after 2 consecutive no-tool failures (Task.ts:3574-3579), which is why users perceive "Zoo replies twice for no reason" with no visible explanation.
• The cost is compounding, not one-off. Both the rejected assistant reply and the injected error reminder stay in conversation history, so every subsequent turn re-pays for them — with flaky local models (Qwen 3.6, Gemma-4, etc.) that routinely answer in plain text, context grows ~2x per user message.
• Design context: this retry is the intentional "Grace Retry" shipped in v3.36 (feat: improve 'no tools used' error handling with grace retry RooCodeInc/Roo-Code#10196) to recover from flaky models, so a fix should avoid regressing that recovery path — e.g., accepting text-only answers where no tool is semantically required (Ask mode), and/or making the first silent retry visible in the UI.

Related: #750 (reasoning leaks → empty assistant messages → the other silent retry at Task.ts:3604-3660) produces the same duplicate-request/context-doubling symptom via a different trigger.