Rode o cérebro de RAG do Quivr em um endpoint personalizado compatível com OpenAI.

Resposta rápida: llm_base_url em LLMEndpointConfig.

O Quivr atual é o quivr-core, uma biblioteca Python de RAG, e sua conexão de LLM é explícita. LLMEndpointConfig carrega supplier (openai por padrão), model, llm_base_url, e llm_api_key; LLMEndpoint.from_config() constrói o cliente real a partir desses campos, e para o supplier openai esse cliente é o ChatOpenAI do LangChain construído com sua base url. Defina llm_base_url como https://api.apisrouter.com/v1, defina model como qualquer id do catálogo, e passe o endpoint para seu Brain. A chave pode vir do campo de configuração ou do ambiente: quando llm_api_key não está definida, o quivr-core a resolve de uma variável de ambiente nomeada a partir do supplier, que para o supplier openai é OPENAI_API_KEY. Os dois caminhos são comportamento upstream, legíveis em quivr_core/rag/entities/config.py e quivr_core/llm/llm_endpoint.py.

from quivr_core.llm import LLMEndpoint
from quivr_core.rag.entities.config import (
    DefaultModelSuppliers, LLMEndpointConfig)

llm = LLMEndpoint.from_config(LLMEndpointConfig(
    supplier=DefaultModelSuppliers.OPENAI,
    model="claude-sonnet-4-6",          # any catalog id
    llm_base_url="https://api.apisrouter.com/v1",
    llm_api_key=os.environ["APISROUTER_API_KEY"],
))

O que o Quivr é agora, e onde o slot de LLM se encaixa.

O Quivr (QuivrHQ no GitHub, cerca de 39 mil estrelas) começou como um aplicativo completo de segundo cérebro e pivotou para o quivr-core: uma biblioteca de RAG opinativa que você embarca no seu próprio produto. Você alimenta arquivos, ele os analisa e fragmenta, embarca os fragmentos em um vector store (FAISS por padrão, PGVector suportado), e responde perguntas sobre eles através de um fluxo de recuperação configurável. O objeto Brain é a unidade: Brain.from_files() ingere, brain.ask() recupera e gera. Geração é a única etapa que precisa de um chat model. O fluxo de recuperação monta o contexto dos seus documentos, e o LLMEndpoint que você passou escreve a resposta fundamentada. Esse endpoint é construído uma vez a partir de LLMEndpointConfig, então a decisão de base url é tomada no momento da construção e se aplica a todo ask() naquele brain. Como o ChatOpenAI encaminha o campo model como uma string simples via /v1/chat/completions, o id pode ser Claude, DeepSeek, GPT, ou Gemini quando o endpoint atrás de llm_base_url os serve. Uma nota honesta sobre o status do projeto: o repositório está quieto desde meados de 2025, então trate o quivr-core como uma biblioteca estável em vez de uma que muda rápido. A superfície de configuração descrita aqui corresponde à main branch mais recente, e o histórico quieto significa que é improvável que ela mude debaixo de você; também significa que tutoriais antigos descrevendo o app full-stack aposentado (arquivos .env de backend, um frontend hospedado) não correspondem mais ao código.

Configuração completa: um brain com um LLM roteado pelo gateway.

O padrão completo passa o LLMEndpoint configurado para Brain.from_files. Tudo mais sobre o brain (parsing, fragmentação, o armazenamento FAISS, o fluxo de recuperação) é independente do endpoint do LLM e mantém seus padrões. Atenção ao embedder. Se você não passar um, o quivr-core constrói o OpenAIEmbeddings do LangChain com seus próprios padrões, que autentica com OPENAI_API_KEY e mira o endpoint padrão da OpenAI. Esse é um cliente separado do LLM de chat: rotear a geração pelo gateway não o move. Passe seu próprio embedder (um wrapper local sentence-transformers, ou qualquer instância Embeddings do LangChain que você configure) se você não quiser que a metade de embedding dependa de uma conta OpenAI.

import os
from quivr_core import Brain
from quivr_core.llm import LLMEndpoint
from quivr_core.rag.entities.config import (
    DefaultModelSuppliers, LLMEndpointConfig)

llm = LLMEndpoint.from_config(LLMEndpointConfig(
    supplier=DefaultModelSuppliers.OPENAI,
    model="claude-sonnet-4-6",
    llm_base_url="https://api.apisrouter.com/v1",
    llm_api_key=os.environ["APISROUTER_API_KEY"],
    max_output_tokens=2048,
    temperature=0.3,
))

brain = Brain.from_files(
    name="team-docs",
    file_paths=["handbook.pdf", "runbook.md"],
    llm=llm,
    # embedder=...  # separate component; see note above
)

print(brain.ask("What is the on-call escalation policy?").answer)

Escolhendo um modelo de geração para respostas de RAG.

Comparar candidatos é uma mudança no momento da construção: monte dois LLMEndpoints contra a mesma base url, dois brains sobre os mesmos arquivos, e compare as respostas em um conjunto fixo de perguntas. O log de uso por chave precifica a execução de cada candidato, então qualidade por token é medida em vez de discutida.

• Geração de RAG é pesada em entrada: trechos recuperados dominam o prompt. O preço por token de entrada define o custo de uma resposta, que é por isso que um id rápido geralmente reduz a conta pela metade sem tocar na qualidade da recuperação.
• claude-sonnet-4-6 é o padrão confiável para respostas fundamentadas que respeitam o contexto recuperado e recusam de forma limpa quando os documentos não contêm a resposta.
• Produtos embarcados de alto volume (o caso de uso declarado do Quivr) rodam bem em claude-haiku-4-5-20251001, deepseek-v4-flash, ou gemini-3.5-flash para a mistura de perguntas do dia a dia.
• max_context_tokens na mesma configuração governa quanto contexto recuperado o pipeline empacota; aumentá-lo combina naturalmente com ids de contexto longo e eleva o gasto de entrada proporcionalmente.
• Prefixos de modelo desconhecidos caem de volta em um tokenizador genérico para orçamento, o que é cosmético; a própria requisição carrega seu id inalterado para o endpoint.

Pague pelo uso · abaixo do preço oficial

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Correções ao folclore comum sobre o Quivr.

Guias em circulação descrevem superfícies que o Quivr não tem mais, então vale a pena declarar o que o código atual realmente faz. O quivr-core é apoiado em LangChain, não em LiteLLM. O enum supplier seleciona uma classe de chat do LangChain, e openai mapeia para ChatOpenAI com seu llm_base_url. Se um tutorial te diz para configurar um proxy LiteLLM ou uma configuração api_base dentro do Quivr, ele descreve uma arquitetura mais antiga; o campo atual é llm_base_url em LLMEndpointConfig. O app full-stack está aposentado. Instruções sobre um .env de backend, configuração Supabase, ou um seletor de modelo no app se referem à aplicação pré-pivô, que não é mais o que o repositório empacota. A configuração agora acontece no seu código Python (ou no seu próprio app em torno da biblioteca). A variável de ambiente da chave é derivada do supplier. Para o supplier openai é OPENAI_API_KEY, mesmo quando o endpoint não é a OpenAI. Se você prefere não sobrecarregar esse nome, passe llm_api_key explicitamente na configuração, que tem precedência e mantém o ambiente limpo. O embedder é separado. Rotear a geração não move os embeddings; o embedder padrão é OpenAIEmbeddings com suas próprias credenciais. Decida as duas metades independentemente, e reembarcar um armazenamento existente só é necessário se você mudar o próprio modelo de embedding.

Quem roteia o quivr-core por um gateway.

• Times de produto embarcando RAG em seus apps que querem que o modelo de geração seja um valor de configuração, não um compromisso de fornecedor embutido na stack.
• Desenvolvedores rodando muitos brains em níveis de qualidade diferentes: uma chave, um endpoint, id de modelo por brain.
• Times que querem respostas fundamentadas com qualidade Claude atrás de uma configuração no formato OpenAI sem adicionar um segundo SDK ou conta de provedor.
• Criadores fazendo benchmark de modelos de geração sobre um corpus fixo, onde cada candidato é uma mudança em LLMEndpointConfig.
• Desenvolvedores sem acesso ao faturamento de um determinado fornecedor. O acesso baseado em recarga sem exigência de cartão remove a dependência de cadastro por provedor.

Verifique o endpoint e depure o primeiro ask().

Confirme que o gateway lista seu modelo antes de ingerir qualquer coisa; o campo model precisa corresponder exatamente a um id servido. Falhas na primeira execução são previsíveis. Um aviso de que a chave de API para o supplier openai não está definida significa que nem llm_api_key nem OPENAI_API_KEY estavam visíveis quando a configuração foi construída; o aviso acontece na construção, a falha no primeiro ask(). Um 401 significa que a chave resolvida não pertence ao endpoint em llm_base_url. Um erro model-not-found é um erro de digitação de id contra /v1/models. E um erro de autenticação relacionado a embedding durante Brain.from_files é o embedder padrão separado pedindo suas próprias credenciais OpenAI, que nenhuma configuração de llm_base_url vai corrigir; passe um embedder que você controla. Assim que as respostas fluem, o console da APIsRouter mostra modelo, contagens de token e gasto por requisição. Para uma biblioteca que empacota trechos recuperados em todo prompt, o número de tokens por resposta no seu corpus real é a figura que deveria guiar sua escolha de modelo.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

Perguntas frequentes