fix(memos-local-plugin): add maxTokens to LlmSchema & SkillEvolverSchema

[chouti]

Problem

Reasoning models (e.g. deepseek-reasoner, o1*, gpt-5-thinking) consume hundreds of tokens on chain-of-thought before emitting JSON content. When llm.json reflection / skillEvolver.crystallize is called with the legacy hard-coded max_tokens: 1024, the response is truncated mid-JSON and the bridge logs llm.json malformed 73+ times in a single reflection cycle.

Result: episodes never close, recoveryReason: "dirty_reward_rescore" piles up, and the MemOS viewer reports bridge.status: disconnected even though the daemon is alive.

Reproduction

llm:
  provider: openai_compatible
  endpoint: https://api.deepseek.com/v1
  model: deepseek-reasoner       # or any reasoning model
  apiKey: sk-...
algorithm:
  lightweightMemory:
    enabled: false               # full self-evolution ON

Start bridge with no override of max_tokens. After ~1 episode:

[bridge] llm.json malformed at 2026-06-08T...Z (attempt 1)
[bridge] llm.json malformed at 2026-06-08T...Z (attempt 2)
... × 73

Direct curl confirms root cause: API returns finish_reason: "length" with truncated content.

Fix

Add maxTokens (default 4_000) to LlmSchema and SkillEvolverSchema. Reasonable budget for reasoning models while still clamping below OpenAI's 32k ceiling.

• LlmSchema.maxTokens: NumberInRange(4000, 1024, 32768)
• SkillEvolverSchema.maxTokens: NumberInRange(4000, 1024, 32768)
• Corresponding defaults in defaults.ts for old configs

TypeBox's Value.Default already preserves user-supplied fields, so the change is backward compatible — old configs without maxTokens get the 4_000 default; new configs can override.

Verification

Before patch:

• 73 malformed per reflection cycle
• bridge.status: disconnected

After patch (config unchanged, schema updated):

• 0 malformed across 141 episodes
• bridge.status: connected
• Viewer loads (200 OK)

Files changed

• apps/memos-local-plugin/core/config/schema.ts (+15 lines, 2 field defs)
• apps/memos-local-plugin/core/config/defaults.ts (+2 lines, 2 default values)

 apps/memos-local-plugin/core/config/defaults.ts |  2 ++
 apps/memos-local-plugin/core/config/schema.ts   | 15 +++++++++++++++
 2 files changed, 17 insertions(+)

[Memtensor-AI]

Automated Test Results: FAILED

Cloud test-engine rerun against dev-v2.0.22 failed.

• Run: tr-7d12f792-72f on cloud test-engine 10010

• Verdict: fail_code_bug

• Summary: Tests failed. Failed cases: test

• memos_local_plugin/unit: 0 passed, 1 failed, 0 skipped

• memos_local_plugin/smoke: 0 passed, 0 failed, 0 skipped

• memos_local_plugin/contract: 0 passed, 0 failed, 0 skipped

Failed cases:

• test: e}
  11:26:01.223 WARN [core.memory.l2.events] listener_threw kind="l2.candidate.added" err={name,message}
  11:26:05.033 WARN [core.skill.events] listener_threw kind="skill.archived" err={name,message}
  11:26:05.033 WARN [core.skill.events] listener_threw kind="skill.archived" err={name,message}
  11:26:06.675 WARN [core.retrieval.events] listener_threw kind="retrieval.started" err="bad listener"
  11:26:06.675 WARN [core.retrieval.events] listener_threw kind="retrieval.started" err="bad listener"

Do not merge until this is fixed and cloud tests pass.

[Memtensor-AI]

🤖 Open Code Review

Target: PR #1896
Task: c3f809a70b09c2e6
Base: main
Head: fix/llm-schema-add-max-tokens

✅ OpenCodeReview: No comments generated. Looks good to me.

Generated by cloud-assistant via Open Code Review.

[Memtensor-AI]

✅ Automated Test Results: PASSED

All tests passed (103/103 executed). memos_local_plugin/unit: 103/103. Duration: 13s [advisory, non-gating] AI-generated tests on branch test/auto-gen-c3f809a70b09c2e6-20260806195541: 77/78 passed, 1 failed — these do NOT affect the PR verdict; review the branch manually.

Branch: fix/llm-schema-add-max-tokens

[Hun-ger]

Thanks for addressing this issue. The truncation problem is still present on main, and the added runtime wiring tests for both shared and dedicated LLM clients are valuable.
Before merging, please reconsider the global 1024–32768 validation range. This is a provider-agnostic configuration, so a minimum of 1024 prevents legitimate smaller budgets, while the 32768 upper bound rejects models that support larger outputs. Please use a more permissive provider-neutral range, or only validate that the value is a positive integer.
Once the range and corresponding tests are updated, this should be ready for another review.