Post actualizado el día octubre 27, 2026 by DeiviSanzPlay
Qué estás comparando realmente cuando eliges una vía de acceso a la API
Hay tres caminos que la gente confunde: la API oficial de OpenAI, la suscripción ChatGPT Plus con sus GPTs personalizados y las plataformas intermedias (Azure OpenAI, OpenRouter, o wrappers como Make/Zapier). Cada uno resuelve un problema distinto y ninguno sustituye al otro. Si buscas un tutorial de la API de ChatGPT para decidir por dónde entrar, lo primero es aceptar que la API no es «ChatGPT sin interfaz»: es un producto con facturación por tokens, límites por minuto y una curva de aprendizaje que empieza por entender que el modelo no recuerda la conversación anterior salvo que tú se la envíes.
Comparativa de las cuatro opciones que la gente usa de verdad
1. API directa de OpenAI (platform.openai.com)
Es la referencia. Generas una clave en el panel, la guardas en una variable de entorno y haces una petición POST al endpoint de chat completions. La ventaja es el acceso inmediato a los modelos nuevos y a la documentación oficial. La desventaja, según la propia documentación, es que el saldo es prepago: si se agota, la API devuelve error 429 y el servicio se detiene sin aviso previo. He visto proyectos caerse en producción un viernes por la tarde por este detalle, no por un bug de código.
Algo que solo se aprende usando: el parámetro max_tokens no limita la longitud de la respuesta de forma intuitiva cuando usas modelos de razonamiento; parte del presupuesto se consume en tokens internos que no ves. Si pones un valor bajo, recibes una respuesta truncada a mitad de frase sin ningún error explícito.
2. Azure OpenAI Service
Mismos modelos, otra infraestructura. Encaja cuando la empresa exige residencia de datos en una región concreta, cumplimiento contractual y facturación consolidada en la nube de Microsoft. El precio por token es similar, pero añade latencia de configuración: crear el recurso, desplegar el modelo y esperar aprobación de acceso. No es una opción para un fin de semana; es una decisión de arquitectura. Limitación clara: los modelos llegan más tarde que en la API pública, así que si necesitas la última versión para probar una idea, no es tu sitio.
3. OpenRouter y agregadores similares
Útiles para comparar modelos de distintos proveedores con una sola clave y una interfaz compatible. La contra es la capa extra: dependes de su disponibilidad, sus precios incluyen margen y la depuración se complica porque el error puede venir del agregador, no del modelo. Para prototipos es cómodo; para producción con SLA, yo lo evitaría salvo que el equipo tenga claro el plan B.
4. Plataformas no-code (Make, Zapier, n8n)
Permiten conectar la API sin escribir código, pero esconden la lógica de tokens y a menudo usan modelos más baratos por defecto. Sirven para automatizaciones simples (clasificar correos, resumir formularios). No sirven para control fino de prompt, temperatura o gestión de contexto largo.
Primer código: lo mínimo que funciona y los errores que aparecen
El esqueleto en Python con el SDK oficial es corto, pero tres fallos concentran la mayoría de las consultas en foros:
- Clave expuesta en el frontend. Cualquier llamada desde JavaScript del navegador filtra la clave. La petición debe salir de un servidor propio.
- No manejar el contexto. Si no reenvías el historial de mensajes en cada llamada, el modelo responde como si fuera la primera vez. El coste crece con cada turno porque todo el historial se factura de nuevo.
- Ignorar los límites de tasa. La documentación oficial detalla los RPM y TPM por nivel de uso; superarlos devuelve error 429 y, sin reintentos con espera exponencial, la aplicación falla en cascada.
Ejemplo concreto de un caso que vi: un chatbot de atención al cliente enviaba 30 mensajes de historial en cada turno porque el desarrollador guardaba las respuestas sin recortar. La factura se multiplicó por cinco en una semana sin que el tráfico creciera. La solución fue resumir el historial antiguo con una llamada aparte y conservar solo los últimos turnos.
Qué no funciona con la API (y conviene saber antes)
La API no tiene memoria entre sesiones, no navega por internet por defecto y no ejecuta código salvo que uses herramientas específicas. Tampoco es un buscador fiable: si le pides datos actuales sin aportar fuentes, puede inventarlos con seguridad aparente. Para tareas de extracción de datos estructurados funciona bien; para cálculos financieros sin verificación, no.
El coste tampoco es trivial a escala. Según la documentación oficial, los precios varían por modelo y por tokens de entrada y salida, y los modelos grandes cuestan varias veces más que los pequeños. Para clasificar textos cortos, un modelo pequeño suele bastar; reservar el grande para razonamiento complejo es la decisión que más ahorra.
Cómo elegir según tu caso
Si estás aprendiendo: API directa, clave en variable de entorno, un script de veinte líneas y el panel de uso abierto para ver el gasto en tiempo real. Si la empresa exige cumplimiento: Azure. Si quieres comparar modelos sin múltiples cuentas: agregador, asumiendo la capa extra. Si no programas: no-code, con la expectativa de que el control es limitado. Ninguna opción garantiza que el modelo acierte; todas requieren validar las respuestas antes de ponerlas delante de un usuario final.
Perfiles verificables: Sitio web
Publicado el 27 de October de 2026. Última revisión: 27 de October de 2026.
