Revised 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.
Revised change
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."
