Draai Onyx op een aangepaste OpenAI-compatibele LLM-provider.

Snel antwoord: Add Custom LLM Provider in het adminpaneel.

De documentatie van Onyx is expliciet dat een aangepaste provider werkt zolang hij OpenAI-compatibele endpoints aanbiedt, en zijn voorbeeld-Base-URL-vorm is precies een gateway-vorm https://yourprovider.com/v1. De flow: open het Admin Panel via je profielicoon, ga naar Configuration, dan Language Models, en kies Add Custom LLM Provider. Vier beslissingen doen ertoe in dat formulier. Display Name is cosmetisch. Provider Name moet overeenkomen met een LiteLLM-providersleutel, omdat Onyx modelaanroepen eronder via LiteLLM routeert; voor een OpenAI-compatibele gateway is dat openai. Base URL is het gateway-endpoint inclusief het /v1-suffix. En de sectie Model Configurations is waar je elk model-ID registreert dat je beschikbaar wilt hebben, precies gespeld zoals de catalogus het bedient. Sla op, kies een standaard, en chats routeren onmiddellijk via de gateway.

Admin Panel -> Configuration -> Language Models
  -> Add Custom LLM Provider

Display Name:   APIsRouter
Provider Name:  openai            (LiteLLM provider key)
Base URL:       https://api.apisrouter.com/v1
API Key:        sk-YOUR-APISROUTER-KEY
Model Configurations:
  claude-sonnet-4-6
  claude-haiku-4-5-20251001
  deepseek-v4-pro

Waar de LLM zit in de architectuur van Onyx.

Onyx (onyx-dot-app op GitHub, ruim 31K sterren, voorheen Danswer) is een open-source AI-platform voor bedrijfskennis: het indexeert bronnen zoals Slack, Google Drive, Confluence, en tientallen andere connectoren, en beantwoordt er dan vragen over via een chat-UI, assistenten, en agent-workflows. Het is een van de meest gedeployde self-hosted enterprise-zoekstacks, en precies daarom verdient de LLM-rekening een routeringsbeslissing in plaats van een standaard. De pipeline splitst netjes in twee. Indexering en retrieval, inclusief documentembedding en reranking, draaien op de eigen modelserver van Onyx met standaard lokale modellen; niets daarvan raakt je LLM-provider. Antwoordgeneratie is de andere helft: zodra retrieval de relevante passages verzamelt, leest een LLM ze en schrijft het gegronde antwoord, en die aanroep gaat via LiteLLM naar wat de admin ook configureerde als provider. De aangepaste-provider-flow verwisselt de bestemming van precies deze helft. Omdat LiteLLM het model-ID als platte string doorgeeft aan een provider van het type openai, kunnen de ID's die je registreert in Model Configurations alles zijn wat het endpoint achter de Base URL bedient: Claude voor zorgvuldige gegronde antwoorden, DeepSeek voor volume, Gemini voor zeer lange broncontext. Verschillende assistenten kunnen standaard verschillende modellen gebruiken, dus een support-assistent en een engineering-assistent kunnen verschillende prijspunten rijden via dezelfde providervermelding.

Volledige instelling, en wat onaangeroerd blijft.

Het providerformulier is de hele integratie; er is geen configbestand te bewerken of container te herbouwen. Stel na het opslaan het standaardmodel voor de workspace in, en overschrijf optioneel het model per assistent waar je verschillende kwaliteitsniveaus wilt. Wat doelbewust onaangeroerd blijft: connectoren behouden hun eigen credentials, de index blijft onaangetast, en het embeddingmodel geconfigureerd voor zoeken beweegt niet mee. Die scheiding is het waard om te benoemen omdat het dit een laag-risico wijziging maakt. Als de gateway zich zou misdragen, zouden zoeken en bronnen nog steeds werken; alleen antwoordgeneratie zou falen, en terugschakelen naar een vorige provider is één dropdown. Voor teams die deployments automatiseren, kan dezelfde providerdefinitie via de API van Onyx worden gezaaid in plaats van doorgeklikt in de UI, maar het adminpaneel-pad is het gedocumenteerde en stabiele oppervlak, en een eenmalige instelling rechtvaardigt zelden meer.

# confirm the gateway lists the ids you plan to register
curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

# confirm a chat completion works end to end
curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

Modellen kiezen voor gegronde enterprise-antwoorden.

Modelevaluatie binnen Onyx is ongewoon concreet: stel dezelfde vraag tegen dezelfde connectoren met twee verschillende assistent-standaarden en vergelijk welk antwoord de juiste passages citeert. Het gebruikslogboek per sleutel prijst beide kandidaten op je echte vragenmix.

• Gegrond antwoorden is input-zwaar: het model leest opgehaalde passages die het antwoord dat het schrijft ver overstijgen. De prijs per inputtoken bepaalt daarom je kosten per vraag meer dan de outputprijs.
• claude-sonnet-4-6 is een sterke workspace-standaard: gedisciplineerd om binnen de opgehaalde bronnen te blijven en bestand tegen het verzinnen van beleid dat niet in de documenten staat.
• Assistenten met veel verkeer (IT-helpdesk, HR-FAQ) draaien goed op claude-haiku-4-5-20251001 of deepseek-v4-pro, waar volumeprijzen de kosten per seat voorspelbaar houden.
• Lange brondocumenten bevoordelen langecontext-ID's; gemini-3.1-pro-preview is het waard om te testen voor assistenten die grote ontwerpdocumenten of contracten in de context trekken.
• Registreer meerdere ID's in één providervermelding en wijs ze toe per assistent. Kwaliteitsniveaus per team verslaan één globaal compromismodel.

Betaal naar gebruik · onder officiële prijzen

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

Faalmodi specifiek voor Onyx.

Provider Name is geen vrij te kiezen label. Het moet overeenkomen met een LiteLLM-providersleutel, en voor een gateway is die sleutel openai. Een verzonnen naam faalt tijdens runtime met een LiteLLM-providerfout, ook al slaat het formulier prima op. De Base URL wil het /v1-suffix. De eigen documentatie van Onyx toont endpointvormen die eindigen op /v1; zonder dat lost het chat-completions-pad verkeerd op en geven verzoeken 404 bij de gateway. Model-ID's leven in Model Configurations. Een model dat je daar nooit hebt geregistreerd, kan niet als standaard worden geselecteerd, en een tikfout in een geregistreerd ID komt naar voren als een model-not-found-fout bij eerste gebruik, niet bij opslaan. De /v1/models-lijst van de gateway is de gezaghebbende spelling. Als je admin-UI het Base URL-veld mist op het aangepaste-modellenformulier, heb je een gemelde UI-regressie in sommige releases van 2026 geraakt, geen ontbrekende feature; upgraden herstelt het veld. En onthoud welke helft je hebt verplaatst: als zoekresultaten er verkeerd of verouderd uitzien, is dat indexering en connectoren, die de aangepaste provider nooit raken. Alleen gegenereerde antwoorden routeren via de gateway.

Wie routeert Onyx via een gateway.

• Self-hosted teams die leveranciersaccounts per model vervangen door één endpoint, één sleutel, en gebruik per sleutel dat netjes mapt op een workspace of afdeling.
• Ondernemingen die op Onyx hebben gestandaardiseerd voor intern zoeken en Claude-kwaliteit gegronde antwoorden willen zonder een aparte Anthropic-factureringsrelatie.
• Platformteams die meerdere assistenten op verschillende kwaliteitsniveaus draaien, geprijsd per assistent via geregistreerde model-ID's op één provider.
• Evaluatoren die antwoordkwaliteit vergelijken over modelfamilies op identieke corpora, waar elke kandidaat een geregistreerd ID is in plaats van een nieuwe providerintegratie.
• Developers zonder toegang tot de facturering van een bepaalde leverancier. Toegang op basis van opwaarderen zonder kaartvereiste verwijdert de aanmeldingsafhankelijkheid per provider.

Verifieer het endpoint en debug de eerste chat.

De twee curl-checks hierboven dekken de gateway-helft voordat je het formulier aanraakt: de ID's die je van plan bent te registreren moeten verschijnen in /v1/models, en een directe chat completion zou moeten antwoorden. Fouten zijn snel te lokaliseren binnen Onyx. Een providerfout die LiteLLM noemt, betekent dat Provider Name geen geldige sleutel is; zet hem op openai. Een authenticatiefout bij de eerste chat betekent dat de API Key niet bij het endpoint in Base URL hoort. Een model-not-found-fout is een mismatch tussen Model Configurations en de catalogus. Antwoorden die genereren maar je documenten negeren, zijn een retrieval- of connectorprobleem, ver stroomopwaarts van de LLM-provider. Zodra chats vloeien, toont de APIsRouter-console model per verzoek, tokenaantallen en uitgaven. Voor een workspace-tool waar elke vraag opgehaalde context meedraagt, is dat token-per-vraag-getal de eerlijke basis voor capaciteitsplanning, en één sleutel per workspace verandert het gebruikslogboek in een kostenrapport op afdelingsniveau.

Veelgestelde vragen