Cómo usar APIs 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 con el proveedor, creas una clave de API y el servidor de tu app envía peticiones con esa clave; se te cobra cada petición según la cantidad de tokens (fragmentos de texto) que entran y salen. Eso es, en esencia, lo que significa normalmente “añadir IA a una app”: una petición bien escrita al modelo de otra empresa, hecha de forma segura desde tu servidor.

Por qué importa cuando construyes con IA

En una app creada con IA hay dos IA distintas, y es fácil confundirlas:

1. La IA que construye tu app: el agente del creador, 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 “resumir esto” o el etiquetado automático.

La segunda llama a una API de LLM con tu clave y factura a tu cuenta del proveedor. Entender los tokens, el contexto y el precio 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 escritor freelance muy capaz, que cobra por palabra

Piensa en una API de LLM como en un escritor freelance brillante al que contactas por correo y al que pagas por palabra, tanto por las palabras que le envías como por las que te devuelve (y las 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 cierta cantidad a la vez. Ese límite es la ventana de contexto.
• Cuanto más clara sea tu instrucción, mejor y más corta será la respuesta, lo que también la abarata.

Los 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 aproximadamente 0,75 palabras en inglés, por token. 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, aceptan hasta un millón de tokens. Pero las entradas largas cuestan más y tardan más, así que envía solo lo que la tarea necesita.

Peticiones sin estado

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

El prompt del sistema

Son las instrucciones que definen el papel del modelo y sus reglas en 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 la respuesta completa, la API puede enviar el texto a medida que se genera, de modo que los usuarios ven aparecer las palabras al instante. Eso hace que las interfaces de chat se sientan 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 sus modelos más grandes, y cambian con frecuencia, así que no los citamos aquí. 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 del sistema (“Resume en tres viñetas y luego redacta una respuesta amable; no inventes números de pedido”) más 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 usó.
4. El botón llama a tu ruta, no al proveedor, y muestra el resumen mientras se va escribiendo.
5. Gestiona los fallos. Si el proveedor tarda o devuelve un error, muestra “No se pudo resumir ahora mismo” y mantén 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 no hace falta: no hay entrenamiento de modelos ni infraestructura especial. Una clave, una ruta en el servidor y un prompt bien escrito.

Términos clave

• Clave de API: el secreto que identifica tu cuenta ante el proveedor. Cualquiera que la tenga puede gastar tu dinero.
• Modelo: el LLM concreto que llamas. Los proveedores ofrecen varios tamaños con distintos precios y velocidades.
• Temperatura: un ajuste que controla cuánto varían las respuestas. Cuanto más baja, más predecibles.
• Tokens máximos: un límite a la 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 fragmentos 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 ejecutar una función concreta, como “consultar 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 trata esto junto con otras comprobaciones antes de lanzar.
• No tener límite de gasto ni límites por usuario. Un error, 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 de chat completos 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 total seguridad. En datos, precios o cualquier tema legal o médico, basa las respuestas en tus propios datos y muestra las fuentes, o haz que una persona lo revise.
• Dejar 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 pensar. Revisa las condiciones de uso de datos del proveedor, sobre todo en los niveles gratuitos, y envía solo lo que la función necesita.

Qué pedirle a tu creador 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 del sistema: […], limita la respuesta a 300 tokens, muestra la respuesta en la página mientras se genera y muestra un mensaje 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 más ideas, cómo añadir funciones de IA a tu app. Si las APIs en general te resultan nuevas, empieza con qué es una API.

Las APIs de LLM en apps creadas con Mythex

Cuando construyes con Mythex, la IA dentro de tu app usa tu propia clave del 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 le pides al agente que haga la llamada en el servidor. El uso del proveedor se factura a tu cuenta del proveedor, no a los créditos de construcción de Mythex. Mythex no incluye tokens para los usuarios de tu app ni un producto integrado de base de conocimiento, y los límites de frecuencia y los controles de coste los diseñas y pruebas tú. La receta de la documentación añadir funciones de IA con tus propias claves de API incluye un prompt inicial, y la página creador de apps con IA muestra por dónde empezar.

Preguntas