- risk
- (a) If the empty outputs come from a harness or tool-loop problem rather than truncation or budget exhaustion, formatRepair may not rescue them and the gain shrinks. (b) The date_calc negative-days behavior is unverified, so the protocol includes a fallback to a net offset computed with the calculator. (c) The ~800 extra system characters apply to every task and cost a small number of tokens, plus a possible small shift on non-tool tasks. (d) Eight tool calls plus one retry can raise tokens on …
- title
- Tool-use routing protocol with output headroom, bounded tool retries and conditional format repair
- hypothesis
- Both visible tool_use failures end with an empty output tail and no final line. That points to a termination failure (the 700-token ceiling, the 4-call tool budget, or a turn that ends on a tool call) more than to wrong arithmetic. I cannot see traces, so this is an inference. Three changes target it: more output headroom, tool-call headroom, and formatRepair, which fires only when the required final line is missing. A short generic protocol routes exact-computation families to the right built-in tool. Together these should recover most of the lost tool_use points without adding planner, self-evaluation or self-consistency calls.
- change Summary
- Two files changed, about 25 lines in total.
1) entity/config.json:
- model.maxOutputTokens 700 -> 1400. This is a ceiling, not a target.
- model.temperature 0.7 -> 0.3. Critique pointed out that 0.2 might hurt the JSON/constraint tasks, so this is a milder drop.
- tools.enabled -> ["calculator","date_calc","text_inspect"]. No run_javascript and no skills, since no sandbox is available.
- tools.maxToolCalls 4 -> 8.
- errorRecovery.toolRetries 0 -> 1.
- errorRecovery.formatRepair false -> true.
- Unchanged: strategy=direct, selfConsistencySamples=1, planner off, selfEvaluation off, memory settings.
2) entity/system.md: keep the existing two lines and append a compact protocol of about 800 characters. It has no task-specific values and no output-format literals, and it says nothing about an ANSWER line, because the harness supplies that instruction. Content:
"Exact-computation protocol. When a task needs exact arithmetic, dates or character counts, use a tool instead of mental calculation, and always finish by stating your final answer in the format the task requests.
- Large integers and modular exponentiation: call calculator with one expression using ^ and %, such as (a^b) % m, with every number copied digit for digit as given. Do not round, abbreviate or split the exponent by hand.
- Calendar steps: use date_calc. Apply the steps in order and feed each returned date into the …
- expected Effect
- Mechanism: output headroom, call headroom and formatRepair remove the empty-tail failure, and the routing text prevents hand arithmetic on 17-digit numbers, modular exponentiation and weekday work. Estimate: dev tool_use 66.7 moves to roughly 85-100, and hidden tool_use 78.1 moves to the mid or high 80s. That is about +1.5 to +2.5 capability points, which is uncertain. Experiment #2 gave Δ=1.84 with CI [-1.60, 5.49], so a gain of this size may again fail to reach significance; I am not claiming…
- changes From Critique
- Accepted:
- GPT and Gemini: the protocol text was truncated and needed completing, so it is now written out in full.
- GPT: sequential date steps can be uneconomical, so the protocol now allows computing a net offset with the calculator and applying it once.
- Grok and GPT: the negative-days API assumption is unverified, so I added an explicit fallback.
- Grok: temperature 0.2 could cost reliability, so I used 0.3 rather than 0.2.
- Grok: ~900 characters is a cost on every task, so I trimmed the protocol to about 800 characters and told the agent to keep reasoning brief.
- GPT, Grok and Gemini: the failure mechanism and the projected gains are unproven, so the hypothesis and effect estimate are labelled as inference.
Rejected:
- Gemini's concern that tool_use-only targeting will repeat ex…