AI News Hub Logo

AI News Hub

Cómo Rastrear el Gasto de la API de OpenAI por Función: Guía de Atribución de Costos

DEV Community
Roobia

Tu factura de OpenAI dice que gastaste $4,237 el mes pasado. No te dice que $3,100 vinieron de un único endpoint de resumen descontrolado, $700 de un cliente que paga $50 al mes y $437 de una función que nadie usa. El panel de control oculta la información que necesitas para decidir precios, capacidad y roadmap. Prueba Apidog hoy Esta guía muestra cómo implementar atribución de costos para la API de OpenAI: etiquetar cada solicitud con metadatos, calcular el gasto por función, ruta y cliente, configurar límites de presupuesto por clave y diseñar prompts para que el costo deje de ser una línea opaca. 💡 Apidog te ayuda a validar solicitudes etiquetadas antes de producción. Úsalo para reproducir llamadas, verificar la forma del log y comprobar que cada request incluye los metadatos que tu almacén espera. Etiqueta cada llamada a la API de OpenAI con metadatos estructurados: feature route customer_id environment model Después, emite un log estructurado por solicitud con tokens, latencia y costo calculado. Agrega esos eventos en tu almacén de datos y consulta el gasto por función, cliente o ruta. También deberías: configurar límites de presupuesto por clave en OpenAI; crear alertas sobre anomalías de gasto por hora; validar el wrapper extremo a extremo con Apidog. Lanzas una función de IA el martes. El viernes, tu CFO pregunta por qué el gasto de OpenAI subió 40%. Abres el panel de OpenAI. Ves que el gasto total sube, pero no sabes qué función, cliente o ruta lo causó. Esa es la brecha que encuentran los equipos que ejecutan LLMs en producción. La interfaz de facturación de OpenAI sirve para cuentas por pagar, no para atribución técnica. Ves totales diarios y desglose por modelo, pero no ves la solicitud, el cliente, la ruta ni la función que activó el gasto. La solución es directa: envolver cada llamada a OpenAI; añadir metadatos obligatorios; registrar cada solicitud en un formato estructurado; calcular el costo al momento de escribir el evento; agregar por etiquetas; alertar sobre desviaciones. Para el contexto de precios que alimenta el cálculo de costos, consulta el desglose de precios de GPT-5.5. Para un problema relacionado de atribución de facturación en herramientas para desarrolladores, consulta la facturación de uso de GitHub Copilot para equipos de API. Para los conceptos básicos, revisa la referencia oficial de la API de OpenAI. El panel de OpenAI muestra gasto diario, desglose por modelo y límite de uso. Eso funciona si tienes una sola app, un solo cliente y una sola función. Deja de ser suficiente cuando tienes: múltiples funciones; múltiples clientes; múltiples entornos; múltiples desarrolladores; jobs en background; workers o colas; distintos productos usando la misma organización. Lo que falta: El panel puede decir que ayer gastaste $312 en GPT-5.5. No te dice si vino de un cliente usando el chat de soporte 50,000 veces o de un job nocturno que resumió toda tu base de conocimiento por error. OpenAI etiqueta por clave de API y modelo. No etiqueta por función, ruta, cliente ni entorno. Si necesitas esas dimensiones, debes capturarlas en tu aplicación. Los datos de uso pueden tardar decenas de minutos o algunas horas. Para cuando un bucle descontrolado aparece en el panel, ya consumió presupuesto. Para alertas operativas necesitas datos propios casi en tiempo real. OpenAI ofrece límites y notificaciones generales. No hay una alerta nativa del tipo: “avísame si /api/v1/chat/answer supera $50 en una hora”. Eso debes construirlo con tus propios logs y consultas. Si vendes SaaS B2B con funciones de IA, necesitas responder: “¿cuánto me cuesta el cliente X este mes?” Sin ese dato, no puedes calcular margen bruto por cliente ni decidir cuotas, precios o upsells. Las claves de proyecto permiten separar uso por proyecto, pero no por función, cliente o ruta. La API de uso de OpenAI devuelve datos agregados por proyecto, no por solicitud. El patrón es claro: el panel nativo responde una pregunta financiera. Tú necesitas responder una pregunta de producto. Cada solicitud a OpenAI debe generar un evento etiquetado. Ese evento es tu unidad de análisis. Esquema mínimo recomendado: Columna Tipo Ejemplo Por qué importa request_id uuid 7a91... Idempotencia, deduplicación, reintentos timestamp timestamptz 2026-05-06T14:23:01Z Series temporales y anomalías feature text soporte-chat Función del producto route text /api/v1/chat/answer Ruta HTTP o job customer_id text cliente_4291 Gasto por cliente environment text prod, staging, dev Separar costo interno de costo de cliente model text gpt-5.5, gpt-5.4-mini El precio depende del modelo prompt_tokens int 15234 Tokens de entrada completion_tokens int 812 Tokens de salida reasoning_tokens int 4500 Tokens de razonamiento facturados como salida cached_tokens int 12000 Tokens cacheados latency_ms int 2341 Correlación costo/experiencia cost_usd numeric(10,6) 0.045672 Costo calculado prompt_cache_key text sistema-v3 Seguimiento de caché error_code text null, 429 Evitar doble conteo en reintentos Calcula el costo cuando escribes el evento, no al consultar. Los precios pueden cambiar; el evento debe conservar la tarifa aplicada cuando ocurrió la solicitud. Ejemplo en Python: PRICING = { # USD por 1M de tokens, a partir de mayo de 2026 "gpt-5.5": {"input": 5.00, "cached": 2.50, "output": 30.00}, "gpt-5.5-pro": {"input": 30.00, "cached": 15.00, "output": 180.00}, "gpt-5.4": {"input": 2.50, "cached": 1.25, "output": 15.00}, "gpt-5.4-mini": {"input": 0.25, "cached": 0.125, "output": 2.00}, } def compute_cost_usd( model, prompt_tokens, cached_tokens, completion_tokens, reasoning_tokens ): rates = PRICING[model] uncached = max(0, prompt_tokens - cached_tokens) input_cost = (uncached * rates["input"]) / 1_000_000 cache_cost = (cached_tokens * rates["cached"]) / 1_000_000 output_cost = ( (completion_tokens + reasoning_tokens) * rates["output"] ) / 1_000_000 return round(input_cost + cache_cost + output_cost, 6) Los tokens de razonamiento cuentan como salida. La API los devuelve en: usage.completion_tokens_details.reasoning_tokens Súmalos a completion_tokens para calcular el costo. Si no lo haces, subestimarás el gasto en llamadas con razonamiento. Para ver la matemática completa, consulta el desglose de precios de GPT-5.5. Todas las llamadas a OpenAI deberían pasar por una única función. Ejemplo: import time import uuid import json import logging from openai import OpenAI client = OpenAI() logger = logging.getLogger("llm.cost") def call_with_attribution( *, feature, route, customer_id, environment, model, messages, **openai_kwargs ): request_id = str(uuid.uuid4()) started = time.time() error_code = None response = None try: response = client.chat.completions.create( model=model, messages=messages, **openai_kwargs ) except Exception as e: error_code = getattr(e, "code", "unknown_error") raise finally: latency_ms = int((time.time() - started) * 1000) u = response.usage if response else None prompt_tokens = getattr(u, "prompt_tokens", 0) completion_tokens = getattr(u, "completion_tokens", 0) cached_tokens = ( getattr( getattr(u, "prompt_tokens_details", None), "cached_tokens", 0 ) or 0 ) reasoning_tokens = ( getattr( getattr(u, "completion_tokens_details", None), "reasoning_tokens", 0 ) or 0 ) cost_usd = compute_cost_usd( model, prompt_tokens, cached_tokens, completion_tokens, reasoning_tokens ) logger.info(json.dumps({ "event": "openai.request", "request_id": request_id, "feature": feature, "route": route, "customer_id": customer_id, "environment": environment, "model": model, "prompt_tokens": prompt_tokens, "completion_tokens": completion_tokens, "reasoning_tokens": reasoning_tokens, "cached_tokens": cached_tokens, "latency_ms": latency_ms, "cost_usd": cost_usd, "error_code": error_code, })) return response Ese wrapper es tu punto de control. Cada función del producto lo llama. Cada llamada emite una línea JSON. Desde ahí, envía los logs a BigQuery, ClickHouse, Snowflake o Postgres usando tu pipeline existente: Vector, Fluent Bit, Logstash, OTLP collector o equivalente. Para Node.js, el patrón es el mismo: envolver el SDK; recibir metadatos obligatorios; capturar response.usage; calcular cost_usd; emitir un evento JSON; publicarlo en stdout, Kafka, NATS, Pub/Sub o tu sistema de logs. Busca en tu base de código: OpenAI( client.chat.completions.create Cada llamada directa debe convertirse en: call_with_attribution( feature="soporte-chat", route="/api/v1/chat/answer", customer_id=customer.id, environment="prod", model="gpt-5.5", messages=messages, ) Haz que feature, route, customer_id y environment sean obligatorios. No uses unknown como valor por defecto. Si falta un campo, lanza error. Registra una línea JSON por solicitud: { "event": "openai.request", "feature": "soporte-chat", "route": "/api/v1/chat/answer", "customer_id": "cliente_4291", "environment": "prod", "model": "gpt-5.5", "prompt_tokens": 15234, "completion_tokens": 812, "reasoning_tokens": 4500, "cached_tokens": 12000, "latency_ms": 2341, "cost_usd": 0.045672 } Usa INFO para estos eventos y evita mezclarlos con logs de depuración. Ejemplo de consulta: SELECT feature, DATE_TRUNC(timestamp, DAY) AS day, COUNT(*) AS requests, SUM(cost_usd) AS spend_usd, SUM(prompt_tokens + completion_tokens) AS tokens, AVG(latency_ms) AS avg_latency_ms, SUM(cached_tokens) / NULLIF(SUM(prompt_tokens), 0) AS cache_hit_rate FROM openai_events WHERE environment = 'prod' AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY) GROUP BY feature, day ORDER BY day DESC, spend_usd DESC; Con esto puedes ver qué función consume más presupuesto y cómo evoluciona en el tiempo. Conecta Grafana, Metabase, Looker o Superset a la tabla y crea tres vistas: gasto por función en el tiempo; gasto por cliente en el tiempo; top 20 rutas por gasto de ayer. Ese panel debería ser parte de tus operaciones diarias. Antes de desplegar, valida que el wrapper produce eventos correctos. Si el esquema está mal, tus dashboards mentirán. Usa Apidog para probar el flujo extremo a extremo: Crea un escenario que llame a tu endpoint de IA con customer_id y feature conocidos. Captura la respuesta y el log emitido por stdout, OTLP o tu endpoint de logs. Agrega aserciones para verificar que el log incluye: feature; route; customer_id; cost_usd > 0; prompt_tokens > 0. Ejecuta el mismo escenario en staging y producción usando variables de entorno. Reproduce solicitudes etiquetadas y valida que los reintentos no duplican costo. Para enfoques más amplios de pruebas de API, consulta herramientas de prueba de API para ingenieros de control de calidad. Para combinar esto con un enfoque contract-first, revisa desarrollo de API "contract-first". Crea claves de proyecto separadas por entorno o función: prod-support-chat prod-summarization staging-all Configura límites estrictos en OpenAI para que una función no pueda agotar todo el presupuesto de la organización. Después, añade alertas propias desde tu almacén de datos. Por ejemplo: alertar si una función supera 3 veces su gasto horario promedio móvil de 7 días. Puedes enviar la alerta a PagerDuty, Opsgenie o Slack. El disparador debe venir de tus datos, no del panel de OpenAI. GPT-5.5 cobra el 50% de la tarifa de entrada por tokens cacheados. Para aprovecharlo: mantén el prompt del sistema estable; coloca variables por solicitud al final; rastrea cache_hit_rate por función; alerta si una modificación de prompt reduce la tasa de acierto. La documentación oficial de caché de prompts de OpenAI explica las reglas de elegibilidad. Todo lo que no necesita respuesta síncrona debería pasar por la API por lotes: resúmenes nocturnos; evaluaciones; reprocesamiento de documentos; backfills; embeddings offline. Etiqueta esos eventos con batch_job_id para atribuirlos a la carga de trabajo original. GPT-5.5 Thinking usa niveles de reasoning.effort. Más esfuerzo implica más tokens de salida. Audita tus funciones: ¿usas medium donde low sería suficiente? ¿la calidad mejora lo suficiente para justificar el costo? ¿puedes hacer A/B testing entre niveles? Para más detalles, consulta cómo usar la API de GPT-5.5. Los prompts largos son caros. RAG con un presupuesto de recuperación ajustado suele ser mejor que meter toda la base de conocimiento en el contexto. Rastrea: AVG(prompt_tokens) BY feature Si sube semana tras semana sin cambios funcionales, tu prompt se está inflando. OpenAI aplica un multiplicador de entrada de 2x y un multiplicador de salida de 1.5x en solicitudes que superan los 272K tokens. Agrega una guarda: if prompt_tokens > 250_000: logger.warning("Prompt cerca del umbral de 272K tokens") Para detalles de precios, consulta la publicación sobre precios de GPT-5.5. Si vendes B2B, necesitas cuotas por cliente. Flujo recomendado: calcula gasto mensual por customer_id; consulta ese gasto antes de cada llamada; si supera la cuota, devuelve 429; incluye un mensaje claro de límite mensual; ofrece una acción de upgrade o contacto con ventas. Ejemplo: { "error": "ai_quota_exceeded", "message": "Cuota mensual de IA excedida" } Esto convierte las funciones de IA de un riesgo de margen en una unidad de producto controlable. Evita estos patrones: contar tokens de razonamiento como entrada; confiar en el panel de OpenAI para alertas en tiempo real; etiquetar a nivel global del SDK en lugar del sitio de llamada; olvidar cron jobs, workers y webhooks; muestrear solicitudes; permitir customer_id = null; calcular costos con una tabla de precios desactualizada; no deduplicar reintentos; mezclar logs de costo con logs de debug. Para jobs internos, usa rutas sintéticas: cron:nightly-summarize queue:image-caption worker:document-indexing No siempre necesitas construir todo desde cero. Enfoque Lo que hace bien Lo que cuesta Cuándo usar API de uso de OpenAI Nativa, sin configuración, precisa para conciliación Gratis Un proyecto, una función, sin atribución por cliente Helicone Proxy fácil, dashboards, caché, costos por usuario Nivel gratuito; pago desde $20/mes Quieres un panel alojado rápido Langfuse Código abierto, trazas + costo, autoalojado o cloud Autoalojado gratis; cloud desde $29/mes Quieres observabilidad open source LangSmith Integración con LangChain, evaluación + costo Pago desde $39/usuario/mes Ya usas LangChain Almacén de datos propio Control total, sin proxy, dimensiones personalizadas Tiempo de ingeniería Cargas grandes, compliance o residencia de datos Consideraciones: Un proxy añade un salto en la ruta crítica. Un stack autoalojado te da control, pero debes operarlo. Un almacén de datos propio se integra mejor con tu stack, pero tú mantienes consultas y alertas. La API de uso nativa sirve para conciliación, no para atribución granular. Para más contexto, la guía de Helicone sobre seguimiento de costos de LLM explica el enfoque basado en proxy. La documentación de Langfuse sobre seguimiento de costos cubre la ruta open source. Si operas esto a escala de plataforma, revisa plataformas de API para arquitectura de microservicios. Una empresa vende inteligencia de ventas. Cada cliente activa llamadas a GPT-5.5 al generar informes. Sin atribución, solo sabe que gasta $80,000 al mes en OpenAI. Con atribución por cliente, descubre que el 12% de los clientes genera el 71% del gasto. Con esos datos puede introducir: precios escalonados; cuotas suaves en planes bajos; cargos por exceso; upsells basados en uso real. Una organización da a cada desarrollador acceso a un asistente privado con GPT-5.5. Usando customer_id = dev_email, plataforma detecta que tres desarrolladores concentran 50% del gasto. Dos tenían agentes automatizados corriendo en bucle. Desactivarlos ahorra $1,800 al mes. El tercero sí tenía uso legítimo, así que recibe una cuota mayor basada en datos. Un equipo de producto quiere lanzar una función de resumen. Para estimar costo, usa datos históricos: tokens promedio de prompt; tokens promedio de salida; llamadas esperadas por usuario activo; usuarios activos esperados. Resultado: $0.04 por usuario activo por día $1.20 por usuario activo por mes Con esa información, el equipo puede fijar el precio de la función en $5 por usuario al mes y justificar el margen. No puedes gestionar lo que no puedes medir. El panel de facturación de OpenAI responde una pregunta financiera. La atribución por función, cliente y ruta responde la pregunta de producto. Implementa el flujo así: etiqueta cada solicitud; calcula costo al escribir el evento; usa claves separadas por entorno o función; configura límites nativos en OpenAI; agrega alertas desde tu almacén de datos; valida el wrapper con Apidog; audita prompts, caché y esfuerzo de razonamiento periódicamente. Descarga Apidog y úsalo para verificar tu wrapper de atribución de costos de extremo a extremo. Envía solicitudes etiquetadas, valida la carga útil del log y reproduce escenarios en distintos entornos antes de confiar en los dashboards. Para lecturas relacionadas, consulta el desglose de precios de GPT-5.5 y la facturación de uso de GitHub Copilot para equipos de API. Como salida. La API los devuelve en: usage.completion_tokens_details.reasoning_tokens Súmalos a completion_tokens cuando calcules el costo. Para multiplicadores y precios, consulta el desglose de precios de GPT-5.5. response.usage frente al panel de OpenAI? Los recuentos de tokens en response.usage coinciden con el panel. La desviación aparece si calculas costos con una tabla de tarifas desactualizada. Versiona tu tabla de precios y actualízala cuando OpenAI cambie tarifas. Solo parcialmente. Las claves de proyecto dan una dimensión: proyecto. No dan función, cliente ni ruta. Úsalas para separar entornos y establecer límites; usa metadatos de aplicación para la atribución granular. Si una solicitud falla antes de ejecutar el modelo, normalmente no hay usage y no se registra costo. Si la solicitud sí se ejecuta y luego tu aplicación reintenta, puedes duplicar el costo si no deduplicas. Usa el mismo request_id en reintentos idempotentes y deduplica al escribir. Tiene retraso de decenas de minutos. Úsala para conciliación mensual. Para alertas o interruptores de emergencia, usa tus propios eventos. No. El volumen es pequeño: una línea JSON por solicitud. El muestreo rompe la atribución por cliente y ruta. Sí. Agrega una columna: provider Ejemplos: openai anthropic google deepseek El wrapper cambia por proveedor, pero el almacén de datos y los dashboards pueden mantenerse. Para comparar precios, consulta precios de la API de DeepSeek V4. Sí, pero la fórmula cambia. Embeddings: costo por token de entrada. Imágenes: costo por imagen y resolución. Agrega una columna endpoint: chat embeddings image Después ramifica el cálculo de costos según el endpoint.