[pocharlies]

Qué pasa hoy

El razonamiento que el cliente sí conserva en el historial llega al backend y se descarta en silencio, antes de la plantilla y sin error. El modelo vuelve a razonar lo ya razonado en cada paso de herramienta.

La causa no es LiteLLM: es un nombre de campo.

• vLLM lee el thinking previo de message["reasoning"] (vllm/entrypoints/chat_utils.py). En su ConversationMessage, reasoning_content está marcado "Deprecated": solo se escribe en la salida, de la entrada nunca se lee.
• LiteLLM emite reasoning_content — por el adaptador openai/ y también por la traducción de /v1/messages, que además lo duplica en thinking_blocks.

Medido

/tokenize sobre una secuencia de tools (no gasta GPU, renderiza la plantilla):

sin thinking histórico               321 tok
campo 'reasoning_content' (LiteLLM)  321 tok   ← se descarta
campo 'reasoning'  (lo que vLLM lee) 472 tok   ← llega

La plantilla del modelo sí lo usa: chat_template.jinja:111-117 emite <think>…</think> en cuanto el campo llega con el nombre bueno. El único eslabón roto era el nombre.

Por qué acotado al turno en curso

chat_template_kwargs.preserve_thinking: False preserva solo el thinking posterior al último mensaje de usuario — la secuencia de herramientas en marcha, que es lo que recomienda Qwen. Sin ese kwarg se preservaría el de toda la conversación y el contexto de una sesión agéntica larga crece sin tope.

El precio está medido y es el prefix cache:

	tokens turno 1	prefijo compartido al llegar un mensaje nuevo
hoy	351	100 % (recomputa 1 tok)
este PR (preserve_thinking:false)	953	30 % (recomputa 666 tok)
todo el historial	953	100 % (recomputa 1 tok)

Se paga una vez por turno de usuario, no por paso de herramienta: dentro del turno el prefijo sigue creciendo de forma monótona. A cambio, el contexto no se infla de forma acumulativa (turno 2: 358 tok, casi igual que hoy).

Relación con el PR 41050 de upstream

No es ese arreglo. BerriAI/litellm#41050 reenvía reasoning_content, que es justo el nombre que vLLM ya no lee. Y aquí no aplicaría de todas formas: ningún modelo de este proxy usa el adaptador hosted_vllm/ — los vLLM locales van por openai/, que ya conserva el campo. Comprobado reproduciendo ambos adaptadores contra la librería del pod.

Alcance

Acotado a FORWARD_REASONING_MODELS = los dos alias del backend qwen38-flash-next, el mismo par que ya lista STRICT_LEADING_SYSTEM_MODELS (mismo backend, mismo template). Un test de contrato exige que las dos listas no se desincronicen.

La llamada va con el modelo resuelto, no con el alias pedido: con el alias sería un no-op para tooling/high/max.

Tests

tests/test_forward_reasoning_contract.py, 10 casos que ejecutan la función real extraída del manifiesto (no una copia). Existe porque el fallo es mudo: si alguien renombra el campo o retira el kwarg, nada peta y el único síntoma es que el modelo vuelve a razonar lo ya razonado.

Suite completa: 321 pasan. Queda 1 rojo, test_openrouter_access_contract, preexistente en main limpio (migración de ExternalSecrets a 1Password, 11bfdaf) y ajeno a este cambio.

Nota de despliegue

config.k8s.e-dani.com/revision se recalcula: el hook vive en un ConfigMap que el proceso no relee en caliente. Venía ya desactualizada de antes de este cambio.

🤖 Generated with Claude Code

[github-actions]

Review automatica

⏭️ Modelo no disponible, review omitida. contenido vacio (finish_reason='length')

El perfil de computo de los Sparks se conmuta entre llm-tp y creative; en creative el modelo no tiene endpoints. El check queda en verde a proposito.

_{modelo tooling · revision no bloqueante}