Beperkingen voor modelcontext, upstream API’s en de eigen infrastructuur zijn verschillende dingen; behandel ze niet als één soort limiet. De proefinstellingen — waaronder 8 MiB voor een request en 1.024 berichten — zijn niet onderbouwd als algemene industriestandaard.
Gepubliceerd doorAfbeeldingen gegenereerd met GPT Image 2
Research answer
![[GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W](https://d15bya8fi85z1v.cloudfront.net/chat/asPK4DNv50bsymHMgLZKWhkmJ3B3/thumbnails/BE539E29210DE042959E/C6C71DEEB633A101A564-medium-640.webp)
Create a landscape editorial hero image for this Studio Global article: [GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W. Article summary: <tool call {"name":"attempt completion","arguments":{"result":"有必要设置资源边界,但没有充分依据把这六个具体数值当作模型能力或行业标准。当前最值得反思的不是“限制太多”,而是试验参数、网关资源预算、上游协议限制和模型上下文容量被混成了同一种限制。\n\n 1.. Topic tags: general web, openai, agents, prompt engineering, ai. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clickbait thumbnails, icons, an
Een AI-gateway moet voorkomen dat een onbeperkt request de parser, het geheugen of de beschikbare capaciteit overbelast. Maar daaruit volgt niet dat elke ingestelde grens ook een goede productielimiet is. De kernvraag is: welke grens beschermt het model, welke volgt uit de upstream-API en welke is alleen nodig om de gateway zelf gezond te houden?
De gateway in kwestie is geen modelserver en ook geen volledig transparante doorgeefluik. Hij bouwt requests op, verwerkt toolprotocollen, past de gespreksgeschiedenis aan en zet afbeeldingen om in verwijzingen naar upstream-bijlagen. Dat blijkt uit de implementatie van requestopbouw en geschiedenisverwerking en de codering van bijlagemeldingen.
Daarom is het nuttig drie categorieën uit elkaar te houden:
Dat data uiteindelijk als getallen wordt verwerkt, maakt bytes, JSON-objecten, tokens en geheugengebruik niet onderling uitwisselbaar. De gateway draait geen modelinference, maar moet wel de ontvangst en omzetting van requests kunnen verwerken.
Enkele officiële specificaties laten zien waarom je modelcapaciteit en gatewaylimieten niet op één hoop moet gooien:
| API of functie | Geverifieerde specificatie | Betekenis voor een gateway |
|---|---|---|
| OpenAI GPT-5.5 | Een contextvenster van 1.050.000 tokens en maximaal 128.000 outputtokens. |
Dit zegt niet hoeveel MiB aan HTTP-data de gateway moet accepteren. Tokens en requestbytes meten iets anders. |
| Anthropic Messages API en Token Counting API | Op 28 oktober 2026 verhoogde Anthropic de maximale requestgrootte voor de first-party API van 32 MB naar 128 MB. |
32 MB is daarmee geen actuele algemene limiet voor die API. De eigen gatewaylimiet van 8 MiB is ook niet automatisch de limiet van Claude. |
| Anthropic Messages API | Een request kan maximaal 100.000 berichten bevatten. |
Een grens van 1.024 berichten is geen gezamenlijke standaard van de sector. Dat de API meer toestaat, verplicht een lokale gateway niet om dat maximum over te nemen. |
| Anthropic API voor afbeeldingen | Maximaal 100 afbeeldingen per request voor modellen met een contextvenster van 200.000 tokens en 600 voor andere modellen, naast beperkingen voor afmetingen. |
Aantal en afmetingen zijn afzonderlijke zaken; ook een gateway kan verschillende soorten bescherming nodig hebben. |
Bij de stateless Messages API wordt bovendien de volledige gesprekshistorie bij elk request meegestuurd. Een korte nieuwe prompt kan dus samengaan met een groot totaalrequest.15
Deze specificaties zijn nuttige referentiepunten, maar bewijzen op zichzelf niet dat een route met een vergelijkbare modelnaam via StudioGlobal dezelfde API-voorwaarden of capaciteit heeft. Voor Google Vertex, AI Studio en xAI is in de aangeleverde analyse geen vergelijkbare, voldoende onderbouwde parametervergelijking beschikbaar.
De zes onderstaande getallen zijn in de code als proefconfiguratie gedefinieerd; ze zijn niet vanzelfsprekend de huidige productiegrenzen.[internal/chatadmission/config.go:12]
| Instelling | Waar kan die voor beschermen? | Beoordeling van de genoemde waarde |
|---|---|---|
| Requestbody: 8 MiB | Onbeperkte ontvangst en verdere verwerking van grote requests. | Kan een tijdelijke testgrens zijn, maar is niet automatisch geschikt als vaste limiet voor alle modellen en soorten input. Een groot contextvenster bewijst op zichzelf ook niet dat 8 MiB te weinig is. |
| Geheugenbudget voor de body: 64 MiB | Intern geheugengebruik van de gateway. | Dit is een infrastructuurkeuze, geen maat voor modelcapaciteit. De passende waarde hangt af van de deployment, gelijktijdigheid en verwerkingskosten. |
| Aantal berichten: 1.024 | Requests met uitzonderlijk veel berichtobjecten. | Berichten tellen is niet hetzelfde als context meten. Veel korte berichten en één groot bericht kunnen heel verschillende belasting opleveren. |
| Aantal tools: 128 | De omvang van het protocol en de verwerking van tooldefinities. | Er is geen onderbouwing dat dit een gezamenlijke norm van de vier genoemde aanbieders is. Aantal, omvang en bruikbaarheid van tools zijn aparte vragen. |
| JSON-diepte: 32 | Bescherming tegen extreem diep geneste structuren tijdens parsing. | Dit gaat over de parser van de gateway, niet over hoe diep een model kan redeneren. De waarde vraagt om onderbouwing met geldige toolparameters en parsergedrag. |
| JSON-nodes: 65.536 | Bescherming tegen requests die veel objecten en waarden uitvouwen. | Dit is geen tokenlimiet en er is geen geverifieerde gezamenlijke norm. De noodzaak hangt ook af van andere limieten voor bytes en geheugen. |
Let op: een limiet voor geneste schema’s bij gestructureerde output is niet automatisch geschikt als limiet voor alle JSON-input. Bovendien is JSON in een berichttekst niet hetzelfde als een even diep genest object in de HTTP-requeststructuur.
Ook het aantal tools is niet simpelweg een kwestie van “meer is beter”. OpenAI beschrijft een manier om tooldefinities pas te laden wanneer ze nodig zijn.2 Dat maakt het terugdringen van onnodige tooldefinities een mogelijke optimalisatie, naast het verhogen van een harde limiet.
In de oudere voorcontrole tellen zowel sleutels als waarden mee als nodes; de huidige streamscanner telt hoofdzakelijk bij waarden. Daardoor kunnen twee implementaties met dezelfde grens van 65.536 toch verschillende requests als zwaar inschatten. Zie de oude nodetelling, telling van sleutels en streamtelling.
De oude voorcontrole raamt afgeleid geheugengebruik onder meer op basis van vier keer de bodygrootte, 512 bytes per node en een toeslag voor gedecodeerde strings. De code beschrijft dit als een conservatieve schatting, niet als daadwerkelijk heap- of RSS-gebruik. De verwerkingsfase reserveert daarnaast de volledige afgeleide capaciteit voor één request.[internal/chatadmission/preflight.go:17][internal/chatadmission/processing.go:18]
Zo’n conservatieve toelatingscontrole kan nuttig zijn, maar bewijst niet dat een budget van 64 MiB een proces tegen iedere geheugenspiek beschermt.
De huidige streamconfiguratie kent een totale bodylimiet van ongeveer 53,8 MiB, maar beperkt niet-media-JSON tot 512 KiB. Het standaardbudget voor afgeleide data is 4 MiB.[internal/chatadmission/phase3.go:10]
Alleen de oude proeflimiet aanpassen verandert dus niet per se het huidige knelpunt voor tekst. En een ruimere limiet voor metadata invoeren zonder de parsing en afgeleide geheugenkosten opnieuw te beoordelen, is evenmin vanzelfsprekend veilig.
Bij het opbouwen van de upstream-payload gelden een budget van 56 veilige berichten en een telling van 480.000 eenheden. Die telling gebruikt voor tekst een schatting op basis van tekens, geen exacte tokenizer per aanbieder. Bij tekst kan de gateway volledige groepen uit de geschiedenis laten vallen om binnen het budget te blijven; requests met media volgen die inkortingsroute niet.[internal/upstream/studioglobal/payload.go:359][internal/upstream/studioglobal/payload.go:400]
Afbeeldingen toevoegen raakt daarmee niet alleen de limiet per afbeelding, maar ook hoe lange gesprekshistorie wordt behandeld. Dat verdient minstens zoveel aandacht als één losse groottegrens.
Een lichte adapter die zegt requests door te sturen, moet duidelijk maken wanneer hij zelf de gesprekshistorie verwijdert of de telling verandert. Noodzakelijke protocolomzetting en beheer van de context zijn niet hetzelfde.
Ook is het niet vanzelfsprekend om tegelijk de grootste requests van alle aanbieders te accepteren, meerdere kopieën tijdens parsing te maken, de gelijktijdigheid te verhogen en dezelfde bescheiden geheugengrenzen te behouden. De ingestelde containerlimiet is 256 MiB.[docker-compose.yml:43] De verwerkingswijze, deploymentcapaciteit en toegestane requestgrootte moeten dus op elkaar worden afgestemd.
Als de gateway vooral een lokale Cline-installatie bedient, ligt het voor de hand eerst te toetsen of echte programmeerrequests goed werken — zonder daarom bescherming tegen resource-uitputting te schrappen. De lokale luisterconfiguratie past bij die toepassing, maar bewijst niet dat alle beschermingsgrenzen overbodig zijn.[docker-compose.yml:29]
Behoud grenzen voor ontvangst, parsing, gelijktijdigheid, time-outs en het vrijgeven van resources. Maak de zes proefwaarden niet zonder verdere onderbouwing tot een algemene productiebelofte. Leg per limiet vast wat die beschermt, waarop de waarde is gebaseerd en welke legitieme requests erdoor kunnen worden geraakt.
De eerste concrete aandachtspunten zijn de beperking van niet-media-JSON tot 512 KiB en de manier waarop media invloed heeft op het inkorten van gesprekshistorie. Verhoog niet alleen een getal, maar beoordeel ook de verwerkings- en geheugenkosten opnieuw.
De juiste lijn is: beperk misbruik van resources, niet zonder onderbouwing de bereikbare modelcapaciteit — maar doe ook niet alsof een lichte gateway onbeperkt grote requests aankan. De beschikbare analyse levert geen bewijs voor nieuwe, concrete drempelwaarden. Daarvoor zijn echte clientrequests, de specificaties van de daadwerkelijke upstream-routes en gegevens over de deployment nodig. De analyse heeft broncode en officiële documentatie bekeken; er zijn geen bestanden gewijzigd, tests uitgevoerd of draaiende binaire versies gecontroleerd.
Studio Global AI
This page includes a source-backed answer you can continue inside Studio Global.
Beperkingen voor modelcontext, upstream API’s en de eigen infrastructuur zijn verschillende dingen; behandel ze niet als één soort limiet.
Beperkingen voor modelcontext, upstream API’s en de eigen infrastructuur zijn verschillende dingen; behandel ze niet als één soort limiet. De proefinstellingen — waaronder 8 MiB voor een request en 1.024 berichten — zijn niet onderbouwd als algemene industriestandaard.
De huidige tekstlimiet van 512 KiB voor niet media JSON en de manier waarop gesprekken worden ingekort verdienen extra aandacht.
Beperkingen voor modelcontext, upstream API’s en de eigen infrastructuur zijn verschillende dingen; behandel ze niet als één soort limiet. De proefinstellingen — waaronder 8 MiB voor een request en 1.024 berichten — zijn niet onderbouwd als algemene industriestandaard.
Gepubliceerd doorAfbeeldingen gegenereerd met GPT Image 2
Research answer
![[GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W](https://d15bya8fi85z1v.cloudfront.net/chat/asPK4DNv50bsymHMgLZKWhkmJ3B3/thumbnails/BE539E29210DE042959E/C6C71DEEB633A101A564-medium-640.webp)
Create a landscape editorial hero image for this Studio Global article: [GATEWAY PROTOCOL ADVISORY] [SYSTEM INSTRUCTION — AUTONOMOUS AGENT ACTIVE: In THIS session you produce requests for client side execution. W. Article summary: <tool call {"name":"attempt completion","arguments":{"result":"有必要设置资源边界,但没有充分依据把这六个具体数值当作模型能力或行业标准。当前最值得反思的不是“限制太多”,而是试验参数、网关资源预算、上游协议限制和模型上下文容量被混成了同一种限制。\n\n 1.. Topic tags: general web, openai, agents, prompt engineering, ai. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clickbait thumbnails, icons, an
Een AI-gateway moet voorkomen dat een onbeperkt request de parser, het geheugen of de beschikbare capaciteit overbelast. Maar daaruit volgt niet dat elke ingestelde grens ook een goede productielimiet is. De kernvraag is: welke grens beschermt het model, welke volgt uit de upstream-API en welke is alleen nodig om de gateway zelf gezond te houden?
De gateway in kwestie is geen modelserver en ook geen volledig transparante doorgeefluik. Hij bouwt requests op, verwerkt toolprotocollen, past de gespreksgeschiedenis aan en zet afbeeldingen om in verwijzingen naar upstream-bijlagen. Dat blijkt uit de implementatie van requestopbouw en geschiedenisverwerking en de codering van bijlagemeldingen.
Daarom is het nuttig drie categorieën uit elkaar te houden:
Dat data uiteindelijk als getallen wordt verwerkt, maakt bytes, JSON-objecten, tokens en geheugengebruik niet onderling uitwisselbaar. De gateway draait geen modelinference, maar moet wel de ontvangst en omzetting van requests kunnen verwerken.
Enkele officiële specificaties laten zien waarom je modelcapaciteit en gatewaylimieten niet op één hoop moet gooien:
| API of functie | Geverifieerde specificatie | Betekenis voor een gateway |
|---|---|---|
| OpenAI GPT-5.5 | Een contextvenster van 1.050.000 tokens en maximaal 128.000 outputtokens. |
Dit zegt niet hoeveel MiB aan HTTP-data de gateway moet accepteren. Tokens en requestbytes meten iets anders. |
| Anthropic Messages API en Token Counting API | Op 28 oktober 2026 verhoogde Anthropic de maximale requestgrootte voor de first-party API van 32 MB naar 128 MB. |
32 MB is daarmee geen actuele algemene limiet voor die API. De eigen gatewaylimiet van 8 MiB is ook niet automatisch de limiet van Claude. |
| Anthropic Messages API | Een request kan maximaal 100.000 berichten bevatten. |
Een grens van 1.024 berichten is geen gezamenlijke standaard van de sector. Dat de API meer toestaat, verplicht een lokale gateway niet om dat maximum over te nemen. |
| Anthropic API voor afbeeldingen | Maximaal 100 afbeeldingen per request voor modellen met een contextvenster van 200.000 tokens en 600 voor andere modellen, naast beperkingen voor afmetingen. |
Aantal en afmetingen zijn afzonderlijke zaken; ook een gateway kan verschillende soorten bescherming nodig hebben. |
Bij de stateless Messages API wordt bovendien de volledige gesprekshistorie bij elk request meegestuurd. Een korte nieuwe prompt kan dus samengaan met een groot totaalrequest.15
Deze specificaties zijn nuttige referentiepunten, maar bewijzen op zichzelf niet dat een route met een vergelijkbare modelnaam via StudioGlobal dezelfde API-voorwaarden of capaciteit heeft. Voor Google Vertex, AI Studio en xAI is in de aangeleverde analyse geen vergelijkbare, voldoende onderbouwde parametervergelijking beschikbaar.
De zes onderstaande getallen zijn in de code als proefconfiguratie gedefinieerd; ze zijn niet vanzelfsprekend de huidige productiegrenzen.[internal/chatadmission/config.go:12]
| Instelling | Waar kan die voor beschermen? | Beoordeling van de genoemde waarde |
|---|---|---|
| Requestbody: 8 MiB | Onbeperkte ontvangst en verdere verwerking van grote requests. | Kan een tijdelijke testgrens zijn, maar is niet automatisch geschikt als vaste limiet voor alle modellen en soorten input. Een groot contextvenster bewijst op zichzelf ook niet dat 8 MiB te weinig is. |
| Geheugenbudget voor de body: 64 MiB | Intern geheugengebruik van de gateway. | Dit is een infrastructuurkeuze, geen maat voor modelcapaciteit. De passende waarde hangt af van de deployment, gelijktijdigheid en verwerkingskosten. |
| Aantal berichten: 1.024 | Requests met uitzonderlijk veel berichtobjecten. | Berichten tellen is niet hetzelfde als context meten. Veel korte berichten en één groot bericht kunnen heel verschillende belasting opleveren. |
| Aantal tools: 128 | De omvang van het protocol en de verwerking van tooldefinities. | Er is geen onderbouwing dat dit een gezamenlijke norm van de vier genoemde aanbieders is. Aantal, omvang en bruikbaarheid van tools zijn aparte vragen. |
| JSON-diepte: 32 | Bescherming tegen extreem diep geneste structuren tijdens parsing. | Dit gaat over de parser van de gateway, niet over hoe diep een model kan redeneren. De waarde vraagt om onderbouwing met geldige toolparameters en parsergedrag. |
| JSON-nodes: 65.536 | Bescherming tegen requests die veel objecten en waarden uitvouwen. | Dit is geen tokenlimiet en er is geen geverifieerde gezamenlijke norm. De noodzaak hangt ook af van andere limieten voor bytes en geheugen. |
Let op: een limiet voor geneste schema’s bij gestructureerde output is niet automatisch geschikt als limiet voor alle JSON-input. Bovendien is JSON in een berichttekst niet hetzelfde als een even diep genest object in de HTTP-requeststructuur.
Ook het aantal tools is niet simpelweg een kwestie van “meer is beter”. OpenAI beschrijft een manier om tooldefinities pas te laden wanneer ze nodig zijn.2 Dat maakt het terugdringen van onnodige tooldefinities een mogelijke optimalisatie, naast het verhogen van een harde limiet.
In de oudere voorcontrole tellen zowel sleutels als waarden mee als nodes; de huidige streamscanner telt hoofdzakelijk bij waarden. Daardoor kunnen twee implementaties met dezelfde grens van 65.536 toch verschillende requests als zwaar inschatten. Zie de oude nodetelling, telling van sleutels en streamtelling.
De oude voorcontrole raamt afgeleid geheugengebruik onder meer op basis van vier keer de bodygrootte, 512 bytes per node en een toeslag voor gedecodeerde strings. De code beschrijft dit als een conservatieve schatting, niet als daadwerkelijk heap- of RSS-gebruik. De verwerkingsfase reserveert daarnaast de volledige afgeleide capaciteit voor één request.[internal/chatadmission/preflight.go:17][internal/chatadmission/processing.go:18]
Zo’n conservatieve toelatingscontrole kan nuttig zijn, maar bewijst niet dat een budget van 64 MiB een proces tegen iedere geheugenspiek beschermt.
De huidige streamconfiguratie kent een totale bodylimiet van ongeveer 53,8 MiB, maar beperkt niet-media-JSON tot 512 KiB. Het standaardbudget voor afgeleide data is 4 MiB.[internal/chatadmission/phase3.go:10]
Alleen de oude proeflimiet aanpassen verandert dus niet per se het huidige knelpunt voor tekst. En een ruimere limiet voor metadata invoeren zonder de parsing en afgeleide geheugenkosten opnieuw te beoordelen, is evenmin vanzelfsprekend veilig.
Bij het opbouwen van de upstream-payload gelden een budget van 56 veilige berichten en een telling van 480.000 eenheden. Die telling gebruikt voor tekst een schatting op basis van tekens, geen exacte tokenizer per aanbieder. Bij tekst kan de gateway volledige groepen uit de geschiedenis laten vallen om binnen het budget te blijven; requests met media volgen die inkortingsroute niet.[internal/upstream/studioglobal/payload.go:359][internal/upstream/studioglobal/payload.go:400]
Afbeeldingen toevoegen raakt daarmee niet alleen de limiet per afbeelding, maar ook hoe lange gesprekshistorie wordt behandeld. Dat verdient minstens zoveel aandacht als één losse groottegrens.
Een lichte adapter die zegt requests door te sturen, moet duidelijk maken wanneer hij zelf de gesprekshistorie verwijdert of de telling verandert. Noodzakelijke protocolomzetting en beheer van de context zijn niet hetzelfde.
Ook is het niet vanzelfsprekend om tegelijk de grootste requests van alle aanbieders te accepteren, meerdere kopieën tijdens parsing te maken, de gelijktijdigheid te verhogen en dezelfde bescheiden geheugengrenzen te behouden. De ingestelde containerlimiet is 256 MiB.[docker-compose.yml:43] De verwerkingswijze, deploymentcapaciteit en toegestane requestgrootte moeten dus op elkaar worden afgestemd.
Als de gateway vooral een lokale Cline-installatie bedient, ligt het voor de hand eerst te toetsen of echte programmeerrequests goed werken — zonder daarom bescherming tegen resource-uitputting te schrappen. De lokale luisterconfiguratie past bij die toepassing, maar bewijst niet dat alle beschermingsgrenzen overbodig zijn.[docker-compose.yml:29]
Behoud grenzen voor ontvangst, parsing, gelijktijdigheid, time-outs en het vrijgeven van resources. Maak de zes proefwaarden niet zonder verdere onderbouwing tot een algemene productiebelofte. Leg per limiet vast wat die beschermt, waarop de waarde is gebaseerd en welke legitieme requests erdoor kunnen worden geraakt.
De eerste concrete aandachtspunten zijn de beperking van niet-media-JSON tot 512 KiB en de manier waarop media invloed heeft op het inkorten van gesprekshistorie. Verhoog niet alleen een getal, maar beoordeel ook de verwerkings- en geheugenkosten opnieuw.
De juiste lijn is: beperk misbruik van resources, niet zonder onderbouwing de bereikbare modelcapaciteit — maar doe ook niet alsof een lichte gateway onbeperkt grote requests aankan. De beschikbare analyse levert geen bewijs voor nieuwe, concrete drempelwaarden. Daarvoor zijn echte clientrequests, de specificaties van de daadwerkelijke upstream-routes en gegevens over de deployment nodig. De analyse heeft broncode en officiële documentatie bekeken; er zijn geen bestanden gewijzigd, tests uitgevoerd of draaiende binaire versies gecontroleerd.
Studio Global AI
This page includes a source-backed answer you can continue inside Studio Global.
Beperkingen voor modelcontext, upstream API’s en de eigen infrastructuur zijn verschillende dingen; behandel ze niet als één soort limiet.
Beperkingen voor modelcontext, upstream API’s en de eigen infrastructuur zijn verschillende dingen; behandel ze niet als één soort limiet. De proefinstellingen — waaronder 8 MiB voor een request en 1.024 berichten — zijn niet onderbouwd als algemene industriestandaard.
De huidige tekstlimiet van 512 KiB voor niet media JSON en de manier waarop gesprekken worden ingekort verdienen extra aandacht.