Cohere brengt Embed 5 en Rerank 5 naar de uniforme API van OpenRouter

Cohere maakte bekend dat zijn retrievalmodellen Embed 5 en Rerank 5 vanaf 4 november 2026 beschikbaar zijn op OpenRouter. Bestaande gebruikers kunnen ze aanroepen met dezelfde API-sleutel en hetzelfde tegoed als voor andere modellen, zonder aparte SDK’s, accounts of facturen.

De modellen verzorgen de retrievalfasen van een pijplijn voor generatie met opgehaalde context, ofwel RAG: Embed 5 zet documenten en zoekopdrachten om in vectoren, Rerank 5 beoordeelt kandidaten opnieuw op basis van de zoekopdracht en elk chatmodel op OpenRouter kan het uiteindelijke antwoord genereren. Cohere publiceerde ook een Python-referentieworkflow voor indexering, retrieval, relevantiefiltering en het genereren van antwoorden met bronvermelding.

De vermelding van Embed 5 Pro op OpenRouter vermeldt een prijs van $0.12 per miljoen teksttokens en $0.40 per miljoen imagetokens; voor Embed 5 Fast is de prijs $0.08 per miljoen tokens. De vermelding van Rerank 5 Pro op OpenRouter vermeldt voor die versie een prijs van $0.05 per miljoen invoertokens en voor Rerank 5 Fast $0.02 per miljoen tokens.

De uitrol via OpenRouter vergroot het bereik, maar introduceert geen nieuwe modelgeneratie. Cohere introduceerde Embed 5 op 30 september 2026 en Rerank 5 op 21 oktober 2026; beide modelreeksen zijn beschikbaar in de versies Pro en Fast.

Gedeelde embeddings scheiden indexeringskosten van querykosten

Het belangrijkste architectuurdetail is dat Embed 5 Pro en Fast dezelfde embeddingruimte delen. Daardoor kan een corpus met Pro worden geïndexeerd en met Fast worden doorzocht zonder de index opnieuw op te bouwen, zolang beide dezelfde uitvoerdimensies gebruiken. Zo wordt het indexeringswerk, dat per corpus maar één keer plaatsvindt, gescheiden van de embeddingaanroep voor elke vraag, waarbij latentie en kosten een rol spelen.

In tests met 40 ontwikkeldatasets kwam Cohere uit op een genormaliseerde gemiddelde retrievalkwaliteit van 98.4 voor een met Pro opgebouwde index die met Fast werd doorzocht, en 96.6 wanneer Fast aan beide kanten werd gebruikt, tegenover 100 voor Pro aan beide kanten. De OpenRouter-workflow gebruikt deze combinatie van indexering met Pro en zoeken met Fast, en reserveert Pro voor de offline indexeringsfase.

Embed 5 biedt zes vectorgrootten, van 256 tot 2,048 dimensies; 2,048 is de standaardinstelling. Het OpenRouter-voorbeeld gebruikt vectors met drijvendekommagetallen van 1,024 dimensies, omdat de embeddings-API van OpenRouter zulke getallen retourneert; Cohere beveelt afzonderlijk int8-vectoren met die dimensie aan als de beste verhouding tussen kwaliteit en kosten. Door tekstfragmenten in batches te verwerken, zijn er tijdens het indexeren minder netwerkverzoeken nodig, maar de kosten voor embeddings op basis van tokens dalen er niet door. Het onlineproces gebruikt per vraag één aanroep van Embed 5 Fast en één van Rerank 5, plus één chataanroep als er na het filteren context overblijft.

Relevantiecijfers bepalen de context voor generatie

De referentiepijplijn haalt met cosinusgelijkenis 20 tekstfragmenten op, stuurt die samen met de vraag naar Rerank 5, behoudt maximaal vijf resultaten en verwijdert resultaten met een score onder de demonstratiedrempel van 0.3. Bij het opnieuw rangschikken worden de vraag en elke kandidaat samen beoordeeld, in plaats van alleen op vectorafstand af te gaan. Dit kan ook na semantisch zoeken, zoeken op trefwoorden of hybride zoekopdrachten, zonder Embed 5.

Volgens Cohere blijven de gekalibreerde scores van Rerank 5 consistent bij verschillende zoekopdrachten en domeinen. Daardoor kan één drempelwaarde bepalen welke context een generator bereikt; in de lanceringsdocumentatie wordt een score van 0.7 beschreven als een kans van 70% dat een document nuttig is. Pro is bedoeld voor complexe redeneervragen en lange of domeinspecifieke documenten, terwijl Fast gericht is op zoekopdrachten met een hoog volume en agents die herhaaldelijk zoeken. De modellen ondersteunen een context van 32K tokens en kunnen JSON-records of tabellen verwerken die als YAML-tekenreeksen zijn opgemaakt.

Bij het genereren worden de overgebleven tekstfragmenten genummerde bronnen, met de instructie om uitsluitend op basis daarvan te antwoorden en er in de tekst naar te verwijzen. Als geen enkel fragment de drempel haalt, meldt de workflow dat het antwoord niet kon worden gevonden en slaat die de aanroep van het chatmodel over. Omdat Rerank de onbewerkte tekst leest op het moment van de zoekopdracht, is voor overschakelen op een andere versie van de reranker geen herindexering of nieuwe embedding nodig.

Resultaten van de demonstratie en beperkingen voor productie

In de demonstratie van Cohere wordt fictieve API-documentatie gebruikt en gevraagd hoe je een sleutel kunt vervangen zonder onderbreking van de dienstverlening. Bij retrieval op basis van alleen embeddings stond het juiste document, API-sleutels roteren, bovenaan met een score van 0.522, gevolgd door Geheimen voor webhookondertekening met 0.337 en API-sleutels aanmaken met 0.316. Na het opnieuw rangschikken kreeg het juiste document een score van 0.808 en kwamen beide sterk gelijkende documenten onder de drempelwaarde uit.

Voor het voorbeeld zijn Python 3.10 of nieuwer, een OpenRouter-API-sleutel, de Python-SDK en NumPy nodig voor de in-memory vectoropslag. Voor productie-implementaties wordt aangeraden die opslag te vervangen door een vectordatabase. De RAG-richtlijnen van OpenRouter beschrijven opnieuw rangschikken als een afweging tussen precisie en latentie: het kan de resultaten verbeteren wanneer een brede verzameling kandidaten moet worden teruggebracht, maar vereist een extra API-aanroep en is minder geschikt wanneer minimale latentie vooropstaat.

Voor multimodale retrieval is een omweg nodig. Embed 5 accepteert afbeeldingen en gecombineerde tekst- en afbeeldingsinvoer, zoals PDF-pagina’s, en de embeddings-API van OpenRouter accepteert afbeeldings-URL’s, maar Rerank 5 werkt alleen met tekst. Mogelijke oplossingen zijn om de geparseerde pagin tekst of bijschriften opnieuw te rangschikken, of het opnieuw rangschikken achterwege te laten voor visuele resultaten.

OpenRouter vermeldt Cohere als enige aanbieder van beide Pro-modellen en stuurt verzoeken rechtstreeks door naar Cohere. Volgens beide vermeldingen is routering binnen de EU-regio niet beschikbaar.

De beschikbaarheid via OpenRouter bundelt de integratie en facturering van de retrievalarchitectuur, terwijl de kosten in productie afhankelijk blijven van de architectuur: een eenmalige Pro-indexering, terugkerende Fast-query-, herordenings- en chatoproepen, en de relevantiedrempel die bepaalt welke context voor generatie wordt gebruikt. De enkele API neemt de extra latentie, de beperking tot tekstuele herordening en de beperkingen voor regionale routering die voor die architectuur zijn gedocumenteerd, niet weg.