Qwen3.5 llama-cpp tool calling fails when function has "strict": true
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- go
- Área
- api, backend-api-design
Línea de trabajo
Comienza en el punto de entrada /v1/chat/completions y sigue cómo el backend llama-cpp gestiona las function tools con y sin strict: true. Reproduce las dos solicitudes del issue usando el modelo qwen3.5-9b-glm5.1-distill-v1 y verifica después que la solicitud strict devuelve una llamada a una herramienta en lugar de una respuesta vacía y un bucle de reintentos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
LocalAI version:
LocalAI version: v4.9.0
Commit:
f7ad3f70eb5d8a0ddf80e08557f0d7df28cf032e
Container image:
localai/localai:latest-gpu-nvidia-cuda-12
LocalAI is running as a Kubernetes deployment.
Environment, CPU architecture, OS, and Version:
LocalAI is running in Kubernetes.
Uname:
Linux k8scp 5.14.0-611.47.1.el9_7.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Apr 8 12:18:23 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
Model:
qwen3.5-9b-glm5.1-distill-v1
Model file:
Qwen3.5-9B-GLM5.1-Distill-v1-Q4_K_M.gguf
Backend:
llama-cpp
Effective runtime settings reported by LocalAI:
context=2048
n_batch=512
n_gpu_layers=0
parallel="1"
flash_attention="auto"
f16=false
The model is therefore running CPU-only for this reproduction
(n_gpu_layers=0).
CPU is an Intel Core i7-3770 @ 3.40 GHz.
Client testing was performed using the OpenAI-compatible
/v1/chat/completions endpoint.
The issue was originally discovered using OpenAI Agents Python SDK
0.22.0, but it can be reproduced independently of the Agents SDK
using a normal OpenAI-compatible Chat Completions request.
Describe the bug
OpenAI-compatible function/tool calling works with the
qwen3.5-9b-glm5.1-distill-v1 model using the llama-cpp backend, but
adding:
"strict": true
to the function definition causes tool calling to fail.
Without strict: true, the model correctly returns:
finish_reason: tool_calls
tool_calls: transfer_to_customer_retention_agent
With strict: true, the same request instead returns:
finish_reason: stop
content: ''
tool_calls: None
reasoning: None
LocalAI returns HTTP 200 in both cases.
The LocalAI logs show repeated:
Backend returned empty response, retrying
for the failing request.
This was initially noticed because OpenAI Agents SDK handoffs are
represented as strict function tools, which prevents native Agents SDK
handoffs from working with this LocalAI/model combination.
The issue can, however, be reproduced without using the Agents SDK.
To Reproduce
Use the following model:
qwen3.5-9b-glm5.1-distill-v1
with the llama-cpp backend.
1. Tool without strict: true - works
Send:
curl http://<LOCALAI_HOST>:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "qwen3.5-9b-glm5.1-distill-v1",
"messages": [
{
"role": "system",
"content": "You are a customer service agent. If the customer wants to close or cancel their account, you must call transfer_to_customer_retention_agent."
},
{
"role": "user",
"content": "I want to cancel my order and account. You delayed my order for the 3rd time!"
}
],
"tools": [
{
"type": "function",
"function": {
"name": "transfer_to_customer_retention_agent",
"description": "Transfer the conversation to the customer retention specialist.",
"parameters": {
"type": "object",
"properties": {},
"required": [],
"additionalProperties": false
}
}
}
],
"tool_choice": "auto",
"max_tokens": 1500,
"reasoning_effort": "none"
}'
This correctly results in an OpenAI-compatible tool call.
Using the OpenAI Python client, the relevant response is:
finish_reason: tool_calls
content: ''
tool_calls:
[
ChatCompletionMessageFunctionToolCall(
function=Function(
arguments='{}',
name='transfer_to_customer_retention_agent'
),
type='function'
)
]
2. Add only strict: true - fails
Repeat the same request but change the function definition to:
{
"type": "function",
"function": {
"name": "transfer_to_customer_retention_agent",
"description": "Transfer the conversation to the customer retention specialist.",
"parameters": {
"type": "object",
"properties": {},
"required": [],
"additionalProperties": false
},
"strict": true
}
}
The resulting response using the OpenAI Python client is:
ChatCompletion(
choices=[
Choice(
finish_reason='stop',
message=ChatCompletionMessage(
content='',
role='assistant',
function_call=None,
tool_calls=None
)
)
]
)
finish_reason: stop
content: ''
tool_calls: None
reasoning: None
Usage for one of the failing requests:
completion_tokens=19
prompt_tokens=63
total_tokens=82
Therefore the significant A/B difference appears to be:
Tool without "strict": true
|
+--> finish_reason = tool_calls
tool call generated successfully
Tool with "strict": true
|
+--> finish_reason = stop
content = ""
tool_calls = None
Expected behavior
Adding:
"strict": true
to an otherwise working OpenAI-compatible function definition should
not prevent the model from making the tool call.
I would expect a response equivalent to:
{
"finish_reason": "tool_calls",
"message": {
"tool_calls": [
{
"type": "function",
"function": {
"name": "transfer_to_customer_retention_agent",
"arguments": "{}"
}
}
]
}
}
The function arguments in this example already conform to the supplied
JSON schema.
Logs
LocalAI starts the model with:
INFO BackendLoader starting
modelID="qwen3.5-9b-glm5.1-distill-v1"
backend="llama-cpp"
model="llama-cpp/models/qwen3.5-9b-glm5.1-distill-v1/Qwen3.5-9B-GLM5.1-Distill-v1-Q4_K_M.gguf"
The effective runtime configuration is:
context=2048
n_batch=512
n_gpu_layers=0
parallel="1"
flash_attention="auto"
f16=false
During failing requests LocalAI repeatedly reports:
WARN Backend returned empty response, retrying attempt=1 maxRetries=5
WARN Backend returned empty response, retrying attempt=2 maxRetries=5
WARN Backend returned empty response, retrying attempt=3 maxRetries=5
WARN Backend returned empty response, retrying attempt=4 maxRetries=5
WARN Backend returned empty response, retrying attempt=5 maxRetries=5
WARN Backend produced reasoning without actionable content, retrying reasoning_len=0 attempt=6
The HTTP request nevertheless completes with:
POST /v1/chat/completions status=200
LocalAI version from the startup log:
INFO Using forced capability from environment variable
capability="nvidia"
env="LOCALAI_FORCE_META_BACKEND_CAPABILITY"
INFO LocalAI version
version="v4.9.0 (f7ad3f70eb5d8a0ddf80e08557f0d7df28cf032e)"
Additional context
The problem was originally discovered while testing LocalAI with the
OpenAI Agents Python SDK version 0.22.0.
An Agents SDK handoff is exposed to the model as a function tool similar
to:
Tool name:
transfer_to_customer_retention_agent
Schema:
{
"additionalProperties": false,
"type": "object",
"properties": {},
"required": []
}
Strict:
True
When this is sent through LocalAI, the Agents SDK receives an empty
model output and therefore cannot perform the handoff:
ModelResponse(
output=[],
usage=Usage(
requests=1,
input_tokens=100,
output_tokens=23,
total_tokens=123
)
)
As a workaround I replaced the native handoff with an ordinary Agents
SDK function tool declared with:
@function_tool(strict_mode=False)
def request_handoff(target_agent: str, reason: str) -> str:
...
The same Qwen model then successfully determines that a handoff is
required and calls the tool:
[TOOL] request_handoff called
[TOOL] target_agent = Customer Retention Agent
[TOOL] reason = Customer wants to cancel their order and account after experiencing repeated order delays.
Python can then perform the actual agent transfer.
This suggests that the model is capable of the required tool selection
and function call, and that the failure is specifically associated with
the strict: true tool definition.
Summary of observed behaviour:
| Test | Result |
|---|---|
| Normal chat completion | Works |
Function tool without strict |
Works |
Function tool with "strict": true |
Fails with empty response |
| OpenAI Agents SDK native handoff | Fails |
Agents SDK strict_mode=False function tool |
Works |
- Lenguaje dominante
- Go
- Estrellas
- 49.2k
- Forks
- 4.5k
- Merge medio
- 1 d 7 h
- PR fusionados (30 d)
- 340
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de mudler/LocalAI
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
mudler/LocalAI#11995 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
mudler/LocalAI#11991 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
fish-speech: make compile:true usable on Blackwell sm_121 by honouring the CUDA toolkit's ptxasAbiertoenhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
mudler/LocalAI#11348 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
feat: add automatic MCP transport selection for 2024-11-05 / 2025-03-26 / 2025-06-18 vs 2025-11-25Abiertoenhancement
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
mudler/LocalAI#12262 · 2 comentarios ·
Los mantenedores suelen responder en 3 días
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 3 días
Todos los issues de mudler/LocalAI
Issues similares
-
priority: low 🌱 type: enhancement 💅🏼
Dificultad 2/5 Medio día Aptitud para principiantes 84/100
nebari-dev/llm-serving-pack#199 ·
Los mantenedores suelen responder en 3 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
area/helm kind/bug priority/backlog triage/accepted
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
lexfrei/cloudflare-tunnel-gateway-controller#889 ·
Los mantenedores suelen responder en 1 día
-
bug difficulty: beginner documentation good first issue help wanted localization
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
wavefnd/wave-platform#140 ·
-
compiler/runtime
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
golang/go#81797 · 1 comentario ·
Los mantenedores suelen responder en 1 día