Cómo usar las API de LLM: tokens, costes, claves y tu primera función de IA

Una API de LLM es un servicio web que permite a tu app enviar texto a un modelo de lenguaje grande —como los modelos GPT de OpenAI, Claude de Anthropic o Gemini de Google— y recibir su respuesta en código. Te registras en el proveedor, creas una clave de API y el servidor de tu app envía peticiones con esa clave; se te cobra por cada petición según el número de tokens (fragmentos de texto) que entran y salen. Eso es todo lo que suele significar «añadir IA a una app»: una petición bien escrita al modelo de otro, hecha de forma segura desde tu servidor.

Por qué importa cuando construyes con IA

Hay dos IA distintas en una app creada con IA, y es fácil confundirlas:

1. La IA que construye tu app: el agente del propio creador de apps, que escribe el código.
2. La IA dentro de tu app: una función que usan tus usuarios, como un asistente de chat, un botón de «resume esto» o el etiquetado automático.

La segunda llama a una API de LLM con tu clave y factura en tu cuenta del proveedor. Entender los tokens, el contexto y los precios te permite diseñar una función que funcione, que no filtre tu clave y que no te sorprenda con una factura.

Una analogía cotidiana: un redactor muy capaz, pagado por palabra

Piensa en una API de LLM como un redactor freelance brillante al que escribes por correo y al que pagas por palabra: tanto por las palabras que le envías como por las que te devuelve (y las palabras que escribe cuestan más).

• No tiene memoria entre correos. Si quieres que continúe una conversación, pegas los mensajes anteriores en cada correo nuevo.
• Solo puede leer una cantidad limitada a la vez. Ese límite es la ventana de contexto.
• Cuanto más clara sea tu petición, mejor y más corta será la respuesta, lo que también la abarata.

Conceptos básicos

Tokens

Los modelos leen y escriben texto en tokens. La documentación de precios de Anthropic estima, a septiembre de 2026, unos 4 caracteres, o unas 0,75 palabras en inglés, por token. Los distintos modelos e idiomas se tokenizan de forma diferente, así que tómalo como una guía aproximada. Todo cuenta: tus instrucciones, el mensaje del usuario, los documentos que incluyas, la conversación anterior y la respuesta.

Entrada y salida

Los tokens de entrada son lo que envías. Los tokens de salida son lo que escribe el modelo. En las páginas de precios de OpenAI, Anthropic y Google, a septiembre de 2026, los tokens de salida cuestan varias veces más que los de entrada para el mismo modelo. La página de precios de Gemini de Google también indica que el «razonamiento» interno de un modelo cuenta como salida.

Ventana de contexto

El número máximo de tokens que un modelo puede recibir en una sola petición, incluida la respuesta. Los modelos modernos aceptan entradas muy largas; algunos modelos actuales de Anthropic, por ejemplo, admiten hasta un millón de tokens. Pero las entradas largas cuestan más y tardan más, así que envía solo lo que necesita la tarea.

Peticiones sin estado

Con la mayoría de las API de estilo chat, cada petición es independiente por defecto. Para que un chat «recuerde», tu app vuelve a enviar los mensajes anteriores con cada nuevo mensaje. Por eso una conversación larga cuesta más por mensaje que una corta.

El prompt de sistema

Son las instrucciones que fijan el papel del modelo y sus reglas para cada petición: «Resumes tickets de soporte en tres viñetas. Nunca incluyas direcciones de correo de clientes». Los usuarios no lo ven, pero da forma a cada respuesta.

Streaming

En lugar de esperar a la respuesta completa, la API puede enviar el texto según se genera, de modo que los usuarios ven aparecer las palabras al instante. Esto hace que las interfaces de chat parezcan mucho más rápidas.

Cómo funcionan los precios

A septiembre de 2026, según las páginas de precios de los propios proveedores:

Algunos proveedores también ofrecen una forma de probar antes de pagar: Anthropic da a los usuarios nuevos una pequeña cantidad de crédito gratuito, y la API de Gemini de Google tiene un nivel gratuito en algunos modelos, con la advertencia de que el contenido enviado en él puede usarse para mejorar los productos de Google.

Los precios difieren mucho entre los modelos pequeños y rápidos de un proveedor y los más grandes, y cambian a menudo, así que aquí no los indicamos. Una estimación sencilla para cualquier función es: (tokens de entrada × precio de entrada + tokens de salida × precio de salida) × número de peticiones al mes. Después añade un margen y establece un límite de gasto mensual en el panel del proveedor.

Un ejemplo práctico: un botón de «resumir este ticket»

Un pequeño equipo de soporte quiere un botón que convierta un hilo largo de correos de clientes en tres viñetas y una respuesta sugerida.

1. Consigue una clave. Crea una cuenta con un proveedor y genera una clave de API. Establece un límite de gasto mensual bajo.
2. Guarda la clave como secreto en tu servidor, con un nombre como ANTHROPIC_API_KEY u OPENAI_API_KEY, nunca en el código de la página. Consulta variables de entorno y secretos.
3. Añade una ruta en el servidor, POST /api/summarise, que:
   • compruebe que la persona ha iniciado sesión y pertenece al equipo de soporte;
   • cargue el ticket desde la base de datos;
   • envíe al proveedor un prompt de sistema («Resume en tres viñetas y luego redacta una respuesta amable; no inventes números de pedido») junto con el texto del ticket;
   • limite la longitud de la respuesta con un ajuste de tokens de salida máximos;
   • devuelva el resultado y registre cuántos tokens ha usado.
4. El botón llama a tu ruta, no al proveedor, y muestra el resumen mientras se va generando.
5. Gestiona los fallos. Si el proveedor tarda o devuelve un error, muestra «No se pudo resumir en este momento» y deja el ticket utilizable.
6. Mide. Tras una semana, revisa los registros de tokens. Si la mayor parte del coste viene de hilos de correo largos, recorta el historial citado antes de enviarlo.

Fíjate en lo que falta: no hay entrenamiento de modelos ni infraestructura especial. Una clave, una ruta de servidor y un prompt bien escrito.

Términos clave

• Clave de API: el secreto que identifica tu cuenta ante el proveedor. Quien la tenga puede gastar tu dinero.
• Modelo: el LLM concreto al que llamas. Los proveedores ofrecen varios tamaños a distintos precios y velocidades.
• Temperatura: un ajuste que controla la variedad de las respuestas. Cuanto más bajo, más predecibles.
• Tokens máximos: un límite de longitud de la respuesta, que también limita el coste.
• Límite de frecuencia (rate limit): cuántas peticiones o tokens puede usar tu cuenta por minuto.
• Embeddings: números que representan el significado de un texto, usados para buscar en tus propios documentos.
• RAG (generación aumentada por recuperación): buscar pasajes relevantes de tus propios datos e incluirlos en el prompt, para que el modelo responda con tu contenido.
• Uso de herramientas / llamada a funciones: permitir que el modelo pida a tu app que ejecute una función concreta, como «consulta el estado de un pedido».

Errores comunes e ideas equivocadas

• Poner la clave en el código del frontend. Es el error más caro. El código del navegador es público. Llama siempre desde tu servidor. La lista de seguridad para apps creadas con IA cubre esto junto con otras comprobaciones antes del lanzamiento.
• No tener límite de gasto ni límites por usuario. Un fallo, un bucle o un usuario abusivo pueden disparar los costes rápidamente. Establece un límite en el proveedor y limita las peticiones por usuario en tu app.
• Enviarlo todo cada vez. Documentos enteros e historiales completos de chat multiplican los tokens de entrada. Recorta, resume los mensajes antiguos o recupera solo las partes relevantes.
• Confiar ciegamente en la salida. Los modelos pueden afirmar cosas erróneas con seguridad. En datos, precios o cualquier asunto legal o médico, basa las respuestas en tus propios datos y muestra las fuentes, o haz que una persona lo revise.
• Permitir que la entrada del usuario anule tus reglas. Los usuarios pueden escribir «ignora tus instrucciones». Mantén los permisos y las acciones sensibles en el código de tu servidor, no solo en el prompt.
• Empezar con el modelo más grande. Prueba primero un modelo más pequeño y barato; sube solo si la calidad lo exige.
• Enviar datos personales sin pensarlo. Revisa las condiciones de uso de datos del proveedor, sobre todo en los niveles gratuitos, y envía solo lo que necesita la función.

Qué pedir a tu creador de apps con IA

Añade un botón «Resumir» en la página del ticket. Llama a una ruta del servidor que usa el secreto OPENAI_API_KEY (nunca expuesto al navegador), comprueba que el usuario ha iniciado sesión, envía el texto del ticket con este prompt de sistema: […], limita la respuesta a 300 tokens, transmite la respuesta a la página y muestra un error amable si la llamada falla. Registra los tokens usados por petición y limita a cada usuario a 30 resúmenes por hora.

Para una experiencia de chat completa, consulta cómo crear una app de chatbot con IA; para otras ideas, cómo añadir funciones de IA a tu app. Si las API en general te resultan nuevas, empieza por qué es una API.

API de LLM en apps creadas con Mythex

Cuando construyes con Mythex, la IA dentro de tu app usa tu propia clave de proveedor. La añades como secreto del proyecto, o a través de la tarjeta de secretos que Mythex muestra en el chat cuando la necesita, y pides al agente que haga la llamada en el servidor. El uso del proveedor se factura en tu cuenta de proveedor, no a los créditos de construcción de Mythex. Mythex no incluye tokens para los usuarios de tu app ni un producto de base de conocimiento integrado, y los límites de frecuencia y los controles de coste son tuyos para diseñarlos y probarlos. La receta de la documentación añadir funciones de IA con tus propias claves de API incluye un prompt de inicio, y la página del creador de apps con IA muestra por dónde empezar.

Preguntas