Hoe zet je {{1}}één agent uit?{{/1}} {{2}}Uitgavenlimieten en de kill switch{{/2}}

Hier is een vraag die het stellen waard is over elke agentconfiguratie voordat je die opschaalt: welke exacte handeling stopt één agent, nu meteen, zonder jou te stoppen? Voor de meeste implementaties in augustus 2026 is het eerlijke antwoord "mijn eigen wachtwoord wijzigen" — wat elke agent die je draait stopt en je als neveneffect buiten je eigen accounts sluit. Dat is geen noodknop; het is een zelfvernietiging. OrcaID's maandelijkse limiet en pauze met één klik zijn een poging tot de versie die zich in plaats daarvan tot de agent beperkt.

De reden dat dit plotseling urgent is, is dat agents langlopend zijn geworden. SpaceXAI's Grok Bot, gelanceerd op 11 augustus 2026, is gebouwd om te blijven werken nadat je de laptop sluit. Hermes Agent van Nous Research is ontworpen om maandenlang te draaien met een ingebouwde cron-planner. OpenClaw draait proactieve achtergrondtaken op je eigen machine. In alle drie de gevallen is de standaardtoestand van de software handelen, en de standaardtoestand van de operator is niet kijken. Besturingselementen die zijn ontworpen rond een begeleide sessie overleven die omkering niet.

Een melding is geen limiet.

De meeste uitgavencontroles die tegenwoordig beschikbaar zijn, zijn beleefde meldingen. Je stelt een drempel in op 80% van het budget, je krijgt een e-mail en de uitgaven gaan gewoon door. Voor mensgestuurd gebruik is dat prima, omdat de e-mail iemand bereikt die kan besluiten te stoppen.

Er staat een getuigenis op SpaceXAI's eigen Grok Bot-pagina die als risicoverklaring moet worden gelezen: "Ik heb Grok Bot ooit een workflow laten zien en nu vertrouw ik er volledig op dat hij voor altijd blijft draaien. Ik heb het gevoel dat ik 2–3x efficiënter ben, omdat hij het doet zonder dat ik hoef te verifiëren en te beoordelen." Dat is een tevreden gebruiker die nauwkeurig de toestand beschrijft waarvan een uitgavenwaarschuwing afhangt dat die niet bestaat. Een van de vijf specialistische categorieën die dezelfde pagina noemt, is uitgaven.

Voor een onbeheerde agent is een melding bijna nutteloos, en de reden is timing in plaats van principe. Een agent in een lus kan op één middag een maandbudget verbranden. Een melding die wordt afgeleverd bij iemand die slaapt, in het weekend, of gewoon in een vergadering zit, arriveert na de gebeurtenis die ze moest voorkomen. Erger nog, meldingsdrempels worden meestal geëvalueerd op basis van facturatiegegevens die achterlopen — tegen de tijd dat het getal maatgevend is, is de uitgave al historisch.

Een cap is een ander object. Op orcaid.ai wordt de maandelijkse cap beschreven als een harde stop, en de kaart "weigert op het moment dat die je cap overschrijdt". Die formulering is het hele onderscheid: de controle wordt afgedwongen op het punt van de transactie, door deze te weigeren, in plaats van achteraf te rapporteren. Een agent die een harde cap bereikt, faalt — wat het juiste gedrag is voor software die zijn bevoegdheid heeft overschreden, en iets dat je alleen kunt tolereren als de fout netjes is.

Dit houdt verband met waarom fondsen worden gereserveerd voordat ze worden uitgegeven. Een plafond dat alleen wordt beoordeeld op basis van afgewikkelde transacties kan worden overschreden door alles wat onderweg is. Een plafond dat wordt beoordeeld op basis van reserveringen plus afgewikkelde uitgaven kan dat niet, en dat is wat "hard" een verdedigbaar woord maakt.

Drie dingen waar een dop aan moet voldoen om te werken

Niet elke limiet die zichzelf een cap noemt, doet het werk voor een onbeheerde agent. Drie eigenschappen onderscheiden de echte.

Per agent, niet per account. Een enkel plafond voor een vloot moet hoog genoeg worden ingesteld voor het duurste lid, wat betekent dat elke andere agent draait met een limiet die hij nooit zal bereiken — en dus geen enkele bescherming biedt. Grok Bot's ontwerp gaat uit van meerdere bots parallel met specialisten voor verschillende taken; een onderzoeksbot die veel goedkope aanroepen doet en een inkoopbot die af en toe grote aankopen doet, hebben verschillende getallen nodig, en één gedeelde limiet kan dat niet uitdrukken.

Afgedwongen bij de transactie, niet in het rapport.Hierboven behandeld. Als het mechanisme "we merken het en vertellen het je" is, is het monitoring.

Beide kostenposten worden gedekt. Een agent geeft uit aan inferentie en aan de wereld. Het alleen begrenzen van inferentie laat de kaart onbegrensd; het alleen begrenzen van de kaart laat een agent in een lus vrij om onbeperkt tokens te verbranden. Dit is waarom het enkele grootboek ertoe doet als controlemiddel en niet slechts als gemak — "tokens + dollars, één grootboek" is de enige vorm waarin een totaal betekenisvol is.

Budgetwaarschuwing bij 80%. Stopt een lus om 3 uur 's nachts?: Nee. Beperkt tot één agent?: Soms. Dekt tokens en dollars?: Zelden.

Kaart met een maandelijkse limiet. Stopt een 3am-lus?: Gedeeltelijk — na de limiet, en alleen voor kaartuitgaven. Beperkt tot één agent?: Alleen met één kaart per agent. Dekt tokens en dollars?: Nee.

Modelbudget per sleutel. Stopt een 3am-loop?: Alleen voor inferentie. Beperkt tot één agent?: Ja. Dekt tokens en dollars?: Nee.

Harde limiet op een gefinancierde account per agent. Stopt een lus om 3 uur 's nachts?: Ja. Beperkt zich tot één agent?: Ja. Omvat tokens en dollars?: Ja, als het grootboek verenigd is.

Het intrekkingsprobleem is de moeilijkere helft.

Limieten pakken de agent aan die te veel uitgeeft. Ze doen niets voor de agent die zich binnen het budget verkeerd gedraagt — gegevens lekt, de verkeerde mensen mailt, zich voor dingen aanmeldt, handelt naar een instructie die het had moeten negeren. Daarvoor moet je het stoppen, en juist bij het stoppen faalt het model van de geleende identiteit het hardst.

Als een agent met uw referenties werkt, zijn al uw opties slecht. Het roteren van de referentie stopt de agent, maar stopt ook u en alle andere agents die deze delen. Het intrekken van een OAuth-machtiging is netter, maar vaak grof en doet niets aan een actieve browsersessie. Het beëindigen van het proces werkt alleen voor agents die u host — niet voor cloud-gebaseerde bots. En in elk geval voert u een operatie uit op uw eigen identiteit om een stuk software te disciplineren.

De door OrcaID vermelde versie is een kill switch die wordt weergegeven als "Actief · één klik om te pauzeren", met de framing van de site dat pauzeren betekent dat "alles stilvalt. Niets anders beweegt." Het belangrijke woord is niets anders— de reikwijdte is de handle, dus de wallet, de kaart, de inbox en het nummer die van die naam zijn afgeleid, stoppen allemaal tegelijk, en de accounts van de operator zelf blijven onaangeroerd.

Dat is alleen mogelijk omdat de bevoegdheid van de agent oorspronkelijk gescheiden was. Je kunt selectieve intrekking niet achteraf toepassen op een gedeelde credential; de granulariteit van uitschakeling wordt bepaald door de granulariteit van identiteit. Dit is het sterkste argument in het hele OrcaID-ontwerp en het argument dat verder generaliseert dan welk product dan ook: als je één agent wilt kunnen uitschakelen, heeft die agent een eigen identiteit nodig, en dat moet je beslissen voordat je een vloot hebt.

Het geheel lezen als een riem

De framing op orcaid.ai is bewust smal: "de naam is de leiband. Eén ding om te financieren. Eén ding om te begrenzen. Eén ding om te trekken." Drie stappen — reserveren, financieren en begrenzen, trekken.

Wat dat meer dan een slogan maakt, is dat alle drie op hetzelfde object werken. De faalmodus van agent-governance in de praktijk is dat de bedieningselementen op verschillende plekken leven: uitgaven in een kaartenportaal, toegang in een identiteitsprovider, modelbudget in een leveranciersdashboard, en de uitschakelaar nergens in het bijzonder. Een operator die onder tijdsdruk vier consoles voor zich heeft, zal geen daarvan correct gebruiken. Het samenbrengen van financiering, limiet en stop op één hendel betekent dat er één plek is om te kijken en één ding om te doen.

Het is belangrijk om te benadrukken dat een limiet en een schakelaar op zichzelf geen veiligheidsarchitectuur vormen. Ze begrenzen de kosten en ze begrenzen de duur; ze beslissen niet of een specifieke actie gepast was. Dat is een andere controle — beoordelen wat een draaiende agent per verzoek mag doen — en die hoort daarnaast, niet in plaats daarvan. Limieten beantwoorden "hoeveel"; beleid beantwoordt "of".

Status, duidelijk gezegd: op orcaid.ai zijn de wallet, kaart en het nummer gelabeld als "bij verificatie" en de inbox "bij lancering". Het reserveren van een gebruikersnaam is gratis en opent geen account of start geen facturering. De limiet en kill switch die hier worden beschreven zijn ontwerpclaims bij preregistratie, en er is geen integratie met Grok Bot, OpenClaw of Hermes Agent aangekondigd.

Wat deze week te regelen

Geen van de OrcaID-controls is live, dus hier is de versie die niet wacht.

Schrijf de stopprocedure voor één agent op, en als het het veranderen van iets van jezelf betreft, behandel dat dan als een bevinding in plaats van een plan. Geef elke agent zijn eigen API-sleutel, zodat modeluitgaven zowel toewijsbaar als onafhankelijk intrekbaar zijn — dit is meestal gratis en is de verandering met de hoogste hefboomwerking die vandaag beschikbaar is. Stel een echte limiet in op welk betaalmiddel agenten ook kunnen bereiken, gekozen als een bedrag dat je zou accepteren te verliezen, in plaats van een limiet die voor het gemak is gekozen. Zet je alerts om in stops waar het platform het toestaat, want een alert die afgaat terwijl je slaapt, heeft al gefaald. En controleer of er überhaupt iets een limiet stelt aan je tokenuitgaven; een agent in een redeneerlus zonder plafond is de meest voorkomende dure verrassing van 2026.

De kern

Agents die altijd actief zijn, hebben de aanname omgekeerd waarop elke uitgavencontrole was gebouwd. Wanneer de standaardtoestand van software handelen is en de standaardtoestand van de operator afwezigheid is, is een melding geen controlemiddel en zijn gedeelde inloggegevens geen schakelaar. De twee vragen die ertoe doen — hoeveel kan deze agent uitgeven voordat iets hem weigert, en welke enkele actie deze agent stopt zonder mij te stoppen — hebben in de meeste implementaties die vandaag draaien geen goed antwoord.

Om ze te beantwoorden moet de agent een afzonderlijk geïdentificeerde entiteit zijn die een saldo aanhoudt, een limiet respecteert die bij de transactie wordt afgedwongen, en op zichzelf kan worden gepauzeerd. Daar dienen OrcaID's limiet en kill-switch voor, en het is op dit moment een reservering in plaats van een product. De vraag is echter de moeite waard om nu te beantwoorden met de tools die je al hebt — omdat de kosten van het ontbreken van een antwoord meeschalen met de omvang van je vloot.

Bronvermelding: OrcaID's maandelijkse limiet beschreven als een harde stop, de kaart die op het moment dat de limiet wordt overschreden wordt geweigerd, de 'Active · one click to pause'-kill-switch, het gedrag van 'pause it and everything goes dead, nothing else moves', de verklaring 'tokens + dollars, one ledger' en de reserve-/fund-and-cap-/pull-framing zijn afkomstig van orcaid.ai, gecontroleerd op 2026-08-22, waar de wallet, kaart en het nummer zijn gelabeld als 'By verification' en de inbox 'At launch' — claims uit de preregistratie-ontwerpfase, geen uitgebrachte functionaliteiten. Grok Bots altijd-aan-gedrag en de multi-bot-specialistenstructuur zijn SpaceXAI's eigen claims uit de lancering van 11 augustus 2026. Hermes Agents ontwerp voor langdurige processen en de ingebouwde cron-scheduler zijn afkomstig uit Nous Researchs eigen materiaal. OpenClaws proactieve achtergrondwerking op een lokale machine komt uit de eigen beschrijving van het project. Er is geen integratie aangekondigd tussen OrcaID en enige hier genoemde agent.