A Cohere leva o Embed 5 e o Rerank 5 à API unificada da OpenRouter

A Cohere anunciou, em 4 de novembro de 2026, que seus modelos de recuperação Embed 5 e Rerank 5 estão disponíveis na OpenRouter. Os usuários atuais podem acessá-los com a mesma chave de API e os mesmos créditos usados para outros modelos, sem SDKs, contas ou cobranças separados.

Os modelos abrangem as etapas de recuperação de um pipeline de geração aumentada por recuperação, ou RAG: o Embed 5 converte documentos e consultas em vetores, o Rerank 5 recalcula a classificação dos candidatos em relação à consulta, e qualquer modelo de chat disponível na OpenRouter pode gerar a resposta final. A Cohere também publicou um fluxo de trabalho de referência em Python que abrange indexação, recuperação, filtragem por relevância e geração com citações.

A página do Embed 5 Pro na OpenRouter informa o preço de US$ 0,12 por milhão de tokens de texto e US$ 0,40 por milhão de tokens de imagem; o Embed 5 Fast custa US$ 0,08 por milhão de tokens. A página do Rerank 5 Pro informa o preço de US$ 0,05 por milhão de tokens de entrada para essa categoria, enquanto o Rerank 5 Fast custa US$ 0,02 por milhão de tokens.

A disponibilização na OpenRouter amplia a distribuição, em vez de introduzir outra geração de modelos. A Cohere lançou o Embed 5 em 30 de setembro de 2026 e o Rerank 5 em 21 de outubro de 2026; ambas as famílias oferecem as categorias Pro e Fast.

Embeddings compartilhados separam os custos de indexação e consulta

O principal detalhe arquitetônico é que o Embed 5 Pro e o Fast compartilham o mesmo espaço de embeddings. Assim, um corpus pode ser indexado com o Pro e consultado com o Fast sem reconstruir o índice, desde que ambos usem as mesmas dimensões de saída. Isso separa o trabalho de indexação, feito uma vez por corpus, da chamada de embeddings, sensível à latência e ao custo, feita para cada pergunta.

Nos testes da Cohere com 40 conjuntos de dados de desenvolvimento, a qualidade média normalizada da recuperação foi de 98,4 para um índice criado com o Pro e consultado com o Fast, e de 96,6 com o Fast nas duas etapas, em comparação com 100 com o Pro nas duas etapas. O fluxo de trabalho da OpenRouter adota essa combinação de indexação com o Pro e consulta com o Fast, reservando o Pro para a etapa de indexação offline.

O Embed 5 oferece seis tamanhos de vetor, de 256 a 2.048 dimensões, sendo 2.048 o padrão. O exemplo da OpenRouter usa vetores de ponto flutuante de 1.024 dimensões porque a API de embeddings retorna números de ponto flutuante; separadamente, a Cohere recomenda vetores int8 com essa dimensão como a opção preferencial em termos de equilíbrio entre qualidade e custo. Agrupar blocos reduz as chamadas de rede durante a indexação, mas não diminui as cobranças de embeddings baseadas em tokens. No fluxo online, são feitas uma chamada ao Embed 5 Fast, uma ao Rerank 5 e, quando o contexto passa pelo filtro, uma chamada ao modelo de chat por pergunta.

As pontuações de relevância controlam o contexto enviado à geração

O pipeline de referência recupera 20 blocos por similaridade de cosseno, envia-os ao Rerank 5 junto com a pergunta, mantém até cinco resultados e descarta aqueles com pontuação inferior ao limiar de demonstração de 0,3. O reranqueamento analisa em conjunto a consulta e cada candidato, em vez de depender apenas da proximidade vetorial, e pode ser aplicado após uma busca semântica, por palavras-chave ou híbrida, sem o Embed 5.

Segundo a Cohere, as pontuações calibradas do Rerank 5 permanecem consistentes entre consultas e domínios, permitindo que um único limiar determine qual contexto chega ao modelo gerador; a documentação de lançamento descreve uma pontuação de 0,7 como uma probabilidade de 70% de que um documento seja útil. O Pro destina-se a consultas que exigem raciocínio intensivo e a documentos longos ou específicos de um domínio, enquanto o Fast é voltado a buscas de alto volume e agentes que fazem buscas repetidas. Os modelos aceitam um contexto de 32 mil tokens e podem processar registros JSON ou tabelas formatadas como strings YAML.

Na etapa de geração, os blocos que passam pelo filtro se tornam fontes numeradas, e as instruções determinam que a resposta use apenas essas fontes e inclua citações no próprio texto. Se nenhum bloco atingir o limiar, o fluxo de trabalho informa que não foi possível encontrar a resposta e não faz a chamada ao modelo de chat. Como o Rerank lê o texto bruto no momento da consulta, trocar as versões do modelo de reranqueamento não exige reindexar nem gerar novos embeddings.

Resultados da demonstração e limitações em produção

A demonstração da Cohere usa documentação fictícia de API e pergunta como trocar uma chave sem interromper o serviço. Na recuperação baseada apenas em embeddings, o documento correto, Rotação de chaves de API, ficou em primeiro lugar, com 0,522, seguido de Segredos de assinatura de webhook, com 0,337, e Criação de chaves de API, com 0,316. Após o reranqueamento, o documento correto obteve 0,808, e os dois resultados semelhantes ficaram abaixo do limite.

O exemplo requer Python 3.10 ou mais recente, uma chave de API da OpenRouter, o SDK do Python e NumPy para o armazenamento vetorial em memória. Para implementações em produção, recomenda-se substituir esse armazenamento por um banco de dados vetorial. As orientações da OpenRouter sobre RAG apresentam o reranqueamento como uma escolha entre precisão e latência: ele pode melhorar os resultados quando é necessário reduzir um amplo conjunto de candidatos, mas acrescenta uma chamada à API e é menos adequado quando a prioridade é minimizar a latência.

A recuperação multimodal exige uma solução alternativa. O Embed 5 aceita imagens e entradas mistas de texto e imagem, como páginas de PDF, e a API de embeddings da OpenRouter aceita URLs de imagens, mas o Rerank 5 trabalha apenas com texto. As opções propostas são reranquear o texto extraído das páginas ou as legendas, ou deixar de aplicar o reranqueamento aos resultados visuais.

A OpenRouter lista a Cohere como única provedora dos dois modelos Pro e encaminha as solicitações diretamente a ela. Ambas as páginas informam que o roteamento regional dentro da UE não está disponível.

A disponibilidade no OpenRouter consolida a integração e a cobrança da pilha de recuperação, enquanto sua economia operacional em produção continua vinculada à arquitetura: indexação Pro única, consultas Fast recorrentes, chamadas de reranking e de chat, e o limiar de relevância que controla o contexto de geração. A API única não elimina as restrições documentadas para essa pilha quanto à latência adicional, ao reranking apenas de texto ou ao roteamento regional.