llama.cpp returns a tool call but the client shows an empty answer

A single-request reference client displayed empty message.content after a valid tool call. Supplying the validated tool result and making the next request completed the answer.

Qualified 2026-10-16 Pacific · Same-agent local repeatability

Qualified 2026-10-16 Pacific on llama.cpp 0.6.0 build 11429 (d81235049), Qwen3-4B Q4_K_M; exact artifact SHA-256 in the package.

Apple M4 Pro, 24 GiB unified memory, macOS 26.3; CPU only, two threads, one slot, 2048-token context; loopback/offline.

For each repair, the same agent completed two seven-trial sequences in fresh server processes on the same Mac. Unchanged passing case runs were reused; the evidence index identifies them.

Same-agent repeatability checks on one Mac; no independent operator, second machine or human acceptance test.

Download full evidence cohort

412,621 bytes

SHA-256: 8a3e0d0b0f217f30e583450c7073dd1558ce75b9bb8f0e3e8f348e6260a28b93

Observed symptom

The response succeeds with finish_reason=tool_calls and valid function arguments, but a client that displays only message.content shows no final answer.

Correction

Handle the returned tool call in the client: validate it, perform the explicitly allowed operation, append its result with the actual tool_call_id and request the final assistant response.

  1. Check finish_reason and tool_calls before treating empty content as a failed model answer.
  2. Validate the tool name and original arguments before invoking any operation. The package permits only the owned lookup_stock fixture.
  3. Supply the synthetic stock result once using the exact call ID returned by the model.
  4. Append the assistant call and tool result to the conversation, then make the final request. The tested final request uses tool_choice=none.
  5. Require the exact answer Stock for KINGY-017: 37. and finish_reason=stop. For real tools, implement appropriate permissions and duplicate-execution protection.

Results

In each of two fresh-process runs: 0/3 baseline task passes, 3/3 corrected passes and 0/1 reverted passes. All original task checks and scoped completion checks passed. The offline audit recomputed acceptance from raw responses and rejected six damaged corrected-response controls.

Failed attempts and controls

The single-request client received a complete valid stock lookup but had no visible final answer because it never supplied a tool result.

Limits

Same-agent repeatability checks on one Mac; no independent operator, second machine or human acceptance test.

Fixed synthetic tasks selected after exploration. The repeat counts do not establish a general reliability rate or support for other models and builds.

Runtime binaries and model weights are excluded. Exploratory failures, the failed first qualification fixture and all final trial responses are retained.

Client demonstrations identify owned reference integrations and injected inputs explicitly; they are not claims of a repaired Open WebUI release or a general llama.cpp bug fix.

The failing client is an owned single-request reference integration. The server correctly returned a tool request; no runtime defect is alleged.

This differs from repair 001, where explicit --no-jinja caused the server to reject the initial request. Here Jinja is enabled and that request succeeds.

Only the harmless fixed inventory result is supplied. The reproduction executes no generated commands, purchases, web search or external tools.

Evidence

The ZIP includes exact requests, raw responses, the indexed complete case runs, failed initial attempts, frozen runner/client code, the offline audit, all file checksums and the selection record. It contains no model weights or runtime binary.

Primary protocol or upstream reference. The current result above is limited to the identified artifacts and fixture.

Read this repair in Fix Finder →