Waarom tools voor LLM-tracing nu AI-gateways bouwen

In 2026 voegden LangSmith, Langfuse, Opik en Braintrust allemaal een gateway toe vóór de modelproviders. De belangrijkste reden is controle: een tracingtool kan een modelaanroep alleen registreren, terwijl een gateway die kan tegenhouden.

Twee tools met elk een eigen taak

De afgelopen twee jaar gebruikten veel teams twee afzonderlijke tools voor applicaties met grote taalmodellen (LLM’s). Tussen de applicatie en de modelproviders stond een gateway. Die beheerde de API-sleutels van de providers, vertaalde tussen hun API’s en probeerde mislukte aanroepen opnieuw. LiteLLM, een opensourceproxy, werd hiervoor een veelgebruikte keuze. Naast de applicatie stond een tracingtool, zoals LangSmith of Langfuse. Die registreerde elke modelaanroep, toolaanroep en ophaalstap, zodat engineers konden zien wat een agent had gedaan.

Die scheiding was logisch: een gateway moet snel zijn en de API van elke provider ondersteunen, terwijl een tracingtool een goede interface, opslag voor grote payloads en een SDK nodig heeft die de applicatiecode omhult. Langfuse beschrijft deze opzet met twee tools nog steeds, met een integratie met LiteLLM Proxy die elke aanroep via de proxy naar Langfuse stuurt. In 2026 begonnen de leveranciers van tracingtools zelf een gateway te bouwen.

Vier lanceringen in zes maanden

LangChain kondigde de LangSmith LLM Gateway in mei 2026 aan als besloten bèta en stelde deze op 30 juli beschikbaar als openbare bèta. Sindsdien maakt deze ook deel uit van de implementaties van LangSmith in de eigen cloud. Braintrust heeft zijn eerdere AI-proxy uitgefaseerd en verwees gebruikers naar een nieuwe gateway, die in de previewfase zit en gratis is tot de algemene beschikbaarheid. Comet bracht de Opik LLM Gateway uit als bèta-eindpunt dat verzoeken in OpenAI-formaat accepteert. Op 4 november stelde Langfuse zijn AI Gateway beschikbaar in openbare bèta, zowel op Langfuse Cloud als voor zelfgehoste implementaties. De gateway heeft een MIT-licentie en is geschreven in Rust.

MLflow, dat begon als een tool voor de levenscyclus van machine learning en niet als tracingtool, heeft al langer een AI-gateway, met budgetmeldingen en limieten.

Gateways bestaan al jaren en de risico’s van het gebruik ervan zijn goed gedocumenteerd. De nieuwe gateways komen van bedrijven die zich bezighielden met het registreren van modelaanroepen en nu willen dat elke aanroep eerst via hen verloopt.

Waarom een budget de volledige aanvraagroute nodig heeft

Een tracingtool registreert een modelaanroep pas nadat de provider heeft geantwoord en de tokens zijn betaald. Met die registratie kun je een uitgavengrafiek maken, maar de tracingtool kan de uitgaven niet tegenhouden. Een team aan zijn budget houden, een model blokkeren of een geheim uit een prompt verwijderen: daarvoor moet het verzoek worden gecontroleerd voordat het de provider bereikt. Alleen het onderdeel dat zich in de aanvraagroute bevindt, kan dat doen.

LangChain voert dit argument aan in het bericht over de lancering. Het beschrijft hoe teams een afzonderlijke gateway, een product voor beveiligingsmaatregelen en een observabilitytool combineren, en stelt dat problemen voorkomen betekent dat beleid op de aanvraaglaag moet worden afgedwongen. De gateway antwoordt met HTTP-statuscode 402 op een aanroep die het budget zou overschrijden, in plaats van die naar de provider door te sturen.

Eén toegangspunt registreert elke aanroep

De tweede reden is de dekking. Een SDK registreert alleen de codepaden die iemand van instrumentatie heeft voorzien. Buiten die paden blijven fouten van agents vaak onopgemerkt. Een script op een laptop, een notebook of een codeeragent die een gekopieerde API-sleutel gebruikt, laat geen spoor achter. Een gateway die de providersleutels beheert, ziet elke aanroep, omdat er geen andere route naar de provider is.

Langfuse bouwt zijn gateway rond dit idee. Volgens de documentatie van de gateway is elke gateway-sleutel gekoppeld aan een gebruiker of serviceaccount en kan die metadata bevatten, zoals een team of kostenplaats. Alleen de gateway heeft de inloggegevens van de provider in beheer, en beheerders bepalen welke modellen met elke set inloggegevens mogen worden aangeroepen. LangSmith publiceert installatiepagina’s voor het routeren van Claude Code, Codex en Gemini CLI via zijn gateway. Deze agents roepen modellen aan vanaf de computer van een ontwikkelaar, buiten de tracingcode van een applicatie om.

Wat de gateway van een tracingtool toevoegt

De leveranciers van tracingtools voeren ook het omgekeerde argument aan: een zelfstandige gateway is op zichzelf niet genoeg. In het bericht over de lancering stelt Langfuse dat een zelfstandige gateway alleen tokens en kosten kan tellen, terwijl met de eigen gateway elke aanroep onderdeel wordt van een volledige trace. De gateway van Langfuse accepteert een W3C traceparent-header, zodat een aanroep via de gateway wordt opgenomen in de trace die de applicatie al is gestart. Standaard registreert de gateway gebruik en kosten, maar niet de inhoud van prompts en antwoorden.

Dit is het sterkste technische argument om de gateway in de tracingtool te integreren. Een zelfstandige gateway ziet een vlakke lijst met voltooide modelaanroepen. Een tracingtool beschikt via zijn SDK al over de toolaanroepen en ophaalstappen van de agent en kan elke gateway-aanroep in die structuur opnemen.

Er is ook een commerciële kant aan dit verhaal, al zeggen de leveranciers dat zelf niet. Wie de gateway beheert, beheert de sleutels voor de providers en het uitgavenoverzicht, en dat overzicht is wat financiële en platformteams raadplegen. Daardoor is een gateway moeilijker te vervangen dan een traceviewer. LangSmith en Langfuse benutten die positie al op verschillende manieren: LangSmith verkoopt Gateway Credits, waarmee klanten gehoste modellen zoals Kimi kunnen aanroepen zonder hun eigen providersleutel, terwijl Langfuse in zijn FAQ zegt dat het geen tokens doorverkoopt.

Wat de bètagateways nog niet kunnen

Deze gateways zijn nog jong en de leveranciers documenteren zelf waar de tekortkomingen zitten. De gateway van Langfuse ondersteunt momenteel alleen OpenAI en Anthropic; Amazon Bedrock, Google Vertex AI en Google AI Studio staan op de roadmap. Terugvalmogelijkheden tussen providers en harde uitgavenlimieten per team, gebruiker of sleutel zijn gepland, maar nog niet beschikbaar. Voorlopig biedt de gateway een dashboard voor uitgaven en waarschuwingen. De documentatie vermeldt geen snelheidslimieten of caching van reacties.

De gateway van Langfuse zet API-indelingen niet naar elkaar om, dus een OpenAI-client kan alleen OpenAI-modellen aanroepen. De zelfgehoste versie maakt alleen gebruik van de officiële URL’s van providers. Daardoor zijn Azure OpenAI, Bedrock en een interne proxy voorlopig uitgesloten. Comet beschrijft de Opik-gateway als bedoeld voor ontwikkeling en testen. Braintrust heeft de prijzen voor zijn gateway nog niet bekendgemaakt.

De gateway van LangSmith kan nu al meer dan de andere. In de documentatie worden terugvalmogelijkheden, uitgavenlimieten, snelheidslimieten en gegevensbeleid als huidige functies vermeld. De gateway ondersteunt bovendien de indelingen OpenAI Chat Completions, OpenAI Responses en Anthropic Messages. Terugvalmogelijkheden en snelheidslimieten stonden in mei nog op de planning, maar zijn dus tijdens de bèta toegevoegd. Het product als geheel wordt nog steeds als bèta aangeduid.

Belastingtests brengen een ander soort tekortkoming aan het licht. Uit een zelfgehoste benchmark van de gateway van Langfuse, LiteLLM en AcruxCore bleek dat de gateway van Langfuse per aanroep minder latentie toevoegde dan LiteLLM. Met de standaardinstellingen van Docker mislukten echter 739 van de 1.000 gelijktijdige streams, omdat het proces de standaardlimiet van Docker van 1.024 geopende bestanden niet wijzigde. Eén regel in het Compose-bestand van Langfuse loste dat op.

Vergeleken met deze bèta’s ondersteunt LiteLLM, al jarenlang een zelfstandige gateway, meer dan 100 providers en biedt het al virtuele sleutels, uitgavenregistratie, beveiligingsmaatregelen, taakverdeling en een beheerdersdashboard. LiteLLM verplaatst de afhandeling van verzoeken bovendien van Python naar Rust. De Rust-AI-gateway is in bèta en het team van LiteLLM verwacht dat verzoeken in de stijl van Anthropic, /v1/messages, tegen 1 december van begin tot eind in Rust worden afgehandeld, met ongeveer 20 keer minder latentie. Enkele opensourceplatforms, zoals MLflow en AcruxCore, leveren al een gateway en tracing in één product.

Waarom je ze gescheiden houdt

Een gateway samenvoegen met de tracer brengt kosten met zich mee; de grootste daarvan is de onderlinge afhankelijkheid. Met een afzonderlijke gateway kan een team van tracingleverancier wisselen door een loggingcallback te wijzigen. Wanneer de tracer ook de gateway is, moeten ook de basis-URL, sleutels en model-ID’s van elke service worden aangepast. Langfuse schrijft model-ID’s bijvoorbeeld in de vorm credential:model.

De tracer wordt dan ook een afhankelijkheid tijdens de uitvoering. Als een tracingbackend uitvalt, verliest het team traces. Valt een gateway uit, dan mislukken modelaanroepen. Een tracingleverancier die de gateway beheert, moet nu dus de uptime van kritieke infrastructuur garanderen.

Ook beveiligingsleveranciers willen een plek in het verzoekpad. Palo Alto Networks heeft de overname van Portkey, een zelfstandige gateway, in mei 2026 afgerond en maakte die gateway onderdeel van zijn Prisma AIRS-platform. Een beveiligingsteam wil de gateway mogelijk zelf beheren in plaats van deze onder te brengen in een observability-tool. Gateways zijn ook een doelwit voor aanvallers geworden, zoals het lek in de toeleveringsketen van LiteLLM in maart liet zien.

Hoe teams een keuze kunnen maken

Teams kunnen beginnen met een lijst van alles wat moet gebeuren voordat een model wordt aangeroepen. Als ze alleen inzicht nodig hebben, volstaat een tracer naast het verzoekpad; die voegt geen afhankelijkheid tijdens de uitvoering toe. Hebben ze ook budgetten, sleutelbeleid of goedkeuring van modellen nodig, dan hebben ze een gateway nodig.

Daarna komt de ondersteuning van providers aan bod. Een team moet alle providers en API-indelingen noteren die het in productie gebruikt, waaronder Azure OpenAI en Bedrock, en die lijst vergelijken met wat elke gateway momenteel ondersteunt, niet met wat op de roadmap staat.

Teams die LiteLLM al gebruiken, hebben weinig reden om over te stappen zolang een gateway in bèta niet iets biedt wat ze nog missen. Het belangrijkste voordeel van de gateway van een tracer is dat een gatewayaanroep wordt opgenomen in de trace van de agent; dat voordeel moet een migratie rechtvaardigen. Teams die helemaal opnieuw beginnen, kunnen de gateway als afzonderlijke laag houden, zelfs als één leverancier beide levert. Als de basis-URL en sleutels in één configuratiemodule staan, is een latere overstap een configuratiewijziging in plaats van een codewijziging.

De meeste van deze gateways worden aangeduid als bèta of preview, dus de lijst met tekortkomingen zal snel korter worden. De open vraag is wie binnen een doorsnee bedrijf het verzoekpad beheert: het observabilityteam, het platformteam dat een zelfstandige gateway beheert of het beveiligingsteam. Dit jaar hebben LangSmith en Langfuse hun eigen gateways gebouwd en heeft Palo Alto Networks er een gekocht, maar in veel systemen loopt het verzoekpad nog steeds via LiteLLM.