Respuestas y streaming

6.1 Solicitud

POST /lmsp/v1/responses
Authorization: Bearer <token>
Content-Type: application/json
Idempotency-Key: 01J8M5T7Z2K4N6Q8S0V3X5B9DG
LMSP-Version: 1.0

{
  "model": "qwen3:14b-q4_k_m",
  "input": [
    {
      "type": "message",
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "Describe a local model service in one sentence."
        }
      ]
    }
  ],
  "stream": false,
  "max_output_tokens": 512,
  "temperature": 0.7,
  "response_format": {
    "type": "text"
  },
  "store": true
}

El protocolo principal usa una estructura input y output al estilo Responses en lugar de una simple lista de cadenas de mensajes, de modo que una única forma de solicitud pueda transportar:

• mensajes de varios turnos;
• texto, imágenes, audio y archivos;
• llamadas a herramientas y resultados de herramientas;
• salida estructurada;
• resúmenes de razonamiento;
• salida multimodal.

LMSP 1.0 define solo contenido de texto. Los tipos de contenido de imagen, audio y archivo se reservan para versiones posteriores.

Una solicitud que necesita una capacidad de la que el modelo carece se rechaza con 400 y unsupported_capability. Una solicitud que no cabe en la ventana de contexto se rechaza con 400 y context_length_exceeded.

Un servicio que pueda almacenar conversaciones PUEDE admitir también previous_response_id. En caso contrario, cada solicitud DEBE llevar el contexto completo. Un servicio NO DEBE depender de la conexión HTTP para mantener el estado de la conversación.

6.2 Respuesta síncrona

Cuando stream es false, el servicio devuelve 200 OK con un objeto de respuesta una vez terminada la generación.

{
  "id": "resp_01J8M6Q4W2T7N5R3V9X1Z8B0DF",
  "object": "response",
  "created_at": 1794200000,
  "status": "completed",
  "model": "qwen3:14b-q4_k_m",
  "output": [
    {
      "id": "msg_01J8M6Q4W5C8H2K9P3S7Y1A6ZE",
      "type": "message",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "A local model service is a resident interface layer that discovers, manages and calls models on the user's own device."
        }
      ]
    }
  ],
  "usage": {
    "input_tokens": 28,
    "output_tokens": 31,
    "total_tokens": 59
  },
  "error": null,
  "incomplete_details": null
}

Tipos de elemento de salida:

Si la generación falla, una solicitud síncrona recibe como respuesta un estado de error y un documento de problema (sección 9.3), no un objeto de respuesta. El estado failed aparece en los flujos, las tareas y las respuestas almacenadas.

GET /lmsp/v1/responses/{response_id} devuelve una respuesta que se almacenó con store: true. Es opcional y requiere la capacidad conversations. Un id desconocido produce 404 con response_not_found.

6.3 Streaming

Para recibir la respuesta en streaming, establece stream en la solicitud:

{
  "stream": true
}

El servicio responde 200 OK con Content-Type: text/event-stream y envía eventos semánticos. Cada evento tiene un id, un nombre event y un objeto JSON data:

id: 1
event: response.created
data: {"response_id":"resp_01J8M6Q4W2T7N5R3V9X1Z8B0DF","status":"in_progress"}

id: 2
event: response.output_item.added
data: {"response_id":"resp_01J8M6Q4W2T7N5R3V9X1Z8B0DF","output_index":0,"item":{"id":"msg_01J8M6Q4W5C8H2K9P3S7Y1A6ZE","type":"message","role":"assistant","content":[]}}

id: 3
event: response.output_text.delta
data: {"response_id":"resp_01J8M6Q4W2T7N5R3V9X1Z8B0DF","item_id":"msg_01J8M6Q4W5C8H2K9P3S7Y1A6ZE","delta":"A local model "}

id: 4
event: response.output_text.delta
data: {"response_id":"resp_01J8M6Q4W2T7N5R3V9X1Z8B0DF","item_id":"msg_01J8M6Q4W5C8H2K9P3S7Y1A6ZE","delta":"service is a resident interface layer."}

id: 5
event: response.output_item.done
data: {"response_id":"resp_01J8M6Q4W2T7N5R3V9X1Z8B0DF","output_index":0,"item":{"id":"msg_01J8M6Q4W5C8H2K9P3S7Y1A6ZE","type":"message","role":"assistant","content":[{"type":"output_text","text":"A local model service is a resident interface layer."}]}}

id: 6
event: response.completed
data: {"response_id":"resp_01J8M6Q4W2T7N5R3V9X1Z8B0DF","status":"completed","usage":{"input_tokens":28,"output_tokens":12,"total_tokens":40}}

Se definen al menos estos eventos:

Un servicio cierra el flujo después de un evento final o de un evento error.

Los servicios PUEDEN enviar eventos adicionales, por ejemplo para argumentos de llamadas a herramientas, imágenes, audio y deltas JSON estructurados. Los clientes DEBEN ignorar los tipos de evento que no conozcan.

Si el cliente cierra la conexión de una solicitud en streaming, el servicio DEBERÍA dejar de generar.

6.4 Ids de evento y reconexión

El id de un evento DEBE ser un número de secuencia entero estrictamente creciente dentro de la respuesta, que empieza en 1.

Tras una conexión interrumpida, un cliente reanuda enviando el último id que recibió. Lo hace con una cabecera:

Last-Event-ID: 2

o con un parámetro de consulta:

GET /lmsp/v1/tasks/{task_id}/events?after=2

Ambos van al endpoint de eventos de una tarea (sección 7.4). El servicio reproduce solo los eventos cuyo número de secuencia es mayor que 2. Si están presentes los dos, prevalece after.

Si los eventos solicitados son anteriores al período de retención, el servicio responde 410 Gone con el error event_history_expired. El cliente obtiene entonces el resultado final con GET /lmsp/v1/tasks/{task_id}.

Una respuesta transmitida directamente desde POST /lmsp/v1/responses pertenece a esa conexión HTTP y no se puede reanudar. Un cliente que necesite una salida reanudable DEBERÍA crear una tarea y seguir sus eventos.

6.5 Llamadas a herramientas

LMSP 1.0 define herramientas de función que ejecuta el cliente. El servicio no ejecuta herramientas por sí mismo. El ámbito tools:execute se reserva para las extensiones que sí lo hacen (sección 10.3).

Primero, el cliente enumera las herramientas. Cada entrada tiene type con el valor function, un name, una description y parameters, un objeto JSON Schema. tool_choice es auto (el valor por defecto), none, required o {"type": "function", "name": "get_weather"}.

{
  "model": "qwen3:14b-q4_k_m",
  "input": [
    {
      "type": "message",
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "What is the weather in Hangzhou?"
        }
      ]
    }
  ],
  "tools": [
    {
      "type": "function",
      "name": "get_weather",
      "description": "Get the current weather for a city.",
      "parameters": {
        "type": "object",
        "properties": {
          "city": { "type": "string" }
        },
        "required": ["city"]
      }
    }
  ],
  "tool_choice": "auto"
}

Cuando el modelo decide llamar a una herramienta, la respuesta contiene un elemento function_call. Sus arguments son una cadena codificada en JSON. En un flujo, el elemento llega completo en response.output_item.done.

{
  "id": "resp_01J8M7B3N6Q9T2V5X8Z1C4D7FH",
  "object": "response",
  "created_at": 1794200050,
  "status": "completed",
  "model": "qwen3:14b-q4_k_m",
  "output": [
    {
      "id": "fc_01J8M7B3N8R1S4W7Y0A3E6G9JK",
      "type": "function_call",
      "call_id": "call_01J8M7B3N9T2V5X8Z1C4D7F0HM",
      "name": "get_weather",
      "arguments": "{\"city\":\"Hangzhou\"}"
    }
  ],
  "usage": {
    "input_tokens": 74,
    "output_tokens": 18,
    "total_tokens": 92
  },
  "error": null,
  "incomplete_details": null
}

El cliente ejecuta la herramienta y luego envía una nueva solicitud que lleva el contexto completo: los elementos de entrada anteriores, el elemento function_call tal como se recibió y un elemento function_call_output con el mismo call_id. Su output es una cadena, normalmente codificada en JSON.

{
  "type": "function_call_output",
  "call_id": "call_01J8M7B3N9T2V5X8Z1C4D7F0HM",
  "output": "{\"temperature_c\":17,\"condition\":\"light rain\"}"
}