Cada vez que Octocode ejecuta una búsqueda semántica, cada vez que Octomind enruta un prompt al modelo adecuado, cada vez que uno de nuestros productos se comunica con un LLM, todo pasa por la misma pieza de código. La extrajimos de Octocode el año pasado. Ahora hace funcionar todo.

Se llama Octolib. Y acabamos de liberarla como código abierto.

De pegamento interno a infraestructura compartida

Octolib comenzó como la parte sucia de Octocode en la que nadie quería pensar.

Octocode necesita embeddings para entender el código semánticamente. LLMs para responder preguntas sobre tu base de código. Reranking para mostrar los resultados que realmente importan. Al principio, eso significaba tres librerías cliente distintas, tres patrones distintos de manejo de errores y tres formas distintas de parsear el uso de tokens. (Todavía recuerdo añadir los embeddings de Cohere y tener que aprender todo su SDK solo para obtener un vector de vuelta.)

Añadir un nuevo proveedor implicaba tocar código en seis lugares. Hicimos lo que la mayoría de los equipos hacen: escribimos un wrapper delgado.

Luego el wrapper ganó funciones. Después ganó proveedores. Entonces nos dimos cuenta de que Octomind, nuestra plataforma de agentes de IA, necesitaba exactamente lo mismo. Y Octobrain también.

Copiar y pegar el wrapper tres veces parecía estúpido. Extraerlo parecía evidente.

Octolib es esa extracción. Una librería de Rust autosuficiente para inferencia LLM, embeddings y reranking en todos los proveedores principales.

Una cadena, cualquier backend

La propuesta es simple. Una cadena provider:model. Una API. Cualquier backend.

let provider = ProviderFactory::get_provider_for_model("openai:gpt-5.5")?;
let response = provider.chat_completion(params).await?;

Cambia openai:gpt-5.5 por anthropic:claude-opus-4-5-20251101, deepseek:deepseek-chat, nvidia:meta/llama-3.3-70b-instruct u openrouter:anthropic/claude-opus-4.5. El código no cambia. El tipo de respuesta no cambia. El seguimiento de uso de tokens y coste sigue funcionando.

Este es el trait que lo hace posible:

#[async_trait]
pub trait AiProvider {
    fn name(&self) -> &str;
    fn supports_model(&self, model: &str) -> bool;
    async fn chat_completion(&self, params: ChatCompletionParams) -> Result<ProviderResponse>;
    fn get_model_pricing(&self, model: &str) -> Option<Pricing>;
}

Cada proveedor implementa la misma interfaz. OpenAI tiene su propia implementación nativa. NVIDIA NIM, Cerebras, Together, Ollama y los endpoints locales pasan todos por una capa compartida compatible con OpenAI. La factory se encarga de parsear la cadena del modelo y enrutarla al backend correcto.

Aburrido por diseño. Esa es la idea.

Proveedores de LLM

Proveedor Tipo Chat Salida estructurada Caching
OpenAI Nativo ✅ ✅ —
Anthropic Nativo ✅ ✅ ✅
Google (Gemini) Nativo ✅ ✅ —
DeepSeek Nativo ✅ ✅ —
Moonshot Nativo ✅ ✅ —
MiniMax Nativo ✅ ✅ —
Z.ai Nativo ✅ — —
OpenRouter Compatible OpenAI ✅ ✅ —
NVIDIA NIM Compatible OpenAI ✅ — —
Cerebras Compatible OpenAI ✅ — —
Together Compatible OpenAI ✅ — —
Cloudflare Workers AI Compatible OpenAI ✅ — —
OctoHub Compatible OpenAI ✅ — —
Ollama Compatible OpenAI ✅ — —
Endpoints locales Compatible OpenAI ✅ — —

Embeddings y reranking

Proveedor Embeddings Reranking Local
Jina ✅ ✅ —
Voyage ✅ ✅ —
Cohere — ✅ —
OpenAI ✅ — —
Google ✅ — —
FastEmbed ✅ ✅ ✅

Los nuevos proveedores llegan como pull requests. Si necesitas uno que falte, la plantilla está en src/llm/providers/openai.rs.

Las piezas de las que nadie habla hasta que se rompen

Las librerías multi-proveedor ya no son raras. La diferencia está en los detalles que solo importan cuando las llevas al límite.

Seguimiento de costes. Cada respuesta incluye el uso de tokens y el coste calculado. Para proveedores con API nativa, mantenemos tablas de precios por modelo. Para proxies y agregadores que alojan modelos de pesos abiertos, recurrimos a precios de referencia emparejados por nombre de modelo. Si la API upstream no devuelve un campo de coste, lo calculamos nosotros mismos a partir del número de tokens.

Esto suena menor. No lo es. Intenta lanzar miles de peticiones a través de cinco proveedores y adivinar a dónde fue tu dinero.

Salida estructurada. No todos los proveedores soportan restricciones de JSON schema. Octolib sabe cuáles sí — OpenAI, Anthropic, DeepSeek, Moonshot, MiniMax — y gestiona las diferencias de formato de petición. Estableces response_format y recibes JSON parseado. Sin prompt engineering manual. Sin trucos de "por favor responde en JSON válido".

Embeddings y reranking. La misma abstracción de proveedor aplica a generate_embeddings() y rerank(). Jina, Voyage, Cohere, OpenAI, FastEmbed — la misma API, distinto backend. Los pipelines RAG modernos tocan tres tipos de servicios distintos. Gestionar clientes separados para cada uno es trabajo tedioso que no deberías tener que hacer.

Sin panics, sin println. Es una librería, no una aplicación. Cada función pública devuelve Result. Los errores llevan contexto. La salida de debug pasa por tracing, no por stdout. Estas no son funciones emocionantes. Son la diferencia entre una librería en la que confías en producción y una que te despierta a las 3 de la madrugada.

Tres productos, una librería

Octolib es la capa de IA de todo nuestro stack:

  • Octocode — búsqueda semántica de código, Q&A sobre la base de código, resúmenes de diff
  • Octomind — razonamiento de agentes, llamada a herramientas, flujos multipaso
  • Octobrain — recuperación de conocimiento, procesamiento de documentos, pipelines de embeddings

Cuando añadimos un nuevo modelo — digamos, un modelo de razonamiento de DeepSeek o el último lanzamiento de Claude — actualizamos Octolib una vez. Cada producto lo obtiene. Cuando OpenAI cambia el formato de respuesta de su API o Anthropic introduce precios de caché, el arreglo vive en un solo lugar.

Por esto la extrajimos. No porque el código wrapper sea interesante. Porque mantener cuatro versiones del mismo wrapper es caro, y equivocarse en las integraciones de proveedores significa productos rotos.

La cuestión de Rust

Esto nos lo preguntan a veces. La respuesta corta: construimos infraestructura en Rust, y Octolib es infraestructura.

La respuesta más larga: las llamadas a LLM son peticiones de red ligadas a I/O. Pero el pipeline circundante — generación de embeddings, reranking, conteo de tokens, batching de peticiones, validación de salida estructurada — se beneficia de la combinación de Rust de rendimiento async y corrección en tiempo de compilación. Cuando estás ejecutando inferencia a una escala donde los milisegundos importan, no quieres pausas de garbage collection ni errores de tipo en runtime en tu camino crítico.

Y el ecosistema de Rust para infraestructura de IA está madurando rápido. Candle para inferencia local. tokio para async. serde para el infinito parseo de JSON. Todo encaja limpiamente.

FAQ

¿Qué es Octolib?

Octolib es una librería de Rust de código abierto para inferencia LLM, embeddings y reranking. Una cadena de API (provider:model) enruta llamadas a OpenAI, Anthropic, Google, DeepSeek, OpenRouter, Ollama y más de 10 proveedores adicionales. Hace funcionar Octocode, Octomind y Octobrain.

¿En qué se diferencia Octolib de LiteLLM o LangChain?

Octolib es nativa de Rust, de nivel infraestructura y de alcance acotado. Gestiona enrutamiento de proveedores, salida estructurada, seguimiento de costes y reranking — nada más. Sin agentes, sin chains, sin plantillas de prompts. Si estás construyendo funciones de IA en Rust y quieres una capa fina y predecible entre tu código y más de 15 proveedores, ese es el nicho.

¿Qué proveedores están soportados?

15 proveedores de LLM (OpenAI, Anthropic, Google Gemini, DeepSeek, Moonshot, MiniMax, Z.ai, OpenRouter, NVIDIA NIM, Cerebras, Together, Cloudflare Workers AI, OctoHub, Ollama, endpoints locales personalizados) y 6 proveedores de embeddings/reranking (Jina, Voyage, Cohere, OpenAI, Google, FastEmbed).

¿Funciona con modelos locales?

Sí. Ollama y cualquier endpoint local compatible con OpenAI funcionan desde el primer momento. FastEmbed ejecuta embeddings localmente sin API. La cadena provider:model es lo único que cambia.

¿Cómo funciona el seguimiento de costes?

Cada respuesta incluye el uso de tokens y un coste calculado. Los proveedores nativos usan tablas de precios por modelo. Los agregadores recurren a precios de referencia por nombre de modelo. Si la API upstream no devuelve un campo de coste, Octolib lo calcula a partir del número de tokens.

¿Está lista para producción?

Hace funcionar tres productos (Octocode, Octomind, Octobrain) cada día. Sin panics en el código de la librería. Cada función pública devuelve Result. La salida de debug pasa por tracing. La licencia es Apache-2.0.

Código abierto, ecosistema abierto

Octolib es una pieza de un cuadro más grande. Octocode es código abierto. La arquitectura de Octomind está documentada públicamente. Construimos en público porque los problemas que estamos resolviendo — cómo hablar con diez proveedores de IA distintos sin perder la cabeza — no son únicos para nosotros.

La librería está en GitHub. Compila con cargo check. Ejecuta los ejemplos sin configuración más allá de una clave de API. Si estás construyendo funciones de IA en Rust y cansado de escribir el mismo boilerplate de proveedores por tercera vez, podría ahorrarte unas cuantas semanas.

Vamos añadiendo proveedores a medida que las cosas evolucionan. El próximo probablemente ya está en una pull request.