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

Tu factura de OpenAI dice que gastaste $4,237 el mes pasado. No te dice que $3,100 de eso provinieron de un único endpoint de resumen descontrolado, $700 de un cliente que te paga $50 al mes, y $437 de una función que nadie usa. El panel de control oculta la imagen que necesitas para tomar cualquier decisión de precios, capacidad u hoja de ruta.

Esta guía te muestra cómo realizar la atribución de costos de la API de OpenAI de la manera correcta: etiqueta cada solicitud con metadatos, agrega el gasto por función, ruta y cliente, establece límites de presupuesto por clave y diseña prompts para que el costo deje de ser una línea misteriosa. Si lanzas funciones LLM, este es el trabajo que convierte la IA de un gasto descontrolado en un costo de producto gestionado.

En Resumen (TL;DR)

Etiqueta cada llamada a la API de OpenAI con metadatos estructurados (función, ruta, customer_id, entorno), emite una línea de log estructurada por solicitud que capture el recuento de tokens y el costo calculado, luego agrégala por etiqueta en tu almacén de datos. Establece límites de presupuesto por clave en el panel de control de OpenAI, configura alertas sobre anomalías de gasto por hora y valida el wrapper de extremo a extremo con pruebas de escenario de Apidog antes de confiar en los números.

Introducción

Lanzas una nueva función de IA el martes. Para el viernes por la mañana, tu CFO te envía un DM preguntando por qué la línea de OpenAI subió un 40 por ciento. Abres el panel de control. Muestra que el gasto total está subiendo. No muestra qué función, qué cliente o qué ruta es responsable. Empiezas a adivinar.

Esta es la brecha que encuentran todos los equipos que ejecutan cargas de trabajo LLM en producción. La interfaz de facturación de OpenAI está diseñada para cuentas por pagar, no para la atribución de ingeniería. Ves totales diarios, desgloses por modelo y eso es todo. No ves la forma de la solicitud, el cliente que la activó o la función que llamó al modelo.

La solución es simple en concepto e implacable en la ejecución. Envuelves cada llamada a la API con una capa de metadatos. Registras cada solicitud en un almacenamiento estructurado. Agregas por etiqueta. Estableces límites. Alertar sobre las diferencias. Al final de esta publicación, tendrás un modelo de datos concreto, dos ejemplos de código funcionando, un flujo de trabajo de verificación con Apidog y una comparación de herramientas para que puedas decidir si construir, comprar o usar la API de uso de OpenAI directamente.

Para el contexto de precios que impulsa tu cálculo de costos, consulta el desglose de precios de GPT-5.5. Para un problema de atribución de facturación relacionado en el lado de las herramientas para desarrolladores, consulta la facturación de uso de GitHub Copilot para equipos de API. Para los conceptos básicos de la API de OpenAI, consulta la referencia oficial de la API de OpenAI.

Por qué el panel de facturación de OpenAI no es suficiente

Abre la página de facturación de OpenAI ahora mismo. Verás un gráfico de gasto diario, un desglose por modelo y un límite de uso. Esa es toda la superficie. Funciona bien si tienes una aplicación, un cliente y una función. En el momento en que tengas cualquiera de: múltiples funciones en el mismo producto, múltiples clientes, múltiples entornos o múltiples desarrolladores, el panel deja de ser útil.

Aquí está lo que falta.

Gasto total sin contexto. El panel te dice que ayer gastaste $312 en GPT-5.5. No te dice si eso provino de un cliente que accedió a tu endpoint de chat de soporte 50,000 veces o de un trabajo en segundo plano que resumió toda tu base de conocimientos porque alguien dejó una bandera activada. Ambos se ven idénticos en el gráfico.

Sin desglose por función. OpenAI etiqueta las solicitudes por clave de API y modelo. No las etiqueta por tu función, ruta, ID de cliente o entorno. Si quieres algo de eso, lo construyes tú mismo. No hay una dimensión nativa para el análisis de productos en el panel de control.

Retraso en los informes. Los datos de uso aparecen con un retraso medido en decenas de minutos a unas pocas horas. Para cuando un bucle descontrolado aparece en tu panel, ya ha consumido una tarjeta de crédito. Necesitas seguimiento en tiempo real, no un gráfico histórico.

Sin primitivas de alerta. OpenAI te da un límite de presupuesto por organización y un correo electrónico de notificación suave. No hay una alerta por clave, un umbral por función, ni detección de anomalías. Si quieres que te notifique "si el endpoint de chat excede los $50 en una hora", lo construyes tú mismo.

Sin atribución de clientes. Si vendes SaaS B2B con una función de IA, necesitas saber qué cliente generó qué gasto para poder fijar precios, limitar o vender más. El panel no puede responder "¿cuánto me está costando el cliente X este mes?". Tu equipo financiero necesita ese número para calcular el margen bruto por cliente. Sin él, tus economías unitarias son conjeturas.

Las cuentas de servicio y las claves a nivel de proyecto ayudan, pero solo parcialmente. Las claves de proyecto de OpenAI te permiten dividir el uso por proyecto. Eso te da un nivel de atribución. No te da por función, por cliente o por ruta. Todavía necesitas metadatos a nivel de aplicación para responder las preguntas importantes. La API de uso de OpenAI devuelve datos agregados por proyecto, no por solicitud.

El patrón se repite en todos los equipos que lanzan características LLM a escala. El hilo de Dev.to "OpenAI te dice lo que gastaste. No dónde. Así que construí un panel" se volvió viral porque puso nombre al problema en voz alta: no se puede gestionar lo que no se puede medir. El panel nativo responde a una pregunta financiera. Tú necesitas responder a una pregunta de producto.

El modelo de datos de atribución de costos

La atribución de costos comienza con una decisión: cada solicitud de OpenAI genera un evento etiquetado que se escribe en tu almacén de datos. Ese evento es tu unidad de análisis. Si el esquema es correcto, el resto del trabajo, los paneles, las alertas, los límites, se convierten en una consulta SQL.

Aquí está el esquema mínimo que necesitas.

Calcula el costo en el momento de la escritura, no en el momento de la consulta. Los precios cambian; quieres un número fijo que refleje la tarifa que pagaste el día en que ocurrió la solicitud. La lógica de cálculo para GPT-5.5 se ve así:

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 de OpenAI los devuelve en usage.completion_tokens_details.reasoning_tokens, pero se facturan a la tarifa de salida. Si te equivocas en esto, subestimarás el costo en cada llamada en modo Pensamiento. Para ver la matemática de precios completa, consulta el desglose de precios de GPT-5.5.

Ahora, envuelve el cliente de OpenAI. Cada llamada pasa por una función. Esa función toma metadatos, realiza la solicitud y escribe el evento.

import time, uuid, json, 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 único wrapper es tu superficie de atribución de costos. Cada característica de tu producto lo llama. La línea de log estructurada es tu entrada al almacén de datos. Desde aquí, envía los logs a BigQuery, ClickHouse, Snowflake o Postgres a través de tu pipeline de logs existente (Vector, Fluent Bit, Logstash, colector OTLP). No hay un segundo pipeline. No hay un servicio extra.

Para los equipos de Node.js, la forma es idéntica. Envuelve el SDK de OpenAI en una función que tome metadatos, capture response.usage, calcule el costo y escriba una línea JSON. Si tu plataforma ya ejecuta un bus de eventos (Kafka, NATS, Pub/Sub), publica el evento allí en lugar de stdout y deja que los consumidores descendentes lo distribuyan a tu almacén de datos y a tu sistema de alertas.

Conecta el seguimiento de costos y pruébalo con Apidog

Tienes el esquema y el wrapper. Ahora, conviértelo en algo operativo. Seis pasos.

1. Reemplaza las llamadas directas a OpenAI por el wrapper. Busca en tu base de código OpenAI( y client.chat.completions.create. Cada coincidencia se convierte en una llamada a call_with_attribution(...). Haz que feature y route sean argumentos obligatorios. Pásalos en el sitio de la llamada, no desde una global. Si olvidas pasarlos, la función debería lanzar un error, no establecer un valor predeterminado a "unknown".

2. Emite logs estructurados. Registra en la salida estándar como JSON, una línea por evento. Establece el nivel del logger en INFO específicamente para estos eventos. No los mezcles con ruido de depuración. Si ya usas un logger estructurado (structlog, pino, winston), conéctalo a este.

3. Agrega por función en tu almacén de datos. Una vez que los eventos llegan a BigQuery o ClickHouse, las consultas se escriben solas:

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;

4. Grafica el gasto por ruta. Apunta Grafana, Metabase, Looker o Superset a la tabla. Construye tres vistas: gasto por función a lo largo del tiempo, gasto por cliente a lo largo del tiempo y una tabla de las 20 rutas principales ordenadas por el gasto de ayer. Ese es tu panel de operaciones diario.

5. Prueba el wrapper con Apidog antes de implementarlo. Este es el paso que la mayoría de los equipos se saltan y luego lamentan. Tu wrapper escribe logs estructurados. Si el esquema es incorrecto, tu almacén de datos estará silenciosamente incorrecto y los paneles mentirán. Usa Apidog para realizar pruebas de extremo a extremo contra tu servicio:

• Crea un escenario en Apidog que envíe una solicitud a tu endpoint de IA con un customer_id y una feature conocidos.
• Captura la respuesta y la emisión de logs por canal lateral (stdout, OTLP, tu endpoint de logs).
• Usa las aserciones de respuesta de Apidog para verificar que la carga útil del log contiene la feature, route, customer_id esperadas, y que cost_usd > 0 y prompt_tokens > 0.
• Ejecuta el mismo escenario en entornos de staging y producción usando variables de entorno de Apidog.
• Reproduce solicitudes etiquetadas y asegura que las llamadas reintentadas no cuenten el costo dos veces (tu wrapper debe reutilizar request_id en el reintento).

Para enfoques de prueba de API más amplios que se ajusten a este paso de verificación, consulta herramientas de prueba de API para ingenieros de control de calidad. Para el enfoque "contract-first" que se combina con la cobertura de atribución de costos, consulta desarrollo de API "contract-first".

6. Establece límites de presupuesto y alertas por clave. OpenAI te permite crear una clave de proyecto por entorno o por función. Úsala. Crea una clave prod-support-chat, una clave prod-summarization, una clave staging-all. Establece límites estrictos en el panel de control de OpenAI para que un bucle descontrolado en una función no pueda agotar todo el presupuesto de la organización. Superpón tus propias alertas: una consulta SQL que se ejecute cada 10 minutos y te avise si alguna función excede 3 veces su gasto horario promedio móvil de 7 días. PagerDuty, Opsgenie o un webhook de Slack funcionan; el disparador proviene de tu almacén de datos, no de OpenAI.

La combinación de límites de clave nativos más alertas basadas en el almacén de datos te brinda dos capas de defensa. Los límites nativos son un respaldo contra el gasto catastrófico. Las alertas del almacén de datos detectan la deriva lenta antes de que se active el límite.

Técnicas avanzadas y consejos profesionales

Una vez que el pipeline básico esté funcionando, las optimizaciones seguirán.

Caché de prompts. GPT-5.5 cobra el 50 por ciento de la tarifa de entrada por los tokens cacheados. Estructura tu prompt del sistema como un prefijo estable y coloca las variables por solicitud al final. Las tasas de acierto de caché superiores al 70 por ciento en cargas de trabajo de chat son normales una vez que haces esto. Rastrea cache_hit_rate por función en tu panel para que puedas ver cuándo un cambio de prompt hunde tu tasa de acierto. La documentación oficial de caché de prompts de OpenAI cubre las reglas de elegibilidad.

API por lotes para trabajo offline. Cualquier cosa que no necesite una respuesta síncrona pasa por la API por lotes para un descuento del 50 por ciento. Resúmenes nocturnos, ejecuciones de evaluación, rellenos de incrustaciones, reprocesamiento de documentos. El envoltorio de costos sigue aplicándose; llama al endpoint por lotes y etiqueta los eventos con batch_job_id para que puedas atribuirlos de nuevo a la carga de trabajo de origen.

Ajuste del esfuerzo de razonamiento. GPT-5.5 Thinking es el mismo modelo con un reasoning.effort más alto. Cada nivel de esfuerzo multiplica los tokens de salida. Audita tus características: ¿estás ejecutando medium donde low pasaría los estándares de calidad? Realiza una prueba A/B, rastrea la calidad y el costo, y envía la opción más barata si la calidad se mantiene. Para cálculos más profundos, consulta cómo usar la API de GPT-5.5.

Disciplina en la ventana de contexto. Los prompts largos son caros. RAG con un presupuesto de recuperación ajustado es mejor que meter toda la base de conocimiento en la ventana de contexto. Rastrea el promedio de prompt_tokens por función; si aumenta semana tras semana sin un cambio de función, tu prompt se está inflando.

Cuidado con el límite de 272K tokens de GPT-5.5. 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 en tu wrapper que registre una advertencia cuando prompt_tokens > 250000 para que puedas detectar prompts que están a punto de alcanzar el límite. Para obtener detalles sobre precios, consulta la publicación sobre precios de GPT-5.5.

Límites de gasto por cliente. Si vendes B2B y tu contrato incluye una función respaldada por LLM, necesitas un límite por cliente. Calcula el gasto continuo por customer_id desde tu almacén de datos y haz que tu aplicación lo verifique antes de cada llamada. Si se alcanza el límite, devuelve un 429 con un mensaje "cuota mensual de IA excedida" y una llamada a la acción de facturación. Esto es lo que convierte las funciones de IA de un riesgo de margen en un producto de margen.

Errores comunes a evitar.

• Contar los tokens de razonamiento como entrada. Son salida. Factúralos a la tarifa de salida.
• Confiar en el panel de control de OpenAI para decisiones en tiempo real. Tiene un retraso. Usa tu propio almacén de datos.
• Etiquetar a nivel de SDK en lugar de en el sitio de la llamada. Las etiquetas pertenecen a la característica, no al cliente.
• Olvidar etiquetar los trabajos en segundo plano. Las tareas programadas (cron jobs), los trabajadores de cola y los webhooks realizan las mismas llamadas a OpenAI; etiquétalos con una route sintética como cron:nightly-summarize o queue:image-caption.
• Muestreo. No muestrees. Registra cada solicitud. El volumen de datos es trivial; la precisión de la atribución no lo es.
• Dejar que customer_id sea nulo. Si no conoces al cliente, registra internal o system, nunca nulo. Nulo se convierte en un agujero negro de atribución.

Alternativas y herramientas

No tienes que construir esto tú mismo. Aquí está la comparación honesta.

Consideraciones a tener en cuenta. Un proxy (Helicone) añade un salto en tu ruta crítica; el costo de latencia es pequeño pero real, y dependes de su disponibilidad. Un stack de observabilidad autoalojado (Langfuse) te da control total pero lo operas tú. La ruta del almacén de datos personalizado es a la que la mayoría de los equipos grandes llegan; se integra con el resto de tu stack de datos, pero tú escribes las consultas y las alertas. La API de uso nativa está bien si tus necesidades son simples, inútil una vez que no lo son.

Para una lectura más profunda sobre cómo se ve una buena observabilidad de costos de LLM en la práctica, la guía del equipo de Helicone sobre el seguimiento de costos de LLM explica el enfoque basado en proxy. La documentación de Langfuse sobre el seguimiento de costos cubre la ruta de código abierto.

Si operas esto a escala de plataforma, los patrones se generalizan. Consulta plataformas de API para arquitectura de microservicios para ver cómo los wrappers de atribución de costos encajan en una estrategia de malla de servicios.

Casos de uso en el mundo real

SaaS B2B con gasto de LLM por cliente. Una empresa vende un producto de inteligencia de ventas. Cada cliente activa llamadas a GPT-5.5 cuando solicita un informe. Sin atribución, la empresa sabe que gasta $80,000 al mes en OpenAI. Con la atribución por cliente, descubre que el 12 por ciento de los clientes generan el 71 por ciento del gasto. Introduce precios escalonados, cuotas suaves en el nivel más bajo y un cargo por exceso por puesto. El margen bruto de la función de IA pasa del 41 al 73 por ciento en un trimestre.

Seguimiento de herramientas internas para desarrolladores. Una organización de ingeniería da a cada desarrollador acceso a un asistente de chat privado de GPT-5.5. Con etiquetas por desarrollador (customer_id se convierte en dev_email), la ingeniería de plataforma ve que tres desarrolladores representan el 50 por ciento del gasto interno. Dos de ellos están ejecutando bucles de agente automatizados que olvidaron desactivar. Desactivarlos ahorra $1,800 al mes. El tercero está realizando un trabajo legítimo; los datos justifican una cuota más alta para ellos en toda la organización.

Previsión de gastos de características de IA. Un equipo de producto quiere lanzar una nueva función de resumen. El gerente de producto no sabe cómo pronosticar el costo. Con datos históricos por característica, el equipo construye un modelo: tokens promedio de prompt por llamada, tokens promedio de salida, llamadas esperadas por usuario activo, usuarios activos esperados. El pronóstico resulta ser: $0.04 por usuario activo por día, o $1.20 por mes. El equipo de precios fija el precio de la función en $5 por usuario por mes. Finanzas lo aprueba porque la economía unitaria es visible.

Conclusión

No se puede gestionar lo que no se puede medir. El panel de facturación de OpenAI responde a una pregunta financiera. La atribución por función, por cliente y por ruta responde a la pregunta del producto. Construye el wrapper, registra el evento, consulta el almacén de datos, y tu línea de IA deja de ser un misterio.

Cinco puntos clave:

• Etiqueta cada solicitud con la característica, ruta, customer_id y entorno. Haz que las etiquetas sean obligatorias en el sitio de la llamada.
• Calcula el costo en el momento de la escritura para que los datos históricos reflejen la tarifa que pagaste ese día.
• Usa una clave de proyecto por entorno y establece límites estrictos en el panel de OpenAI como respaldo.
• Superpón alertas basadas en el almacén de datos sobre los límites nativos para detectar la deriva lenta antes de que se active el límite.
• Prueba el wrapper con Apidog antes de implementarlo; etiquetas incorrectas significan errores de atribución silenciosos.
• Audita el esfuerzo de razonamiento y el tamaño del prompt trimestralmente; la optimización más barata es la que mantiene la calidad constante.
• Rastrea la tasa de aciertos de caché por característica para que un cambio de prompt no duplique silenciosamente tu costo de entrada.

Descarga Apidog y úsalo para verificar tu wrapper de atribución de costos de extremo a extremo. Impulsa tus endpoints de IA con solicitudes etiquetadas, verifica la forma de la carga útil del log y reproduce escenarios en todos los entornos para que los datos en los que confía tu almacén sean los datos que escribieron tus ingenieros.

Para lecturas relacionadas con la gestión de costos, consulta el desglose de precios de GPT-5.5 y la facturación de uso de GitHub Copilot para equipos de API.

Preguntas Frecuentes

¿Los tokens de razonamiento cuentan como entrada o salida para la facturación?Los tokens de razonamiento se facturan a la tarifa de salida. La API de OpenAI los devuelve bajo usage.completion_tokens_details.reasoning_tokens. Súmalos a completion_tokens cuando calcules el costo. Para los multiplicadores por esfuerzo, consulta el desglose de precios de GPT-5.5.

¿Qué tan preciso es response.usage en comparación con el panel de OpenAI?Los recuentos de tokens en response.usage coinciden con el panel hasta el token. Los cambios de precios pueden causar una pequeña desviación si calculas el costo a partir de una tabla de tarifas obsoleta; fija la tarifa por modelo y actualízala el día en que OpenAI cambie los precios.

¿Puedo hacer atribución solo con claves de proyecto de OpenAI?Las claves de proyecto te dan una dimensión de atribución: por proyecto. No te dan por característica, por cliente o por ruta. Usa las claves de proyecto para dividir entornos y establecer límites de presupuesto; usa los metadatos a nivel de aplicación para todo lo demás.

¿Qué pasa con los reintentos y los errores de límite de tasa? ¿Cuentan el costo dos veces?Una solicitud que falla antes de que se ejecute el modelo (4xx, error de red antes de la finalización) no devuelve un objeto usage, por lo que no se registra ningún costo. Una solicitud que se ejecuta correctamente y luego se reintenta en la capa de la aplicación se registrará dos veces a menos que reutilices request_id. Los reintentos idempotentes deben pasar el mismo request_id y tu wrapper debe deduplicar en la escritura.

¿Qué tan rápido devuelve datos la API de uso de OpenAI?La API de uso tiene un retraso de decenas de minutos. Para decisiones en tiempo real (alertas, interruptores de emergencia), usa tu propio almacén de datos. Para la conciliación mensual, la API de uso está bien y coincide con tu factura.

¿Debo muestrear las solicitudes para reducir el volumen de logs?No. El volumen de datos es pequeño (una línea JSON por solicitud), y el muestreo rompe la atribución por cliente y por ruta. Registra cada solicitud.

¿Puedo usar este enfoque para otros proveedores de LLM?Sí. El esquema se generaliza. Agrega una columna provider (openai, anthropic, google, deepseek) y una tabla de precios por proveedor. El wrapper es específico del proveedor; el almacén de datos y los paneles no lo son. Para un punto de comparación, consulta precios de la API de DeepSeek V4.

¿Funciona esto también para las llamadas de incrustaciones y generación de imágenes?Sí, con matemáticas de costos específicas del proveedor. Las incrustaciones se facturan por token de entrada a una tarifa plana; las imágenes se facturan por imagen a una tarifa por resolución. Agrega endpoint (por ejemplo, chat, embeddings, image) al esquema y ramifica tu cálculo de costos en él.