¿Las herramientas IA usan tus créditos sin decirte para qué?

¿Cuándo fue la última vez que revisaste exactamente qué tokens pagaste en tu sesión de Claude Code o Cursor? No el total del mes — sesión por sesión, request por request. Yo tampoco. Y esa desatención me costó más de lo que quiero admitir.

Hace unas semanas empecé a investigar Gas Town, una herramienta que se promociona como wrapper sobre LLMs para flujos de trabajo específicos. La pregunta que circulaba en algunos foros era directa: ¿Gas Town 'roba' créditos de los usuarios para entrenar o mejorar sus propios modelos? Spoiler: no encontré evidencia de robo. Encontré algo más incómodo — una opacidad tan bien diseñada que hace que la pregunta del robo sea casi irrelevante.

Herramientas IA que usan tus créditos: el problema real no es el robo

Cuando usás Claude Code, Cursor, Cline, o cualquier wrapper sobre una API de LLM, estás en una cadena de abstracción que tiene capas. Muchas capas. Y en cada capa puede haber tokens que vos pagás pero que no controlás.

El modelo básico funciona así:

El problema está en ese "system prompt oculto". Cada herramienta inyecta contexto adicional antes de mandar tu request. Contexto que vos no ves, no controlaste, y sí pagás.

Ejemplo concreto: si Cursor inyecta 2.000 tokens de context de tu codebase más 800 tokens de system prompt propio antes de mandarte el request, y vos pensás que enviaste 300 tokens — estás pagando casi 10x lo que creías.

Eso no es robo. Es el producto funcionando. Pero nadie te lo explica antes de activar la tarjeta.

Cómo auditè mis propios logs (y lo que encontré)

La investigación sobre Gas Town me picó el bichito. Fui directo a Anthropic Console y empecé a filtrar por fecha y modelo.

# Si tenés acceso a la API directamente, podés auditar con esto
# Primero, obtené tu usage del mes
curl https://api.anthropic.com/v1/usage \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

# El output te da totales, pero no el desglose por herramienta
# Para eso necesitás comparar timestamps con tus sesiones reales

El primer problema: la API de Anthropic no te dice qué aplicación hizo cada request. Solo timestamp, modelo y tokens. Si usás Claude Code y Cursor en el mismo día, tenés que reconstruir el mapa vos solo.

// Script que armé para correlacionar usage con sesiones de trabajo
// Guardé timestamps de cuando abría/cerraba cada herramienta

const correlateUsageWithSessions = (usageLogs, workSessions) => {
  return usageLogs.map(log => {
    // Buscamos en qué sesión de trabajo cae cada request
    const session = workSessions.find(session => 
      log.timestamp >= session.start && 
      log.timestamp <= session.end
    );
    
    return {
      ...log,
      // Si no matchea ninguna sesión, es sospechoso
      tool: session?.activeTool ?? 'DESCONOCIDO',
      suspicious: !session  // requests fuera de mis sesiones activas
    };
  });
};

// Lo que encontré: 23% de mis tokens del mes 
// vinieron de requests que no pude correlacionar con sesiones activas
// ¿Background sync? ¿Context refresh? ¿Telemetría? No sé.

Ese 23% me molestó. No puedo afirmar que sea robo — probablemente sean procesos legítimos de las herramientas (indexación de codebase, context warming, etc.). Pero tampoco lo puedo descartar, porque la documentación de esas herramientas no lo explica con la granularidad que necesito para decidir.

Cuando armé mi MCP server local hace unos meses, una de las ventajas que no menciono suficiente es exactamente esta: tenés control total sobre qué se manda y cuándo. Podés loggear cada request antes de que salga. Nada pasa sin que vos lo veas.

Los errores más comunes al asumir que "usaste X tokens"

Error 1: Confundir input tokens con lo que vos escribiste

Lo que vos escribís es una fracción del input real. El system prompt de la herramienta, el contexto del proyecto, el historial de conversación — todo eso suma. En una sesión típica de Cursor con un proyecto mediano, el contexto del codebase puede ser 10-15k tokens antes de que vos escribas una letra.

Error 2: No considerar los requests de "thinking" o planning

Algunas herramientas hacen múltiples llamadas internas para un solo resultado visible. Claude Code, por ejemplo, puede hacer un request de análisis antes del request de código. Vos ves una respuesta — pagaste dos.

Error 3: Asumir que "sin respuesta visible = sin costo"

Si una herramienta hace context refresh en background cuando abrís un archivo nuevo, ese request existe aunque vos no hayas pedido nada. Pagaste tokens para que la herramienta se prepare para vos. Legítimo, pero opaco.

Error 4: Ignorar los errores de red reintentados

Si un request falla y la herramienta reintenta automáticamente, pagaste el intento fallido también. Los LLMs cobran por tokens enviados, no por respuestas exitosas.

Este nivel de granularidad es el mismo que tuve que aprender cuando optimicé imágenes Docker — la diferencia entre lo que creés que está pasando y lo que realmente está pasando en cada capa es donde vive el problema.

Error 5: Sobre-atribuir todo a la herramienta y no al LLM

Acá está el contrapunto honesto. Muchas veces el costo alto no es opacidad maliciosa de la herramienta — es que el LLM necesita contexto para funcionar bien, y vos no querés el contexto reducido porque la calidad baja. Esto mismo aplica cuando diseñás agentes: el problema no siempre es la herramienta, a veces es que pedís más de lo que necesitás.

El caso específico de Gas Town

Volviendo al origen: ¿Gas Town roba créditos? La acusación específica era que la herramienta mandaba requests adicionales sin disclosure para "mejorar sus modelos".

Lo que investigué:

1. Sus términos de servicio son vagos en el punto de data usage. Dicen que pueden usar "usage data" para mejorar el servicio, pero no definen si eso incluye el contenido de los requests o solo metadata.

2. No encontré evidencia técnica de requests no solicitados en los análisis de tráfico que vi en foros especializados. Lo que sí encontré fueron requests de telemetría (metadata de uso, no contenido).

3. La opacidad de los system prompts es real. Gas Town no publica su system prompt. Eso significa que no sabés exactamente qué inyectan antes de tu request.

Mi conclusión: probablemente no roban créditos de forma directa. Pero los términos vagos más los system prompts ocultos más la telemetría no-opt-out crean un ecosistema donde la confianza es un acto de fe, no una decisión informada.

Y eso me molesta más que el robo hipotético. El robo lo podés probar y reclamar. La opacidad bien diseñada es simplemente... el estado del arte del SaaS moderno.

De la misma forma que las rutinas de Claude Code te hacen más productivo pero te alejan de entender qué está pasando debajo — la conveniencia siempre tiene un costo en visibilidad.

FAQ: Herramientas IA y el control de tus créditos

¿Cómo sé exactamente cuántos tokens estoy gastando con Claude Code o Cursor?

La respuesta corta: no podés saberlo con precisión total sin instrumentar vos mismo. Anthropic Console te da el total por mes y por modelo, pero no el desglose por herramienta o por sesión. Para auditar, necesitás comparar manualmente los timestamps de tu usage log con tus sesiones de trabajo, o interceptar el tráfico con un proxy local que loggee cada request antes de que salga.

¿Es legal que una herramienta inyecte tokens en mis requests sin decirme?

Sí, completamente legal. Cuando aceptás los términos de servicio de Cursor, Claude Code o cualquier wrapper, implícitamente aceptás que la herramienta puede agregar contexto a tus requests. Esto es técnicamente necesario para que funcionen. El problema no es la legalidad — es la falta de transparencia sobre cuánto y para qué.

¿Cómo audito si una herramienta está haciendo requests en background?

Usá un proxy de red como Charles Proxy o mitmproxy para interceptar el tráfico HTTPS de tu máquina. Filtrá por los dominios de API de los LLMs (api.anthropic.com, api.openai.com, etc.) y fijate qué requests salen cuando vos no estás activamente escribiendo. Si hay requests en background, los vas a ver ahí. También podés revisar los network logs del DevTools si la herramienta es web-based.

¿Debería preocuparme si no tengo acceso API directo y uso los planes de suscripción?

Si usás Claude.ai por suscripción mensual o Cursor con su propio plan, el modelo es distinto — no pagás por token sino una tarifa fija. Ahí la opacidad del uso importa menos económicamente, aunque sigue siendo relevante para privacidad (qué contexto mandás a los servidores de la herramienta). El problema del costo variable por tokens aplica principalmente cuando la herramienta usa tu propia API key.

¿Qué herramientas son más transparentes en el uso de tokens?

En mi experiencia, las herramientas open source que podés correr localmente (como algunas implementaciones de agentes con LangChain o tu propio MCP server) son las más transparentes porque podés ver el código que construye los prompts. Entre las comerciales, las que publican sus system prompts o tienen modo debug que muestra el request completo antes de enviarlo. Cline tiene un modo que te muestra el context window completo — eso es lo mínimo que deberían ofrecer todas.

¿Vale la pena el costo extra de tokens por la conveniencia de estas herramientas?

Generalmente sí, si las usás para lo correcto. El problema no es el costo extra per se — es no saber cuánto es "extra". Si Cursor inyecta 5k tokens de contexto y eso hace que la respuesta sea mejor, esos tokens valen. Si inyecta 5k tokens de boilerplate que no mejoran nada, es desperdicio. Sin visibilidad, no podés hacer esa evaluación. Mi recomendación: pasá una hora auditando tu uso real antes de renovar cualquier herramienta paga. Es como el display neumático que usa aire comprimido en vez de píxeles — a veces la abstracción es elegante, pero cuando falla, necesitás entender qué hay debajo.

Lo que haría diferente (y lo que les pediría a las herramientas)

No voy a decirte que dejes de usar Claude Code o Cursor. Los uso todos los días. Pero sí cambié algunos hábitos después de esta investigación:

1. Revisar usage logs una vez por semana, no una vez por mes cuando llega la factura.
2. Tener un proyecto de test con API key separada para probar herramientas nuevas sin contaminar mis métricas principales.
3. Pedir siempre un modo debug antes de adoptar cualquier wrapper nuevo. Si no tienen modo que muestre el request completo, es señal de alerta.

Lo que le pediría al ecosistema: que el estándar mínimo de transparencia sea mostrar el token count real (input + contexto inyectado) antes de confirmar cada request. No después. Antes. Con un breakdown de qué es tuyo y qué es de la herramienta.

No es difícil de implementar. Es una decisión de producto. Y el hecho de que casi ninguna herramienta lo haga dice algo sobre qué incentivos los mueven.

La pregunta de si Gas Town roba créditos es interesante. La pregunta de por qué aceptamos no saber exactamente qué pagamos es más importante. Hace 30 años, cuando diagnosticaba cortes de conexión en un cyber a las 11pm, aprendí que el primer paso para resolver cualquier problema es saber exactamente qué está pasando en la red. Ese principio no cambió. Las capas de abstracción se multiplicaron — nuestra tolerancia a la opacidad también, y eso es un problema que nosotros elegimos tener.