fix(memory): scale honcho_reasoning tier with prompt complexity (#59470)

[SquabbyZ]

Fixes #59470

Problem

The honcho_reasoning tool used to forward whatever reasoning_level
the calling model chose, including minimal. Honcho's minimal dialectic
tier hard-caps output at 250 tokens (MAX_OUTPUT_TOKENS=250,
MAX_TOOL_ITERATIONS=1). On reasoning-capable backend models (OpenAI
gpt-5.x / o-series and similar) that 250-token budget is shared between
hidden reasoning tokens and visible output — so a multi-fact prompt that
needed real synthesis would exhaust the budget mid chain-of-thought and
return no synthesized answer.

The minimal framing in the tool description read as "fast/cheap" —
a normal quality dial — rather than "hard output cap that can
truncate before answering". So the model reliably picked minimal for
queries that weren't suited to it.

Fix

Add a deterministic complexity heuristic in
plugins/memory/honcho/__init__.py and route every honcho_reasoning
tool call through it:

• Classifier (_classify_query_complexity) — counts sentences,
  clause separators (;/commas), numbered-list markers, and distinct
  content tokens (after stopword removal) to bucket the prompt into
  simple / moderate / complex.
• Selector (_select_reasoning_level) — maps the bucket to a tier
  (minimal / medium / high), honors an explicit caller override
  unless it would fall below the complexity floor (so minimal on a
  complex query is bumped to high), and clamps everything to the
  configured reasoningLevelCap.
• Wired into handle_tool_call("honcho_reasoning", ...) so every
  explicit tool call now benefits. The existing
  _apply_reasoning_heuristic for the auto-injected dialectic is left
  untouched — it still scales by query length for the implicit cadence
  path.

This is a heuristic, not an LLM classifier, matching the issue's
expected behavior.

Tests

tests/plugins/test_honcho_tier_selection.py — 30 tests covering:

• classifier behavior on empty / whitespace / single-sentence /
  multi-sentence / numbered-list / semicolon / comma-separated inputs,
  distinct-topic counting, and stopword handling,
• tier selection with and without explicit caller override,
• cap clamping and invalid-input handling,
• end-to-end through handle_tool_call, including a regression for
  [Bug]: honcho_reasoning picks Honcho's minimal reasoning tier for multi-fact queries → answers cut off at the 250-token combined budget #59470's "model picks minimal for a multi-fact query" scenario
  (asserts the call ends up at high, not minimal).

All 30 tests pass: pytest tests/plugins/test_honcho_tier_selection.py.

Relationship to existing PR #52395

That PR rewrites the tool-level description of honcho_reasoning
and the other tools. It does not touch the reasoning_level
parameter description or add runtime tier selection, so it's orthogonal.
This fix is at the handler level — the model can still see whatever
description we give it, but even if it picks minimal for a complex
query, the runtime promotes the tier so Honcho's hard cap can't
silently truncate the answer.

Environment

Verified locally on Windows / Python 3.11 against a self-hosted Honcho
backend (the same reproduction as #59470).

AI-assisted fix by https://github.com/SquabbyZ/peaks-loop

[alt-glitch]

This was generated by AI during triage.

Competing with #59472 for the same issue #59470. Different mechanism: this PR adds a deterministic complexity heuristic that auto-bumps a minimal tier up to a complexity floor (logic change), while #59472 (canonical, earlier) steers the model away from minimal via the schema description string only. Related, not a duplicate — flagging the cluster for a maintainer to pick.

[teknium1]

Thanks for targeting a real current-main path: plugins/memory/honcho/__init__.py:1352-1362 still forwards a model-selected reasoning_level unchanged.

Problems

• plugins/memory/honcho/__init__.py:1050 accepts default, but the no-explicit return at :1087-1089 never uses it. With dialecticDynamic=true, an omitted level on a simple query becomes minimal, replacing the configured dialecticReasoningLevel; current schema text says omission uses that configured default (plugins/memory/honcho/__init__.py:110-112).
• The explicit branch at plugins/memory/honcho/__init__.py:1081-1084 also clamps max to reasoningLevelCap. Current docs define that cap for automatic reasoningHeuristic scaling, while dialecticDynamic allows per-call model overrides (plugins/memory/honcho/README.md:266-269). The new test at tests/plugins/test_honcho_tier_selection.py:302-314 codifies the regression.

Suggested changes

• Preserve None for omission, or use the configured default as the selector base without lowering it; add coverage with dialecticReasoningLevel=high.
• Floor explicit low/minimal choices for complex prompts without capping higher explicit choices under the auto-heuristic cap.

Automated hermes-sweeper review.

[teknium1]

default is validated above but never participates in selection. This makes an omitted level on a simple query become minimal; with dialecticDynamic=true, the session manager will honor that value instead of the configured dialecticReasoningLevel. Preserve None for omission or use default as the non-explicit base.

[teknium1]

This newly caps explicit higher choices such as max. Current Honcho documentation defines reasoningLevelCap as the ceiling for automatic reasoningHeuristic scaling, while dialecticDynamic permits per-call overrides. Do not apply this cap to explicit choices unless that public contract is deliberately changed and documented.

[teknium1]

Closing after review against current main (post #62290 + #66052).

The issue you targeted (#59470 — minimal tier truncating multi-fact answers at Honcho's 250-token cap) was real, and your diagnosis was right. It's now fixed on main via #66052, which merged the guidance-side approach from #59472: the reasoning_level parameter guide explicitly warns about the 250-token cap and steers multi-fact queries to low+.

We went with guidance over enforcement deliberately: overriding an explicit reasoning_level the model chose with a keyword-counting heuristic falls into a pattern we consistently decline — second-guessing explicit choices with heuristics. When the model picks wrong, we fix the information it picks with, not silently rewrite its choice.

Appreciate the thorough test coverage in this one — the diagnosis helped confirm the issue was worth fixing. Thanks @SquabbyZ!