Qwen3 returns reasoning but no visible answer when its output cap runs out

For one fixed arithmetic task, raising max_tokens from 8 to 1,024 restored the visible answer while keeping thinking enabled. A 512-token proposal still failed.

Reasoning-token exhaustion: measured results

Qualified October 15, 2026 Pacific. A separate agent extracted the frozen input ZIP into a fresh directory and independently reproduced the complete fail/correct/revert sequence with its own server processes on the same physical Mac. Tested configuration: llama.cpp 0.6.0 build 11429 (d81235049), the pinned Qwen3-4B Q4_K_M artifact, macOS 26.3 arm64 and CPU inference.

The unchanged task asks for 19 + 23 and requires exactly 42 in the visible answer. Thinking remains enabled throughout. With max_tokens: 8, the server returns HTTP 200, nonempty reasoning_content, empty visible content, finish_reason length, and eight total completion tokens. The small cap runs out before a visible answer.

The proposed 512-token correction also failed in all three author checks: it returned empty visible content and length after 512 completion tokens. Those failures and their original source files remain in the distribution. They were never counted as repaired tasks.

Revision 2 changes only the proposed corrected cap to 1024. The prompt, model, temperature 0, seed 42, thinking on, reasoning-format deepseek, unrestricted reasoning budget, 2048 context and exact-answer checker stay unchanged. The 27-token rendered input plus 1,024-token output reserve totals 1,051, within the allocated 2,048 context.

Every successful author and independent response returns exactly 42, finishes with stop, retains nonempty reasoning, uses 698 total completion tokens and 27 prompt tokens, and reports zero cached tokens. Baseline reasoning text is a prefix of the corrected reasoning in all three author checks. The API reports total completion usage. The precise reasoning-versus-answer token split is unknown.

The first author invocation stopped during a local-port preflight before any server process/model request. Its environment and failure record are retained at evidence/author-run-001. The complete failed 512 qualification is evidence/author-run-002 with matching original files in evidence/qualification-v1-source. The passing author run is evidence/author-run-003, using 18089.

Reproduce or inspect offline

README.md gives the fresh-inference command. From this extracted distribution, inspect the independent receipts without loading a model:

python3 evidence/independent-audit.py \
  --archive evidence/verifier-input.zip \
  --package . \
  --results evidence/independent-run-001 \
  --port 18088 \
  --out /tmp/kingy-fix-003-offline-audit.json

The unchanged frozen seven-file input remains at evidence/verifier-input.zip. INDEPENDENT-VERIFICATION.md records its hash, fresh extraction, own server processes and offline rejection controls. Distribution files are covered by SHA256SUMS and an outer archive receipt.

Limits

This is a bounded local analogue of the public report in discussion #20931, whose model digest/runtime build were unspecified. The original reported hardware/model are not recreated. The 1024-token cap was selected during qualification; this is not a held-out evaluation or universal minimum. It restores this exact task at temperature 0 and does not establish optimal production sampling, general reasoning quality, latency gains or correctness of every intermediate reasoning statement. Longer tasks can still exhaust the cap.

Independent execution was by a separate agent on the same physical Mac, not a human or second machine. Artifact hashes, complete requests, rendered input/token IDs, usage, stop reasons, cache counters and all attempts remain inspectable. No model/runtime was installed or downloaded, no paid API was called, and production was not changed. Local path redactions do not alter task inputs, answers or token counts.

Read the repair steps in Fix Finder →