La mayoría de las plataformas de agentes se interponen entre tú y el proveedor del modelo, y luego cobran un recargo por cada token que pasa por ellas. Sharkly no lo hace. El uso de modelos funciona con tu propia clave (bring-your-own-key): cada ejecución se factura contra el plan de Claude Code, Codex o API que ya está vinculado al Runtime que la ejecuta, no contra un saldo de tokens que Sharkly te venda. Es una afirmación más modesta de lo que parece, y merece la pena ser honestos sobre lo que te cuesta y lo que te ahorra antes de decidir que es importante.
Qué le hace un modelo de reventa a tus incentivos
Empecemos por la plataforma que sí te vende tokens, porque es lo habitual en esta categoría y conviene decirlo sin rodeos en lugar de andarse con evasivas.
Cuando una plataforma revende acceso a modelos, sus ingresos dependen de cuántos tokens consumen tus Agentes. Eso no es un defecto oculto: es el modelo de negocio funcionando tal como fue diseñado, y genera un incentivo predecible: la plataforma no tiene ninguna razón para abaratar una ejecución. Un prompt más eficiente, una ventana de contexto más pequeña, un Runtime que termina con menos tokens... todo eso reduce los ingresos de la plataforma en tu cuenta. Nada obliga a un revendedor de tokens a trasladarte las bajadas de precio que aplique el proveedor del modelo subyacente, y nada lo recompensa por ayudarte a gastar menos. Pagas un recargo por la coordinación, pero ese recargo está denominado en la moneda que la plataforma quiere que consumas más.
El segundo costo es más silencioso y aparece más tarde. Si tu equipo ya tiene un plan de Claude Code o Codex, o un compromiso de gasto en API con un proveedor, seguramente hayas negociado un precio por ello: un nivel de suscripción, un descuento por volumen, una tarifa por uso comprometido. Si canalizas ese consumo a través de un revendedor, pagas dos veces por la misma ventaja: una al revendedor por el privilegio del acceso, y además pierdes el beneficio de la tarifa que ya habías asegurado directamente, porque ahora se aplica la tarifa del revendedor. La relación de precios que construiste con el proveedor del modelo no viaja contigo a una plataforma que revende tokens bajo su propia cuenta.
Pongámosle un número, aunque sea aproximado. Un equipo que ejecuta un puñado de Agentes a través de un revendedor, con un recargo por token aunque sea modesto, y encima del gasto comprometido que ya tiene directamente con el proveedor del modelo, está pagando dos veces por los mismos tokens: una a la tarifa negociada que ya no puede usar, y otra a la tarifa que al revendedor le haya dado por cobrar. Extrapola eso a las ejecuciones de todo un Sprint, no a una sola Task, y la diferencia se acumula exactamente en la dirección que le conviene al revendedor.
Nada de esto hace que la reventa de tokens sea deshonesta. Lo que hace es convertirla en un modelo en el que los intereses de la plataforma y tus intereses de costo apuntan en direcciones distintas, y eso conviene saberlo antes de confiarle tus ejecuciones a un proveedor.
Lo que BYOK te cuesta en realidad
La separación tampoco es gratis del lado de Sharkly, y un artículo que solo enumerara las ventajas de usar tu propia clave sonaría a marketing y no a un relato honesto del tradeoff. Digamos los costos sin rodeos.
Tú gestionas las claves y las cuotas. Nadie en la capa de coordinación vigila por ti el límite de peticiones de tu plan de Claude Code ni el crédito restante de tu cuenta de API. Si tu equipo ejecuta cinco Agentes contra una sola clave de API de Anthropic y esa clave alcanza su límite de peticiones, esa es una restricción de la que tú eres responsable: tienes que darte cuenta y planificarla, igual que lo harías si una persona de tu equipo estuviera haciendo esas llamadas directamente desde una terminal.
Una ejecución puede fallar por un motivo que no tiene nada que ver con Sharkly. Si el plan de Claude Code vinculado a un Runtime alcanza su límite de peticiones, o si la cuenta de API que lo respalda se queda sin crédito, la ejecución se detiene, y el fallo aparece como un error de tokens o de autenticación del proveedor del modelo, no como una caída de Sharkly. Depurar eso implica revisar dos sistemas en lugar de uno: ¿la Task está atascada por algo de Sharkly o porque el plan subyacente se quedó sin recursos? Es una costura real, y es el precio directo de no tener un fondo de tokens controlado por la plataforma que lo disimule.
La visibilidad del gasto vive en dos sitios. El panel de uso de Sharkly muestra el consumo por Agente, pero la factura como tal aparece en tu factura de Claude Code, Codex o del proveedor de API, no como una única línea de Sharkly. Si tu equipo de finanzas quiere un solo número para «cuánto nos costó programar con IA este mes», tendrá que conciliar dos fuentes en lugar de leer un único resumen, y esa conciliación es trabajo manual que alguien tiene que hacer de verdad.
También hay un costo de puesta en marcha, y conviene nombrarlo en lugar de darlo por sentado. Cada Runtime que conectas necesita su propia clave o plan configurado, alguien del equipo tiene que encargarse de renovar y rotar esas credenciales, y una persona recién incorporada que quiera ejecutar Agentes necesita acceso a la cuenta del proveedor subyacente, no solo una invitación a Sharkly. Una plataforma de reventa puede esconder todo eso detrás de un único registro. BYOK no lo hace, por diseño, y un equipo que evalúe Sharkly debería presupuestar una o dos horas reales de configuración por Runtime en lugar de esperar que sean cero.
Nada de eso es motivo para evitar BYOK. Es la lista honesta de lo que asumes a cambio de no pagar un recargo por tokens, y un equipo debería entrar sabiéndolo, no descubrirlo durante un incidente.
Dónde la capa de gestión sigue ganándose su sitio
Dado que Sharkly no te vende tokens ni disimula los límites de peticiones de los proveedores, es justo preguntarse qué hace realmente la capa de coordinación. Tres cosas, en concreto.
Decide en qué Computer se ejecuta cada ejecución. El Runtime de un Agente necesita un host, local o en la nube, con los repositorios y recursos que requiere una Task, y esa asignación es tarea de Sharkly, sin importar quién pague los tokens que consume la ejecución. La facturación de tokens y la ubicación de la ejecución son cuestiones distintas, y BYOK solo saca a la plataforma de la primera.
Mantiene a una persona en el camino de aprobación. Los Agentes investigan, ejecutan, prueban e informan; las personas marcan la dirección, otorgan autoridad y aceptan el resultado. Ese paso de revisión —quién da el visto bueno a una Task antes de que se fusione o se cierre— no depende de quién pague la llamada al modelo que hay debajo. Un recargo de revendedor más barato no te compra un mejor proceso de revisión, y un modelo BYOK tampoco te cuesta uno.
Y te da un panel de uso que muestra el consumo por Agente, aunque los tokens se facturen en otro sitio. Puedes ver qué Agente consumió más en un Sprint, qué tipos de Task son caros de automatizar y dónde está trabajando al límite un Runtime, todo ello sin que esa visibilidad exija que Sharkly sea quien te cobra por los tokens sobre los que informa. La utilidad del panel no depende de que Sharkly sea el titular de la factura.
Esa es la forma real de la separación: Sharkly gestiona dónde se ejecuta el trabajo, quién lo revisa y cuánto te cuesta ejecutarlo, sin necesidad de ser además el proveedor que te vende aquello que se está midiendo.
Decidir si ese tradeoff merece la pena
Si tu equipo es pequeño, tiene un solo Runtime y casi nunca se topa con un límite de peticiones, la cuestión de revendedor frente a BYOK probablemente no te cambie mucho el día en ningún sentido. El tradeoff se vuelve real cuando ejecutas varios Agentes contra el mismo plan subyacente, coordinas Crews en más de un Computer o intentas responder «cuánto nos costó realmente programar con IA este Sprint» para más de un equipo. En ese punto, una plataforma con un incentivo oculto para mantener alto tu gasto en tokens es un costo que no puedes ver del todo, y una plataforma que simplemente te dice cuánto gastaste, sin ser además quien te lo vende, merece la pena aunque tengas que lidiar con dos paneles.
La apuesta de Sharkly es que el problema que merece la pena cobrar es el de la coordinación, no el de la medición. Es la capa que está por encima de los agentes que ya ejecutas, no un segundo proveedor entre tú y los tokens que gastan. Si ya pagas Claude Code o Codex directamente y quieres que las ejecuciones sean asignables, revisables y visibles sin un recargo que se siente encima de los tokens, esa es la capa que Sharkly está diseñada para ser. Consulta los precios actuales para ver exactamente cómo es la parte de asientos.
