Grok Bot-configuratie: Geen Studio, Geen Model

Er circuleert deze week een Chinese post met de titel 我的 Gro​k Bot 工作室配置 — “mijn Gro​k Bot-studioconfiguratie” — en juist de bewoording verraadt het. Wie Gro​k Bot echt heeft geconfigureerd, weet dat er geen studio is: geen drag-and-dropbouwer, geen canvas met knooppunten, geen dropdown waarin je het model kiest. Gro​k Bot is het always-on agentproduct van SpaceXAI, gelanceerd op 11 augustus 2026, en het hele configuratieoppervlak bestaat uit tekst — een beschrijvingsveld, een gesprek, en alles wat je het kunt aanpraten om te onthouden. Dat is geen beperking die je omzeilt door andere tools te gebruiken. Het verandert wat een configuratie überhaupt is, en het verklaart waarom twee mensen die ogenschijnlijk dezelfde setup draaien, totaal verschillende resultaten krijgen.

De timing maakt dit nu de moeite waard om op te schrijven. Op 7 oktober zei Elon Musk in een post op X dat Grok Bot niet langer beperkt zou blijven tot SpaceXAI's eigen modellen en zou putten uit "het beste backend-model voor elke gegeven taak", waarbij hij Claude Opus 5.5, Midjourney en Suno noemde — een uitspraak die als uitspraak door meerdere media werd bevestigd en nog steeds geen tariefkaart, geen changelog-vermelding en geen externe meting bevat. Twee dagen later, op 9 oktober, begonnen per-Bot e-mailadressen eindigend op @mail.grokbot.com uitgerold te worden. Dus het product onder uw configuratie beweegt, en het ding dat bepaalt of die beweging u helpt, is hetzelfde als altijd: hoe goed de Bot zelf gespecificeerd is.

Wat het overhandigde signaal eigenlijk is

De post is een gebruiker die zijn eigen setup laat zien, en de nuttige lezing is structureel in plaats van letterlijk: het patroon is dat een werkende Grok Bot-configuratie een geschreven functiebeschrijving plus een klein aantal opgeslagen procedures is, niet een instellingenpaneel dat je één keer bezoekt. De eigen documentatie van SpaceXAI is hier ongewoon direct over. “Setup is een bericht, geen workflowbouwer,” zegt een pagina. Een skill wordt gedefinieerd als “een herbruikbare set instructies voor hoe je een taak uitvoert,” en een routine als het ding dat “één Bot vertelt wanneer een workflow moet worden uitgevoerd — volgens een schema of, waar ondersteund, na een gebeurtenis.” De aanbevolen volgorde die de documentatie geeft, is de hele methode in één regel: “Begin met een eenmalige taak. Maak die betrouwbaar, sla de methode op als een skill, en automatiseer het pas daarna.”

Als je hebt gezocht naar een builder-UI omdat elk ander agentproduct er een heeft uitgebracht, dan is die regel het antwoord. Het configuratie-artefact hier is proza dat contact met een echte taak overleeft — en de documentatie vertelt je precies wat een goed exemplaar bevat: wanneer je de vaardigheid moet gebruiken, vereiste inputs en toegang, de volgorde van het werk, hoe je resultaten valideert, wat je moet retourneren, en wat goedkeuring vereist.

De modelkiezer bestaat niet, en dat is juist het interessante eraan.

Vraag waar je voor een bepaalde Bot kiest tussen Grok 4.7 en Claude Opus 5.5 en de documentatie antwoordt botweg: “Cursor beheert de modelselectie, dus er is geen modelkiezer.” Er is geen modelinstelling per Bot, geen per routine en geen per skill. De Bot-instellingenpagina omvat Naam, Label, Beschrijving, Avatar en een voorkeur voor meldingen — dat is het volledige oppervlak per Bot — waarbij de tijdzone op accountniveau staat omdat routines die nodig hebben voor planningen.

De routering die Musk op 7 oktober beschreef, is dus geen knop die je draait. Volgens de documentatie die we kunnen lezen, is het een beslissing aan de platformzijde, onzichtbaar voor jou, behalve in de vorm van uitvoerkwaliteit en wat de gebruiksmeter daarna ook aangeeft. Voor iedereen die een configuratie bovenop Gro​k Bot bouwt, is dat de meest ingrijpende beperking, en het loont om het ronduit te zeggen: jij beheert het werk, niet de engine. Als die ruil acceptabel is, is het product coherent. Als jouw workflow met opzet een specifiek model nodig heeft — voor kosten, voor licentie, voor reproduceerbaarheid — dan is Gro​k Bot de verkeerde laag voor die eis, en de configuratie zal die nooit tot uitdrukking brengen.

De cijfers die een setup daadwerkelijk beperken

De meeste configuratietips zijn vaag omdat de meeste agentdocumentatie dat ook is. Deze zijn niet vaag, en elk ervan heeft een ontwerpconsequentie.

• Routines per Bot — 50. Een Bot kan “maximaal 50 routines” bezitten, en de app bewaart “de 20 meest recente uitvoeringsrecords voor elke routine”, dus je audittrail is bewust beperkt.

• Minimaal schema-interval — vijf minuten. “Routineschema’s moeten minstens vijf minuten uit elkaar liggen,” wat frequente pollinglussen uitsluit en je in plaats daarvan subtiel richting eventtriggers duwt.

• Lesgeven neemt tien minuten op. “Lesgeven legt gedurende maximaal tien minuten zichtbare computerinteractie vast. Het neemt geen microfoonaudio op.” Lange procedures moeten in segmenten worden opgesplitst.

• Geheimen per Team Bot — 25, waarden gemaskeerd en onleesbaar gemaakt in de uitvoer, en de documentatie waarschuwt dat de Bot ‘elk geheim in de conversatie van elke teamgenoot kan gebruiken’, dus een geheim is toegang die aan het hele team wordt verleend.

• Één computer per account, niet per Bot. "Elke Bot op je account gebruikt dezelfde computer," die "is toegewezen aan je gebruikersaccount, niet aan een individuele Bot," bestanden staan in een gedeelde /workspace, en "bestanden zijn zichtbaar voor elke Bot." De schermen die elke Bot ziet, zijn "afzonderlijke werkvlakken, niet afzonderlijke beveiligingsgrenzen."

Dat laatste is de beperking die mensen pas als laatste ontdekken. Het betekent dat een configuratie een accountbreed object is: een permissie die je aan één Bot toekent, is een permissie die de hele vloot heeft, en een persistent bestand dat door je onderzoeks-Bot is geschreven, is leesbaar voor je outreach-Bot.

Configureer de grens voordat u de taak configureert.

De automatiseringsrichtlijnen in de documentatie zelf vormen een korte lijst met dingen die de moeite waard zijn om in de eerste tien minuten van elke nieuwe configuratie te doen. Laat schrijfacties pas na goedkeuring plaatsvinden: “Vereis goedkeuring voor verzenden, aankopen, verwijderen, publiceren of wijzigen van productiesystemen.” Definieer beperkte eventmatching en vermijd “brede listeners zoals 'elk nieuw bericht,'” want ze veroorzaken ruis, verbruiken tegoed en reageren op irrelevante invoer. Gebruik de knop Testrun in de wetenschap dat “een testrun echt werk uitvoert. Hij kan websites bezoeken, bestanden wijzigen en verbonden tools aanroepen.” Leg een no-data-beleid en een stale-data-beleid vast vóór de eerste onbeheerde ochtend, en maak herhaalpogingen idempotent zodat een herhaling niet dubbel verzendt.

Behandel vervolgens verwijdering, want het is de enige bewerking die niet ongedaan kan worden gemaakt. “Het verwijderen van een routine is onmiddellijk en kan niet ongedaan worden gemaakt,” en het verwijderen van een Bot “verwijdert het actieve profiel, gesprek en routines”, terwijl computerbestanden en aanmeldingen niet per Bot geïsoleerd zijn en kunnen blijven bestaan. Verbergen is het omkeerbare alternatief. Er is ook een licentiegerelateerde complicatie die je liever weet dan ontdekt: de Bots-documentatie zegt dat backend-retentie de toepasselijke Cursor-voorwaarden volgt, een zin die je moet lezen voordat je een gedeelde werkruimte vult met iets dat gereguleerd is.

Wat draagt, wat niet

Dupliceren is de goedkoopste manier om dezelfde rol in een andere scope te laten draaien, en de documentatie is nauwkeurig over de scheidslijn. Een duplicaat krijgt “het profiel, de instellingen, de vaardigheden, de routines en de avatar,” en het maakt expliciet “geen kopie van gespreksgeschiedenis, aangeleerd geheugen of chatbijlagen.” Delen gaat verder: je bouwt een sjabloon en kiest voor openbare toegang of toegang alleen voor je team, en ontvangers bekijken een voorbeeld en voegen een kopie toe — “ze ontvangen je machine, inloggegevens of geschiedenis niet.” Verwijder API-sleutels, interne URL's en klantgegevens voordat je deelt, want het sjabloon bevat de configuratie, en de configuratie is waar mensen inloggegevens verstoppen.

Geheugen verdient hetzelfde wantrouwen. De documentatie beschrijft het als gemak, niet als waarheid: blijf feiten in het bronsysteem wijzigen, laat de Bot voor belangrijke beslissingen actuele gegevens opnieuw openen of citeren, en leg veiligheidslimieten vast in de beschrijving in plaats van erop te vertrouwen dat het geheugen ze vasthoudt. Team Bots voegen een tweede laag toe — teamgeheugen dat in ieders gesprek wordt gelezen, en privénotities die één persoon volgen — en een keihard facturatiegegeven: gebruik “komt ten laste van de eigen Gro​k Bot-limiet van die teamgenoot, niet die van de eigenaar.”

Waar een router past zonder zich voor te doen als de agent

Grok Bot is een abonnementsproduct; het is niet iets dat je via een endpoint van een derde partij kunt routeren, en geen enkele eerlijke configuratiehandleiding zou iets anders moeten suggereren. De vraag die het probleem van modelschaarste oproept, is een andere: als je de engine bewust wilt kiezen, koop je API-toegang, en dat is een aparte laag los van de Bot.

Die laag is wat wij verkopen. OrcaRouter is één OpenAI-compatibel endpoint voor meer dan 200 modellen, zonder markup op de lijstprijs van de provider, dus een prijsverlaging van een leverancier is hier dezelfde dag live; Grok 4.7 draait erop tegen het eigen gepubliceerde tarief van SpaceXAI van $2,00 per miljoen inputtokens en $6,00 per miljoen outputtokens onder 200K prompttokens, met een verdubbeling boven die drempel. De onderdelen die van belang zijn voor een configuratie zoals die in de post, zijn de onderdelen die voorkomen dat een onbewezen stap een productie-incident wordt: automatische failover tussen providers wanneer er één degradeert, een routing-DSL die meerdere modellen in één aanroep samenbrengt, en modelfusie voor panels die samen antwoorden. En de praktische zet voor de vraag “kan deze Bot het werk überhaupt aan” is de saaie — schrijf de skill, voer die één keer handmatig uit tegen het model dat je van plan was te vertrouwen, en automatiseer die pas daarna. Failover is wat het uitproberen van een stap tegen een model waaraan je je nog niet hebt vastgelegd, overleefbaar maakt in plaats van een gok.

Als je deze week je setup schrijft

Schrijf de rollen als operationele tekst, niet als functietitels. Het advies hierover in de documentatie is beter dan de meeste: een Bot moet een duidelijk doel, gereedschapsset, stijl, goedkeuringsgrens of schema hebben, en moet beginnen bij "de kleinste nuttige bezetting" waarbij één Bot een end-to-end resultaat bezit voordat specialisten worden toegevoegd. Doe de volgorde dan in de orde die de documentatie voorschrijft — één echte taak, betrouwbaar gemaakt; de methode opgeslagen als een skill; pas daarna een routine, met de Bot, het schema, de tijdzone, de invoerbron, het verwachte resultaat, de goedkeuringsgrens en het gedrag bij een ontbrekende bron allemaal opgeschreven. Test het terwijl je meekijkt. Stel de tijdzone in vóór het eerste schema, want routines gebruiken die. En let op het kleine vangnet dat bestaat: Gro​k Bot kan vragen of routines moeten blijven draaien na een lange afwezigheid en ze pauzeren als je niet antwoordt.

De configuratie in dat bericht is geen studio, en het woord doet geen kwaad — het is slechts een naam voor het ding dat een beoefenaar bouwt wanneer de enige echte besturingselementen een beschrijving, een vaardighedenbibliotheek en een planning zijn. Het deel dat de volgende productwijziging niet zal overleven, is alles wat ervan uitging dat jij het model koos. De verklaring van Musk van 7 oktober is nog steeds slechts een verklaring, en de documentatie zegt nog steeds dat er geen picker is; als er ooit een picker wordt uitgebracht, zullen de opstellingen die de moeite waard zijn, precies die zijn die al die tijd specifiek voor de taak waren.