Thanks for the context here. I did a careful shell check against current main, and this is already implemented.

Current main already implements the central isolated-cron result-level fallback fix through the merged reliability batch, with wiring coverage in the existing cron fallback tests; this branch is now redundant even though the latest stable release still lacks the fix.

Root-cause cluster
Relationship: superseded
Canonical: #100483
Summary: The current PR and related candidates target the isolated cron embedded result-level fallback classifier gap; the merged reliability batch is now the canonical implementation on main.

Members:

• canonical: fix: land ten small reliability fixes #100483 - Merged commit aaf5ab9 landed the cron classifier/merge wiring and tests on current main.
• fixed_by_candidate: [Bug]: isolated cron model-fallback chain never engages on result-level failures (reasoning-only / empty / incomplete_turn), silently dropping the answer #96525 - The open issue describes the same isolated cron embedded result-level fallback gap that the merged PR fixes on current main.
• superseded: fix #97115: classify isolated cron fallback results #99913 - That closed source PR was explicitly incorporated into the merged reliability batch.
• same_root_cause: fix(cron): retry fallback on empty embedded cron results #99911 - It is another open candidate for the same cron classifier wiring gap, with an added CLI guard.
• partial_overlap: [Bug]: Z.AI Coding-Plan: ECONNRESET triggers model fallback — fallback notice is invisible to the user in async contexts (cron jobs, sub-agents, isolated runs) #94919 - It covers async fallback visibility/provider policy more broadly, not only the returned-result cron classifier gap.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Real-world reproduction confirming this gap. We're running OpenClaw 2026.6.10 with a local llama-server (Qwen3-8B Q5_K_M) as primary and deepseek/deepseek-v4-pro as fallback.

Our exact failure pattern:

1. Isolated cron agentTurn session starts (wa-revision-request-check, every 5 min)
2. Session loads bootstrap, calls llama-server for the initial response
3. llama-server returns content="" with reasoning_content populated (Qwen3-8B build b9638 thinking-mode leak — the model outputs reasoning tokens, the primary response is empty)
4. The gateway receives this empty result, classifies it as an incomplete turn, and logs "Agent couldn't generate a response. Note: some tool actions may have already been executed"
5. The cron reports lastRunStatus: ok, lastDurationMs: ~100s, lastDiagnosticSummary: "⚠️ Agent couldn't generate a response... verify before retrying"
6. The fallback model (DeepSeek) is never called despite being configured
7. The revision request remains stuck in status='processing' permanently
8. Subsequent cron runs return "already-running" — the stuck session blocks all future runs until a disable/enable cycle

Gateway log evidence:

14:45:00 [model-fetch] error provider=llama-server model=qwen3-8b elapsedMs=5767 name=AbortError
14:45:00 cron: cleaned up timed-out agent run
14:45:00 embedded run failover decision: stage=assistant decision=surface_error

The model_fallback_decision events show the gateway correctly caught the error at provider-fetch level, but the embedded result-level failure (empty content) was never routed through the fallback classifier — it went straight to "couldn't generate a response" with no fallback attempt.

Our workaround (not a fix): Added --reasoning off to llama-server. Now the model returns actual content, bypassing the empty-response problem entirely. But the underlying fallback gap remains — any other model that returns reasoning-only/empty/incomplete output would hit the same dead end without an operator noticing.

This PR would fix that gap. Happy to provide more logs or run a specific test if it helps with the proof the maintainers are requesting.

Added real-behavior proof: loopback real-HTTP transport reproduces the gap and verifies the fix end-to-end

Per the "needs real behavior proof from a real setup" gate — an end-to-end run where every layer is real production code: the real openai-completions transport, the real classifyEmbeddedAgentRunResultForModelFallback, and the real runWithModelFallback loop. The only injected piece is a loopback OpenAI-compatible model server, which is the only way to deterministically force the reasoning-only / empty-content primary response (the exact Qwen3 thinking-mode leak @nessim-liamani hit in production).

A — real transport: empty content + populated reasoning_content → empty visible text

[A] real-transport primary: {"text":"","thinking":"Let me think..."} serverHits: ["empty-primary-qwen"]

B — real classifier flags it as fallback-eligible

[B] classification: {"message":"Agent couldn't generate a response.","reason":"format","code":"incomplete_result","preserveResultOnExhaustion":true,"preserveResultPriority":0}

C — real runWithModelFallback over real HTTP, without vs with the classifier the cron path now passes

[C-before no classifier]  winnerModel: empty-primary-qwen  visible: (none)  serverHits: ["empty-primary-qwen"]
[C-after  with classifier] winnerModel: healthy-fallback   visible: Workspace cleaned up: removed 12 stale files.  serverHits: ["empty-primary-qwen","healthy-fallback"]

• before (= cron on main, which calls runWithModelFallback with no classifyResult): the loop treats the empty primary as success, the fallback model is never contacted (serverHits has only the primary), and no visible answer is produced.
• after (this PR wires classifyResult + mergeExhaustedResult): the loop advances to the configured fallback over real HTTP (serverHits now includes healthy-fallback) and delivers the real answer.

The cron run-executor wiring (embedded branch passes the classifier, CLI scoped out) is covered by the committed regression run.result-fallback-gap.test.ts, which drives the real runCronIsolatedAgentTurn. The incomplete_turn / fallbackSafe result shape in B/C is what the embedded runner already produces for this case — unchanged by this PR — and matches both #96525 and the production report below.

@nessim-liamani — thanks for the production confirmation, that's genuinely helpful. One precise note for maintainers reading the thread: the pasted log line (name=AbortError + cron: cleaned up timed-out agent run) is the timeout/abort path, which throws and is a sibling of — not identical to — the returned result-level failure this PR targets (empty content / reasoning_content, no throw). Your step 3 ("returns content:"" with reasoning_content populated … classified as an incomplete turn") is exactly the returned path this PR fixes. Both are real; flagging the distinction so the proof above is read against the right failure mode.

@clawsweeper re-review

The "needs real behavior proof from a real setup" item is now addressed: the PR body's new Real-behavior proof section (and the comment above) captures an end-to-end run over a loopback real-HTTP openai-completions transport — the real transport, the real classifyEmbeddedAgentRunResultForModelFallback, and the real runWithModelFallback loop. serverHits shows the configured fallback is never contacted without the classifier (cron on main) and is reached over real HTTP with it (this PR). Please re-evaluate the proof gate.

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Cross-checking #97115 against this PR: the returned-result part of #97115 appears covered here, and the timeout/abort part should stay separate from this landing decision.

Evidence I checked:

• Current main still calls runWithModelFallback from src/cron/isolated-agent/run-executor.ts without classifyResult / mergeExhaustedResult, while src/agents/model-fallback.ts only retries an ok returned result when a classifier returns a classification.
• The Bug: Cron fallback chain broken — models return zero-token success or killed by shared AbortController #97115 zero-token / empty-response slice maps to the existing embedded classifier's incomplete_turn, empty, and reasoning-only handling in src/agents/embedded-agent-runner/result-fallback-classifier.ts.
• PR head 3802123dffe3 wires that classifier and exhaustion merge helper into the cron fallback call, scopes the classifier away from CLI candidates with resolveCronExecutionProvider(...).isCli, and adds src/cron/isolated-agent/run.result-fallback-gap.test.ts coverage for reaching the configured fallback and skipping CLI classification.

So for maintainer triage, I would treat #97115's returned-result failure as a duplicate/partial duplicate of #96525 and keep this PR as the canonical fix. The separate "shared AbortController kills later fallbacks" claim in #97115 is a timeout/abort path and is not proven or covered by this PR.

ClawSweeper applied the proposed close for this PR.

• Action: closed this PR.
• Close reason: already implemented on main.
• Evidence: durable ClawSweeper review.

🦞👀
ClawSweeper could not autoclose this item.

Reason: structured ClawSweeper close marker: close-required (sha=4af4e70c22d0924a14e62194dc87e823b2b0d439)

Usage: /autoclose <maintainer close reason>. I will close this item and any open same-repo items explicitly referenced in the command text.