Primeros pasos con la API de un LLM: clave, primera llamada, parámetros, costos y buenas prácticas

Para usar la API de un LLM, debe crear una clave de acceso, elegir un modelo y enviar una solicitud con sus instrucciones y el texto que desea procesar. El servicio devuelve una respuesta que su programa debe comprobar, junto con un consumo que conviene supervisar. Esta guía presenta una primera llamada reproducible y explica los ajustes, el presupuesto y las medidas de protección necesarios antes de utilizarla de forma habitual.

Entender qué va a conectar

Una API permite que un programa solicite un servicio a otro. Con un modelo de lenguaje, su aplicación suele enviar mensajes y recibir texto o datos estructurados. Así puede resumir un documento, clasificar una solicitud o preparar un borrador sin pasar por una interfaz de chat.

La llamada no concede al modelo acceso automático a sus archivos, a Internet ni a su correo electrónico. Esas funciones requieren conexiones y permisos adicionales. Para empezar, limite la tarea: convertir un texto público breve en un resumen.

El procedimiento que sigue utiliza OpenRouter, una plataforma que envía solicitudes a proveedores de modelos. Se trata de un ejemplo técnico, no de una recomendación comercial. Su guía oficial de inicio, consultada el 24 de octubre de 2026, documenta la dirección y el método empleados aquí.

Criterio	API directa de un proveedor	Plataforma intermediaria
Cuenta y clave	Se gestionan con el proveedor	Se gestionan con la plataforma
Selección de modelos	Catálogo del proveedor	Catálogo que ofrece el intermediario
Recorrido de los datos	Aplicación y después proveedor	Aplicación, intermediario y después proveedor
Diagnóstico	Documentación del proveedor	Documentación de la plataforma y del proveedor
Presupuesto	Condiciones de la oferta directa	Condiciones de la plataforma y de los servicios utilizados

En ambos casos, compruebe primero que el modelo esté disponible y revise las condiciones aplicables a su cuenta.

1. Preparar la cuenta y un entorno sencillo

Requisitos previos: una cuenta con acceso a la API elegida, un terminal Bash, el comando curl disponible y un texto de prueba sin información confidencial. Los comandos siguientes están pensados para Bash; no los copie tal cual en otro intérprete de comandos.

No necesita ninguna biblioteca para este ejercicio. Si su equipo no dispone de las herramientas necesarias, utilice un entorno autorizado por su organización y siga el procedimiento de instalación correspondiente.

En el panel de control de la plataforma:

1. Revise las condiciones de facturación y los créditos disponibles.
2. Cree una clave exclusiva para este ejercicio.
3. Configure un límite de gasto adecuado para la prueba.
4. Localice los datos de consumo y la opción para revocar la clave.

La documentación de autenticación, consultada el 24 de octubre de 2026, describe las claves y sus límites de crédito. Para esta primera conexión, evite utilizar una clave compartida entre varios proyectos: dificulta identificar a qué proyecto corresponden los incidentes y los gastos.

A continuación, elija un modelo al que su cuenta tenga acceso. Consulte las fichas de modelos para orientarse y copie después su identificador exacto de API desde la plataforma. El nombre comercial que aparece en una interfaz no siempre basta para construir una solicitud.

Los benchmarks de modelos ofrecen referencias para comparar opciones. No sustituyen una prueba con su propio texto, su idioma y el formato de salida que necesita.

2. Cargar la clave sin escribirla en el programa

Una clave de API es un secreto de acceso. Cualquier persona que la obtenga podría utilizar los permisos asociados y consumir su presupuesto. No la incluya en una página web pública, en una aplicación que distribuya a los usuarios ni en un repositorio de código.

En Bash, introdúzcala sin que aparezca en pantalla:

read -r -s -p "Clé API : " OPENROUTER_API_KEY
printf '\n'
export OPENROUTER_API_KEY

Este método evita escribir directamente el secreto en un comando que quedaría guardado en el historial del terminal. No convierte el equipo en una caja fuerte: un proceso autorizado para inspeccionar su entorno todavía podría acceder a la clave.

Introduzca después el identificador del modelo elegido:

read -r -p "Identifiant API exact du modèle : " LLM_MODEL
export LLM_MODEL

Copie únicamente el identificador que proporciona la plataforma. El ejemplo siguiente supone que no contiene comillas ni saltos de línea, para poder insertarlo en el documento JSON.

No envíe la clave al modelo en un mensaje para pedirle que la compruebe. La autenticación se transmite en una cabecera de la solicitud; el texto que debe procesarse va en el cuerpo.

Para una aplicación desplegada, utilice el sistema de gestión de secretos de su alojamiento. Separe las claves de desarrollo y de producción, limite quién puede consultarlas y prevea cómo sustituirlas. Una variable de entorno sirve para este ejercicio, pero su protección depende siempre del entorno en el que se encuentre.

3. Enviar la primera llamada

El siguiente comando adapta el formato documentado por la plataforma a una tarea de resumen. El límite de salida y los tiempos de espera son ajustes para el ejercicio, no límites anunciados por el servicio.

curl --silent --show-error \
  --connect-timeout 10 \
  --max-time 60 \
  --dump-header reponse.headers \
  --output reponse.json \
  --write-out 'Statut HTTP : %{http_code}\n' \
  https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<EOF
{
  "model": "$LLM_MODEL",
  "messages": [
    {
      "role": "system",
      "content": "Vous résumez fidèlement le texte fourni en français. N'ajoutez aucune information."
    },
    {
      "role": "user",
      "content": "Résumez en une phrase : La bibliothèque municipale ferme lundi pour réaliser un inventaire. Elle rouvrira mardi aux horaires habituels."
    }
  ],
  "max_tokens": 200,
  "stream": false
}
EOF

Authorization contiene la credencial de acceso. Content-Type indica que el cuerpo está en formato JSON. model identifica el modelo solicitado, mientras que messages contiene las instrucciones y el texto.

El comando guarda las cabeceras y el cuerpo en archivos separados. También muestra el estado HTTP, que ayuda a distinguir una respuesta del servicio de un problema de conexión.

Lea el resultado:

cat reponse.json

No sustituya sin más el texto del ejemplo por una variable extensa que contenga cualquier documento. Las comillas o los saltos de línea podrían invalidar el JSON. Para procesar datos variables, utilice un codificador JSON en su lenguaje de programación que construya el documento correctamente.

Al terminar el ejercicio, elimine la clave del entorno del terminal:

unset OPENROUTER_API_KEY

Este comando no revoca la clave en la plataforma.

4. Leer la respuesta antes de utilizarla

El archivo recibido es un contenedor técnico. En el formato Chat Completions utilizado aquí, el texto suele encontrarse en choices[0].message.content. Los demás campos sirven, entre otras cosas, para identificar la respuesta, entender por qué terminó la generación y seguir el consumo.

Examine por separado estos tres aspectos:

• El resultado técnico: ¿se ha aceptado la solicitud o contiene un error?
• El final de la generación: ¿el modelo ha terminado con normalidad o ha alcanzado un límite?
• El contenido: ¿el resumen respeta el texto y las instrucciones?

Un estado de éxito no garantiza que el resumen sea correcto. En este ejercicio, el resultado debe conservar el cierre del lunes y la reapertura del martes, sin inventar ningún motivo adicional.

Los contadores de consumo utilizan tokens, unidades de texto que no siempre equivalen a palabras. Por tanto, evite calcular una factura mediante conversiones fijas entre palabras, caracteres y tokens.

La ventana de contexto delimita lo que el modelo puede procesar en una llamada, según sus reglas. El texto de entrada, las instrucciones, el historial y la generación ocupan un espacio cuyo límite debe comprobar para el modelo elegido.

Si una aplicación va a guardar un resultado, también debe poder rechazar una respuesta vacía, incompleta o incoherente. Mostrar directamente todo lo que llega no es una práctica adecuada para un proceso automatizado.

5. Ajustar los parámetros de forma gradual

Empiece con pocos parámetros. Añada un ajuste para resolver un problema que haya observado y compare después el resultado con los mismos ejemplos.

La referencia de parámetros, consultada el 24 de octubre de 2026, señala que los parámetros admitidos dependen del modelo y del proveedor. Si omite uno, el proveedor puede aplicar su valor predeterminado.

Parámetro	Función	Precaución
model	Seleccionar el modelo	Comprobar el identificador y el acceso
messages	Proporcionar instrucciones y contenido	Separar claramente los roles
max_tokens	Limitar la generación	Dejar espacio suficiente para terminar
temperature	Modificar la variedad de las respuestas	No considerarlo un ajuste de veracidad
top_p	Influir en la selección de tokens	Evitar cambiar todos los ajustes a la vez
stream	Recibir la generación de forma progresiva	Prever cómo gestionar las interrupciones

Una temperatura baja puede reducir la diversidad de las formulaciones. No garantiza la exactitud de los hechos ni que el resultado se reproduzca de manera idéntica entre ejecuciones. En una tarea de extracción, validar el resultado cuenta más que utilizar un valor supuestamente ideal.

Un límite de salida demasiado bajo puede cortar la respuesta. Además, con algunos modelos de razonamiento, parte del presupuesto puede consumirse sin aparecer en el texto final. Si la salida está vacía, examine el consumo y el motivo de finalización antes de volver a intentarlo.

Para elegir el modelo, la guía Cómo elegir un modelo de lenguaje complementa este método. Mantenga el mismo texto y los mismos criterios de evaluación cuando compare varios candidatos.

6. Calcular el costo por tarea completada correctamente

Para una llamada de texto sencilla, el cálculo básico suma los tokens de entrada y de salida, cada uno multiplicado por su tarifa. Según el servicio, pueden añadirse otros conceptos: caché, razonamiento, herramientas o modalidades específicas.

Este es un ejemplo de cálculo con fines didácticos, sin relación con ninguna tarifa comercial: supongamos que la entrada cuesta 1 dólar por millón de tokens y la salida, 4 dólares por millón. Con 2 000 tokens de entrada y 500 de salida:

Entrée : 2 000 / 1 000 000 × 1 $ = 0,002 $
Sortie : 500 / 1 000 000 × 4 $ = 0,002 $
Total simulé : 0,004 $ par appel

Bajo este supuesto, 1 000 llamadas idénticas representarían 4 dólares, sin incluir otros cargos. Estas cifras explican el cálculo; no son un presupuesto ni una estimación de su consumo.

El indicador útil es el costo de una tarea completada correctamente. Un modelo con un precio por token más bajo puede necesitar más intentos, correcciones o comprobaciones. Una conversación larga también puede volver a enviar los mismos fragmentos varias veces.

Para elaborar su presupuesto real, anote la tarifa aplicable al modelo y al proveedor seleccionados, junto con la fecha. Mida después tareas representativas y contraste los contadores de consumo con el panel de facturación.

La calculadora de precios de LLM ayuda a comparar volúmenes. La guía Entender los precios de las API de LLM detalla los conceptos que conviene revisar, mientras que el artículo ¿Cuánto cuesta realmente un agente de IA al mes? aborda los gastos de una aplicación que encadena llamadas.

7. Separar las instrucciones, los documentos y el formato esperado

Una instrucción útil describe el trabajo, la fuente autorizada y el resultado esperado. Para resumir un documento, indique que la información debe proceder de ese documento y que no deben completarse los datos que falten.

Separe las reglas de la aplicación del contenido que se va a analizar. Un documento recibido de un usuario puede contener frases que parezcan órdenes. Su programa debe tratarlo como un dato, sin concederle capacidad para cambiar los permisos ni el destino de los resultados.

Para enviar el resultado a otro programa, no basta con pedir JSON en el mensaje. Las salidas estructuradas documentadas, consultadas el 24 de octubre de 2026, permiten definir un esquema con los modelos compatibles.

Su aplicación debe seguir comprobando que los campos estén presentes, que sus tipos sean correctos y que sus valores estén permitidos. Una respuesta que respete el esquema puede contener una fecha incorrecta o un importe que no figure en el documento original. La validación del formato y la exactitud de los datos son controles distintos.

Prevea una salida explícita cuando falte información: permitir un valor ausente, marcar el resultado como pendiente de revisión o derivarlo a una persona. Obligar al modelo a completar todos los campos favorece que añada información sin fundamento.

Por último, una API no se convierte en un agente por producir texto estructurado. El artículo Crear su primer agente de IA presenta el paso siguiente: añadir herramientas, un estado y un ciclo de ejecución bajo control.

8. Proteger los datos y controlar los gastos

Antes de enviar un documento real, identifique el recorrido que seguirá. Si utiliza un intermediario, los datos pasan por la plataforma y después por el proveedor seleccionado. Revise también los registros que genera su propia aplicación.

La política de privacidad de OpenRouter, consultada el 24 de octubre de 2026, distingue las prácticas de la plataforma de las de los proveedores de modelos. Una garantía sobre el uso de datos para entrenamiento no resuelve por sí sola las cuestiones de conservación, acceso o ubicación.

Para empezar, utilice datos públicos o ficticios. Elimine la información que no sea necesaria para la tarea: datos de contacto, identificadores de cuenta, secretos técnicos o archivos adjuntos que no guarden relación con la solicitud.

Para controlar el presupuesto, combine varias medidas: límite de la clave, longitud máxima de las entradas, límite de generación y número máximo de intentos. Si la aplicación está abierta a usuarios, añada una cuota por usuario para evitar que una sola persona consuma todo el presupuesto.

Mantenga la clave en su servidor. El navegador del usuario llama a su aplicación, que comprueba sus permisos antes de consultar al modelo. Limite también el tamaño de las solicitudes y el número de llamadas simultáneas.

Registre preferentemente metadatos: modelo solicitado, duración, consumo, estado e identificador de solicitud. Guardar los documentos y las respuestas completos debe responder a una necesidad concreta, con permisos de acceso y un plazo de conservación definidos.

9. Problemas frecuentes

Los errores documentados por la plataforma, consultados el 24 de octubre de 2026, permiten distinguir un problema de la solicitud de una incidencia temporal.

Síntoma	Causa que debe revisar	Primera medida
Estado 400	JSON inválido o parámetro incompatible	Leer el mensaje y simplificar la llamada
Estado 401	Clave ausente, inválida o revocada	Comprobar que el secreto se haya cargado
Estado 402	Créditos o presupuesto insuficientes	Consultar el saldo y los límites
Estado 403	Permiso o regla de bloqueo	Examinar las restricciones aplicables
Estado 429	Límite de solicitudes alcanzado	Esperar antes de volver a intentarlo
Estado 502 o 503	Incidencia de disponibilidad	Reintentar con un tiempo de espera limitado
Texto cortado o vacío	Presupuesto agotado o generación interrumpida	Examinar el motivo de finalización y el consumo

No repita en bucle una solicitud inválida ni vuelva a enviar continuamente una clave rechazada. Ante incidencias temporales, aumente progresivamente la espera entre intentos, respete la cabecera Retry-After cuando exista y establezca un límite global.

Que se agote el tiempo de espera del cliente no demuestra que el proveedor no haya procesado nada. Por tanto, un nuevo intento puede generar consumo adicional. Si su programa ejecuta después una acción en un proceso de trabajo, protéjalo también frente a duplicados.

Para solicitar ayuda, conserve la hora, el identificador de solicitud y un ejemplo mínimo anonimizado. Nunca publique la clave ni el documento confidencial afectado.

10. Validar el paso a un uso habitual

Antes de integrar esta llamada en un proceso real, prepare un pequeño conjunto de casos representativos: texto sencillo, documento incompleto, entrada larga, instrucción ambigua y contenido ajeno al tema. Añada situaciones en las que la respuesta correcta sea señalar que falta información.

Defina sus criterios antes de comparar los resultados. Para un resumen: conservación de los hechos, ausencia de añadidos, idioma correcto y extensión aceptable. Para una extracción: valores fieles a la fuente, campos validados y errores detectados.

Conserve el identificador del modelo y los parámetros utilizados. Un cambio de modelo, proveedor o instrucciones justifica una nueva comprobación con los mismos casos. Mida también la duración y el costo, ya que una respuesta correcta pero demasiado lenta puede no servir para su aplicación.

Termine con esta lista de comprobación:

• La clave es exclusiva, está protegida y se puede revocar.
• Se han comprobado el modelo y los parámetros admitidos.
• La primera llamada utiliza datos sin requisitos especiales de confidencialidad.
• El programa controla los errores, las salidas vacías y las respuestas incompletas.
• Los resultados se evalúan con ejemplos representativos.
• El costo observado se contrasta con la facturación.
• Los intentos, los volúmenes y los gastos tienen límites definidos.
• Se ha delimitado qué datos se transmiten y qué información se guarda en los registros.

Con ello dispone de una base que puede supervisar: una llamada comprensible, un resultado verificado y un presupuesto medible. Añada las siguientes funciones de forma gradual y mantenga estos controles en cada etapa.

Páginas relacionadas

• OpenRouter
• Google AI Studio
• Hugging Face

Preguntas frecuentes

¿Hace falta una suscripción a un chatbot para usar una API de LLM?

El acceso a una interfaz de chat y el acceso a una API son servicios distintos. Revise las condiciones de la plataforma elegida: tener una suscripción a un chatbot no significa que disponga de créditos para la API.

¿Se puede llamar a una API de LLM sin instalar una biblioteca?

Sí, basta con una solicitud HTTP si su entorno permite enviarla. Una biblioteca facilita después la lectura de las respuestas y la gestión de errores, pero también incorpora una dependencia que deberá mantener.

¿Por qué una respuesta breve puede costar más de lo previsto?

La facturación puede incluir un texto de entrada extenso, un historial que se vuelve a enviar en cada intercambio o tokens de razonamiento. Revise los datos de consumo en lugar de fijarse únicamente en la extensión del texto visible.

¿Se puede cambiar de proveedor sin modificar la aplicación?

Una interfaz compatible puede reducir los cambios necesarios, pero no garantiza que el comportamiento sea idéntico. Deberá comprobar de nuevo los parámetros admitidos, los formatos de respuesta, las reglas de conservación de datos y los resultados.

¿Qué debe hacer si una clave de API aparece en un repositorio público?

Revóquela de inmediato, cree un nuevo secreto y actualice las aplicaciones afectadas. Eliminar la línea del repositorio no basta: alguien podría haber copiado la clave y esta podría seguir disponible en el historial.