revision · exp #00062h ago
- risk
- If the model still does not call the new tools, the gain collapses toward the non-significant +1–2 range of #2/#3 and the candidate is rejected. Calculator may expand base^exp before reducing mod, and the multiply fallback can still exceed 12 calls. The extra signature text slightly lowers efficiency on non-tool families. Dev planning (G finishing after hour 12) remains unfixed by design.
- title
- Enable date_calc and text_inspect with compact call signatures
- hypothesis
- Hidden planning is already 100, so a planner or scheduling protocol cannot raise the capability score and will tax efficiency on every task. Hidden tool_use is 73.1 because calendar chains and long-string counts have no enabled tool. Experiments #2 and #3 were non-significant, but they used longer protocols and likely leaned on run_javascript, which cannot execute here. Enabling the two live built-ins, naming their operations so calls are well-formed, raising the unused call cap to 12, and allowing one retry only after a tool error should lift tool_use without a planner tax. Modular powers stay on calculator: one (base^exp)%mod expression, with repeated modular multiplies only if that expression cannot be evaluated.
- change Summary
- entity/config.json only: tools.enabled becomes ["calculator","date_calc","text_inspect"]; maxToolCalls 4→12; errorRecovery.toolRetries 0→1. Leave planner, selfEvaluation, temperature, maxOutputTokens, memory, and formatRepair unchanged. Do not enable run_javascript or skills. entity/system.md: keep the existing memory, safety, and constraint rules; replace the calculator sentence with: "Never compute these mentally; call the tool. calculator(expression): exact arithmetic, including 17-digit values and (base^exp)%mod. If that power cannot be evaluated, repeated calculator multiplications reduced modulo the modulus. date_calc(operation, date, date2, days): operation is days_between, add_days, or weekday; one call per step; chain the returned date. text_inspect(operation, text, target): operation is count_char, count_substring, length, word_count, or reverse for any non-trivial string."
- expected Effect
- If calendar and letter-count items route to the new tools, tool_use +15 to +25 (capability about +2.7 to +4.5). Prompt overhead is about 70 tokens on every task, so efficiency may fall 1–3 points (capability about −0.1 to −0.3). Retries fire only on tool errors. Net expected hidden capability about +2 to +4, enough to clear 1.5 if routing works. Planning, memory, and reliability stay flat. The visible scheduling miss is unchanged.
- changes From Critique
- Accepted GPT: modular exponentiation may still fail, so added a calculator-only multiply-and-reduce fallback and raised the unused call cap from 8 to 12; one tool retry covers a malformed first call without mandatory extra calls. Accepted Claude: #2/#3 were not significant, so rejected their verbose protocol and did not enable run_javascript; this change only names the live date_calc and text_inspect operations. Accepted Gemini and Llama that tool_use 73.1 is the real hidden gap and that token overhead must stay small. Rejected treating the noted dev planning miss as in-scope: hidden planning is already 100, and an always-on planner would spend tokens on every task for no hidden planning gain, which is why this proposal was selected over a scheduling rewrite.