Explorar notas
APIs de modelos
Desde código, una llamada a un modelo suele consistir en construir una request con el modelo, el input y los parámetros necesarios, enviarla al endpoint y procesar la response. A partir de ahí aparecen piezas como usage, streaming y tool calls.
Ejemplo con LM Studio
LM Studio puede exponer un modelo local mediante endpoints OpenAI-compatible. Esto permite reutilizar el SDK de OpenAI cambiando el base_url:
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:1234/v1",
api_key="lm-studio",
)
response = client.chat.completions.create(
model="model-identifier",
messages=[
{"role": "user", "content": "Resume los cambios de este diff."}
],
temperature=0.2,
)
print(response.choices[0].message.content)
print(response.usage)model-identifier debe coincidir con el modelo cargado. El cliente envía la request a LM Studio, el runtime ejecuta la inferencia y devuelve una estructura compatible con el SDK.
El ejemplo utiliza Chat Completions porque su estructura de messages sigue apareciendo en muchos clientes locales. LM Studio también documenta /v1/responses y su propia API REST.
Request y response
La request necesita identificar el modelo y aportar el input. También puede incluir límites de output, parámetros de sampling, instrucciones o definiciones de tools, según la API.
La response puede contener texto, una tool call, el motivo de parada y metadata como usage. El cliente debería leer la estructura documentada por el endpoint en lugar de asumir que un único campo de texto representa todo el resultado.
El usage suele separar input y output tokens y es la base para interpretar cuánto procesó la llamada y calcular su coste. Las categorías adicionales, como cached input o reasoning, dependen del proveedor.
Streaming
Con streaming, el output llega en eventos o fragmentos mientras se genera. El cliente puede mostrar texto progresivamente y, cuando la API lo permite, reconstruir una tool call cuyos argumentos llegan por partes.
El usage definitivo suele aparecer al final del stream o en un evento específico. La forma exacta depende del protocolo del proveedor.
Tool calls
Una request puede incluir definiciones de tools. El modelo puede responder con el nombre de una operación y argumentos estructurados en lugar de producir directamente la respuesta final.
La aplicación valida y ejecuta esa operación y devuelve el resultado al modelo para continuar. Uso de herramientas desarrolla ese recorrido; en la integración con la API hay que conservar los IDs u objetos que relacionan cada call con su resultado.
Estado
Algunas APIs esperan que la aplicación reenvíe en cada request el historial que siga siendo relevante. Otras permiten referenciar una response o conversación anterior.
Ese mecanismo de continuación no sustituye al estado de la aplicación. Un repositorio, una base de datos o el propio harness pueden seguir siendo la fuente donde viven el trabajo realizado, los artefactos y las decisiones que deben persistir.
OpenAI-compatible
OpenAI-compatible suele indicar que otro servidor implementa endpoints o formatos con una forma suficientemente parecida a OpenAI como para reutilizar clientes existentes.
La compatibilidad debe comprobarse sobre las funciones que utiliza la integración. Un servidor puede aceptar messages y temperature y diferir en tools, reasoning, usage, streaming o parámetros ignorados.