Como gestiono mis consumos y LLMs con Openrouter
En la epoca esta que nos encontramos, existen miles de LLMs que siguen saliendo dia a tras dia, el mercado es una competencia por quien mantiene los modelos frontier mientras cada vez los gratuitos o accesibles para todos terminan solamente siendo utiles para cosas basicas y si sos una persona que le interesa la privacidad posiblemente hayas pensado en correr cosas locales lo cual sigue siendo la mejor idea pero requiere dinero, gestionar mas de una subscripcion no es una opcion, vivir de un solo provedor tampoco, hay demasiados problemas entorno a todo esto para quien desarrolla, sin contar que si tu empresa no tiene un contrato enterprise estas entregando datos sensibles en cantidades, como tambien si vos tenes proyectos personales y todavia decis, no puedo ni hostear mis modelos ni acceder a un plan enterprise donde no entrenan modelos en base a mis prompts estas como ?? que hago.
Este ultimo tiempo por una cuestion de querer optimizar mis consumos, centralizar cosas y ver como puedo mejorar mi flujo, termine adoptando en su totalidad Openrouter si bien no es algo nuevo, aun para esta epoca sigue teniendo su encanto, siendo que podes centralizar todos tus consumos ahi, no tenes subscripciones y pagas por uso lo cual te have evaluar tus gastos y buscar modelos optimos para cada tarea, que si lo pensas para un sistema serio no le vas a tirar Opus 4.6 a todo lo que camina, entonces dependiendo la tarea podes empezar a buscar, entre benchmarks que hay en la misma pagina, precios y demas lo que mejor te convenga para lo que haces, sin contar que tienen su querido openrouter/free que si estas haciendo experimentos y si te dignas en leer su politica de ZDR, tenes alguna que otra cosita para usar.
Como aprovechar la plataforma
Gestion de API Keys
Primero que todo, vamos a empezar a crear apikeys en el panel que tiene
Siendo que mi caso es el de un individual (en un proximo blog voy a mostrar como gestionar uno para empresas)
Podemos crear por caso de uso, algo importante obvio para pensar desde siempre es poner un limitante, sea que fue una PoC algo que crees que vas a gastar centavos o demas es siempre crear una nueva apikey ya que si una de las que tenes se filtra por error primero
Solo se va a filtrar esa apikey
Tenes controlado por si alguien llega a consumirla para que no llegue a ser un gasto que afecte tu bolsillo (o controlarte vos mismo)
Dato importante de las keys, las mismas pueden incluir consumo de otras plataformas que tenemos
Donde BYOK significa Bring your own key, asi que si tenemos otras cositas podemos tambien centralizarlas aca.
Busqueda de modelos con buen rendimiento
Para esto podemos usar la parte de models y ordenar justamente por most popular esto significa que son los mejores? no pero viendo el uso de la pagina podemos asumir que los mas usados son la mezcla de el famoso bueno bonito y barato
Sobre todo cuando vemos la diferencia de consumo que hay, al dia de la fecha que escribo esto MiniMax M2.5 se encuentra primero hace tiempo por mas que se pueda ver que no es el #1 en varias categoria, esto muchas veces se ve afectado por el precio que tiene relacionado a sus benchmarks
0.089 USD x millon de tokens en average de input price es bajisimo, para contexto claude opus 4.6 actualmente tiene este coste promedio
Despues obviamente podemos ver muchisima informacion sobre ese modelo
Consumo centralizado
Si empezamos a probar y usar 200 cosas diferentes, crear apikeys, jugar y demas se va todo al corno si, pero es facil verlo desde la interfaz
Empezar a filtrar por apikey, modelo y todo lo que se te ocurra.
Manejo de privacidad
Posiblemente una de las cosas mas importantes, por que? y por que a algunas personas nos importa que hacen con nuestros datos, si bien sabemos que mientras mas control queremos la vida se vuelve menos practica y empezamos a sacrificar comodidades, para quien entiende lo que pasa por detras, es lindo tener un balance y poder vivir con comodidades, sin entregar tu vida digital al mejor postor.
Que tenemos en la plataforma? bastantes cositas que me terminaron resultando interesantes, primero vamos a tener una vista de disponibilidad respecto a que modelos vamos a poder usar en base a nuestra configuracion
Cuando empezemos a cambiar cosas vamos a ver que algunos no van a estar disponibles y nos va a dar una warning mencionando que politica viola este modelo en base a lo que le pedimos.
Un ejemplo
Por que se dio eso? por la siguiente politica
Tengase en cuenta que esto es propio de la cuenta (afecta a todas mis configuraciones) podemos despues segmentar mejor por apikey o demas.
Tambien tenemos configuraciones por provider, te cae mal OpenAI? bueno podes excluirlo por completo y dejarias de ver cualquier modelo que usa sus APIs
Ahora otra cosa importante, los guardrails. Como mencionamos antes las reglas mostradas hasta ahora son globales, aca podriamos aplicar de forma granular para poder segmentar mejor todo.
Que podemos modificar aca?, vamos a tener una vista de disponibilidad como antes
Como tambien la siguiente informacion
Donde aca tenemos lo siguiente
Informacion basica del guardrail para nombrarlo e identificarlo (name + description)
Budget, si bien podes enforzar limite por apikey, tambien lo podes hacer por guardrail.
Privacidad, hacer enforcement de ZDR
Modelos, que modelos vamos a poder usar y cuales no
Provedores, como mencionamos antes el que te caiga mal o no confias en lo absoluto se nos va
Informacion sensible, esto es importante ya que aca podemos empezar a definir que nos parece sensible a nosotros y redactar esa informacion en caso que decidamos enviarla
- Por ultimo la apikey a quien afectaria este guardrail, como para poder agarrar grupos, casos de uso o cualquier cosa que se te ocurra.
Mencionamos varias veces ZDR, pero que es?
Primero que todo, para leer en detalle tenemos su documentacion
Ahora esto ya lo mencione 2 veces en lo que va el Blog pero es algo super importante, con palabras de ellos mismos
Zero Data Retention (ZDR) means that a provider will not store your data for any period of time.
OpenRouter has a setting that, when enabled, only allows you to route to endpoints that have a Zero Data Retention policy.
Providers that do not retain your data are also unable to train on your data. However we do have some endpoints & providers who do not train on your data but do retain it (e.g. to scan for abuse or for legal reasons). OpenRouter gives you controls over both of these policies.
Que pasa aca? bueno que un endpoint que tenga ZDR significa que no van a usar nuestros datos de input/output para entrenar modelos, ni tampoco retenerlo en sus logs, similar a los servicios de VPN que tienen su No Log Policy para mas cuestiones sobre VPN recomiendo el siguiente recurso
Ahora otra cosa interesante es como trabajan ellos, poniendose en contacto con los provedores para establecer esta ZDR y en caso que no puedan llegar a un acuerdo mencionan lo siguiente
If OpenRouter is not able to establish or ascertain a clear policy for a provider or endpoint, we take a conservative stance and assume that the endpoint both retains and trains on data and mark it as such.
Que significa esto? que cualquiera que no quiera dar la informacion que tiene que dar, es catalogado como alguien de desconfianza y podemos asumir que retiene logs o entrena con nuestros prompts.
Conclusion
Si bien quedan cosas por mirar, hasta este punto siento que cualquiera (como vengo haciendo yo) le puede sacar bastante provecho a la plataforma, economizando costos, centralizando consumos para no andar gastando de mas y cuidando sus datos cuando se requiera.
La plataforma tiene una muy buena developer experience en ese caso haciendo todo bastante facil, recomiendo pegarle una mirada.
