Por qué construimos HiWay: una alternativa BYOK europea
Los tres problemas que nos llevaron de 'nos las apañaremos' a 'lo vamos a construir'

Soy Johan Bretonneau, co-fundador de Mytm-Group con Antoine Brodiez. Construimos apps y herramientas IA para empresas europeas. HiWay2LLM es nuestra gateway LLM, y aquí está por qué acabamos shipándola nosotros mismos en vez de usar algo que ya existiera.

Esto no es un storytelling de marketing. Es la secuencia honesta de "probamos X, esto se rompió, probamos Y, esto se rompió, OK, lo construimos".

El punto de partida: 200 $ a las 3 de la madrugada

A principios de 2026 operábamos un puñado de productos IA — algunos internos, otros para clientes. Nuestro gasto LLM mensual subía rápido. No a escala startup — no quemábamos VC — pero sí lo bastante para llamar la atención.

Entonces un martes por la mañana abro la consola de Anthropic y veo un cargo de 200 $ con fecha de las 3 de la madrugada. Un agente había entrado en un bucle de retry contra Claude Opus. Nadie estaba despierto. Ninguna alerta había saltado. La factura simplemente había subido durante cuatro horas hasta que el rate limiter acabó atrapándola.

Es el momento en que dejamos de buscar "una buena gateway LLM" y empezamos a evaluar en serio todas las opciones sobre la mesa, porque nuestra stack existente había fallado de una manera precisa y cara.

Lo que probamos: LiteLLM self-hosted

LiteLLM es la respuesta OSS evidente. Lo desplegamos en nuestro VPS, apuntamos nuestras apps ahí, y funcionó. Durante unas semanas.

Esto es lo que se rompió para nosotros:

Carga ops. Cada cambio de API de proveedor implicaba un update de config, un ciclo de test, un redeploy. Las subidas de cuota de proveedor no estaban centralizadas. Cuando había que rotar la clave de un cliente, lo hacíamos a mano.

On-call. Que LiteLLM se cayera significaba que nuestras features IA caían. Nadie te paga por arreglar tu propia gateway a las 2 de la madrugada.

Agujeros de features. LiteLLM tenía routing y fallbacks. No tenía las cosas que de verdad necesitábamos — alertas burn-rate, detección de bucles agénticos, presupuestos por endpoint que auto-downgradean en vez de simplemente bloquear. Empezamos a parchear.

Los parches se acumularon. Cada semana dedicábamos 4-6 horas al trabajo de gateway en lugar de hacer ship de producto. Calculamos el coste fully-loaded del self-hosting: a nuestra escala, era peor que pagar un servicio gestionado.

LiteLLM es una pieza de software estupenda. Es la pieza de software equivocada para un equipo que quiere shippear producto y no tiene un platform engineer dedicado.

Lo que probamos: OpenRouter

Miramos OpenRouter en serio. Signup rápido, catálogo de modelos amplio, breadth genuinamente impresionante. Lo pilotamos en un producto.

Salieron tres problemas:

El markup sobre facturas en crecimiento. El markup de OpenRouter sobre la inferencia es pequeño en porcentaje, pero nuestra trayectoria de gasto era vertical. A 500 $/mes era ruido. Proyectado a 5K-10K $/mes, el markup se convertía en un line item que tendríamos que justificar. Nuestros clientes lo verían. Tendríamos que explicarlo.

US-hosted, sin opción UE. La mayoría de nuestros clientes son europeos. Varios están en sectores regulados. "Pasamos los prompts de tus usuarios a través de un tercero US cuya lista de sub-procesadores es X y cuyo DPA dice Y" era una conversación que no me apetecía tener una y otra vez. El EU AI Act entraba en vigor. Schrems II todavía era un tema vivo. El hosting US se volvió descalificante.

Sin BYOK. OpenRouter pagaba. El uso de nuestros clientes aparecía bajo nuestra cuenta de OpenRouter, no bajo sus cuentas de Anthropic. Las subidas de cuota pasaban por OpenRouter. La rotación de claves pasaba por OpenRouter. Todo pasaba por OpenRouter. El día que quisiéramos irnos, habría que tocar cada integración.

Ninguno de estos motivos es para hacer dunk a OpenRouter. Son buenos en lo que hacen. Simplemente no encajan con la forma precisa de problema que teníamos: equipo UE, sirviendo a clientes UE, con un gasto en crecimiento y una preferencia BYOK dura.

Lo que probamos: APIs directas con un shim casero

Durante unas semanas consideramos llamar directamente a Anthropic y OpenAI y construir una capa mínima casera de routing/presupuestos.

Es la trampa clásica del "es un proyecto de fin de semana". Lo bocetas, parece fácil, y entonces:

• Necesitas lógica de retry con backoff.
• Necesitas rate limiting por endpoint.
• Necesitas un tope presupuestario que haga downgrade en vez de errorear.
• Necesitas detección de burn-rate.
• Necesitas tracking de coste por request.
• Necesitas streaming.
• Necesitas tool use.
• Necesitas structured outputs.
• Necesitas seguir los cambios de API de cada proveedor.

Lo que empieza como "200 líneas de glue code" se convierte en un proyecto de plataforma de seis meses. Teníamos producto que shippear. Ese camino era una trampa.

Lo que decidimos construir

Tras esos tres callejones sin salida, escribimos lo que de verdad queríamos. Las restricciones eran precisas:

1. BYOK. Claves de proveedor de nuestros clientes, sus cuentas, su facturación. Sin markup sobre la inferencia.
2. UE-hosted. Sobre infra europea, con un DPA que pudiéramos entregar a compliance, sub-procesadores que pudiéramos nombrar.
3. Controles de coste que merezcan el nombre. Alertas burn-rate, presupuestos por endpoint, downgrade automático en umbrales, lo que ningún proveedor ofrece porque le perjudicaría el revenue.
4. Compatible OpenAI. Cero reescritura de SDK para migrar dentro o fuera.
5. Pricing flat. Nuestro margen no debería acumularse contra nuestros clientes a medida que crezcan.

HiWay2LLM es lo que esas restricciones produjeron:

• BYOK sobre Anthropic, OpenAI, Google, Mistral, Groq, DeepSeek, xAI, Cerebras — 60+ modelos en total.
• Alojado sobre OVH, infra francesa. DPA disponible. Cero prompt logging por defecto.
• Smart routing que lee cada request en menos de 1 ms y elige el tier óptimo. Alertas burn-rate vía Slack. Presupuestos por endpoint. Lógica de downgrade automático.
• Endpoints compatibles OpenAI. Swap drop-in para cualquier app que use un SDK de OpenAI.
• Pricing flat por request: Free a 2.500 req/mes, Build a 15 €/mes por 100K, Scale a 39 €/mes por 500K, Business a 249 €/mes por 5M, enterprise custom.

Sin markup sobre la inferencia, nunca. Si routeas 100M tokens por nosotros, le pagas a tus proveedores por 100M tokens y a nosotros nada extra. Nuestro revenue es la suscripción flat. Eso es todo.

Por qué pricing flat por request específicamente

Este merece desplegarse porque es la elección más opinionada que hicimos.

El markup por token alinea los intereses de la gateway con el upsell del proveedor. Más tokens, más revenue. La gateway gana más dinero cuando tu factura sube, lo que significa que las features que harían bajar tu factura — smart routing a modelos más baratos, caching agresivo, alertas burn-rate — son features que la gateway no tiene ningún incentivo para hacer ship.

El pricing metered por encima de los costes de proveedor (estilo Vercel AI Gateway) es una versión más suave del mismo problema. El revenue de la gateway crece igualmente con tu uso.

El pricing flat por request rompe eso. Cobramos lo mismo por una request que routea a Haiku que por una que routea a Opus. Lo que significa que nuestro mejor movimiento alineado es routear tu tráfico al modelo más barato que igualmente haga el trabajo. Cuando hacemos ship de mejoras de smart routing, tú ahorras y nosotros no perdemos nada.

El cálculo funciona porque nuestros costes son mayoritariamente fijos. Operar la gateway, la stack de observability, el motor burn-rate — esos costes no escalan con que tires de Haiku o de Opus. Escalan con el número de requests. Así que cobramos por número de requests.

Qué significa concretamente para nosotros ser una empresa UE

Ser una empresa UE no es solo un ángulo de marketing. Significa:

• Nuestra infra está sobre OVH, cloud provider francés.
• Nuestro DPA está construido contra el RGPD, no contra el EU-US Data Privacy Framework.
• Nuestra lista de sub-procesadores es corta y europea allí donde podemos.
• No logueamos los cuerpos de los prompts por defecto. Si quieres prompt logging para debug, haces opt-in, por clave API, y la retención está acotada.
• Seguimos las guías del EU AI Act sobre sistemas de alto riesgo, incluso cuando el uso de nuestros clientes no está clasificado como alto riesgo, porque las definiciones se mueven.

Para una pyme francesa que vende a hospitales franceses, bancos alemanes, aseguradoras belgas — es la diferencia entre "podemos desplegar esto" y "no podemos, legal no firma".

Algunos de nuestros competidores US tienen regiones UE. Muchos no. Ninguno de ellos nos gana en "somos una entidad UE de verdad, bajo ley UE, con gente basada en UE que responde a tus solicitudes data subject". No es una cosa pequeña.

Lo que aprendimos por el camino

Tres lecciones que pueden ser útiles si piensas en un trabajo de infra similar.

1. El cálculo "yo lo construyo solo" es casi siempre falso en la primera estimación. Estimábamos 2 semanas para el MVP. La cuenta honesta incluyendo herramientas de ops, motor burn-rate, observability y onboarding estaba más cerca de 4 meses de ingeniería real. Estamos contentos de haberlo hecho, pero no era un proyecto de fin de semana.

2. El pricing flat es disciplina, no solo etiqueta. Te obliga a ser eficiente porque no puedes esconder costes en el margen. Cuando Anthropic saca un modelo nuevo, añadimos soporte la misma semana. No porque nos encante el trabajo, sino porque nuestro revenue no depende de que te quedes en modelos más viejos y caros.

3. Los incentivos de tu cliente te enseñan qué construir. Hicimos ship de las alertas burn-rate porque nos pillaron los 200 $ a las 3 de la madrugada. Hicimos ship del pricing por request porque nuestros clientes pedían sin parar "¿puedo modelar este coste de forma predecible para el presupuesto del año que viene?". Hicimos ship del hosting UE porque cada call comercial enterprise daba contra el mismo muro de compliance. La roadmap se escribe sola desde las fricciones del cliente.

Para quién está hecho HiWay

No para todo el mundo. Si tu gasto son 20 $/mes y tu única restricción es "que funcione", usa Anthropic directo. Si eres US-only y te encanta Vercel, usa el Vercel AI Gateway. Si tu equipo tiene un platform engineer dedicado y quieres el control máximo, self-host LiteLLM.

HiWay es para los equipos que:

• Operan llamadas LLM en producción con un gasto en crecimiento.
• Se preocupan por el hosting UE por motivos de compliance o de preferencia.
• Quieren BYOK — claves en sus cuentas, facturación directa de los proveedores.
• Quieren controles de coste que de verdad se disparen antes de que el presupuesto se haya ido.
• Quieren pasar sus semanas haciendo ship de producto, no haciendo ops de gateway.

Si te ves ahí, nos encantaría ganar tu tráfico. Si no, una de las diez alternativas en nuestro otro post probablemente encaja mejor, y esperamos sinceramente que encuentres la correcta.

---

Próximo: LiteLLM vs gateways gestionadas — el trade-off real.