Grok Bot-konfiguration: Ingen Studio, ingen modellväljare

Det cirkulerar ett kinesiskspråkigt inlägg den här veckan med titeln 我的 Gro​k Bot 工作室配置 – ”min Gro​k Bot-studios konfiguration” – och formuleringen är avslöjandet. Alla som har konfigurerat Gro​k Bot på riktigt vet att det inte finns någon studio: ingen dra-och-släpp-byggare, ingen canvas med noder, ingen rullgardinsmeny där man väljer modellen. Gro​k Bot är SpaceXAI:s ständigt aktiva agentprodukt, lanserad den 11 augusti 2026, och hela dess konfigurationsyta är text – ett beskrivningsfält, en konversation och vad du än kan övertala den att komma ihåg. Det är inte en begränsning man kringgår genom att byta verktyg. Det förändrar vad en konfiguration ens är, och det förklarar varför två personer som kör vad som låter som samma upplägg får vitt skilda resultat.

Tajmingen gör att detta är värt att skriva ner nu. Den 7 oktober sade Elon Musk i ett inlägg på X att Grok Bot skulle sluta begränsas till SpaceXAI:s egna modeller och i stället använda “den bästa backend-modellen för varje given uppgift”, och nämnde Claude Opus 5.5, Midjourney och Suno — ett uttalande som bekräftats som ett uttalande av flera medier och fortfarande inte har någon prislista, ingen changelog-post och ingen oberoende mätning. Det var två dagar senare, den 9 oktober, som e-postadresser per Bot som slutar på @mail.grokbot.com började rullas ut. Så produkten under din konfiguration rör sig, och det som avgör om den rörelsen hjälper dig är samma sak som den alltid har varit: hur väl själva Boten är specificerad.

Vad den överlämnade signalen egentligen är

Inlägget är från en användare som visar upp sin egen uppsättning, och det användbara sättet att läsa det är strukturellt snarare än bokstavligt: mönstret är att en fungerande Gro​k Bot-konfiguration är en skriftlig arbetsbeskrivning plus ett litet antal sparade procedurer, inte en inställningspanel som man besöker en gång. SpaceXAI:s egen dokumentation är ovanligt rakt på sak om detta. ”Konfiguration är ett meddelande, inte en arbetsflödesbyggare”, säger en sida. En färdighet definieras som ”en återanvändbar uppsättning instruktioner för hur man utför en uppgift”, och en rutin som det som ”talar om för en Bot när ett arbetsflöde ska köras – enligt ett schema eller, där det stöds, efter en händelse.” Den rekommenderade ordningen i dokumentationen är hela metoden i en rad: ”Börja med en engångsuppgift. Gör den tillförlitlig, spara metoden som en färdighet och automatisera den först därefter.”

Om du har letat efter ett builder-UI eftersom varje annan agentprodukt har släppt ett, är den raden svaret. Konfigurationsartefakten här är prosa som överlever kontakten med en verklig uppgift – och dokumentationen berättar exakt vad en bra sådan innehåller: när färdigheten ska användas, nödvändiga indata och åtkomst, arbetsordningen, hur resultat ska valideras, vad som ska returneras och vad som kräver godkännande.

Modellväljaren finns inte, och det är det intressanta.

Fråga var du väljer mellan Grok 4.7 och Claude Opus 5.5 för en viss Bot, och dokumentationen svarar rakt ut: ”Cursor hanterar modellvalet, så det finns ingen modellväljare.” Det finns ingen modellinställning per Bot, ingen per rutin och ingen per färdighet. Sidan för Bot-inställningar omfattar Namn, Etikett, Beskrivning, Avatar och en aviseringsinställning — det är hela ytan per Bot — med tidszonen på kontonivå eftersom rutiner behöver den för scheman.

Så routningen som Musk beskrev den 7 oktober är inte en ratt man vrider. Så vitt den dokumentation vi kan läsa visar, är det ett beslut på plattformsnivå, osynligt för dig utom som utdatakvalitet och som vad användningsmätaren än säger efteråt. För alla som bygger en konfiguration ovanpå Gro​k Bot är det den enskilt mest konsekvensrika begränsningen, och det är värt att säga rakt ut: du styr arbetet, inte motorn. Om den avvägningen är acceptabel är produkten sammanhängande. Om ditt arbetsflöde medvetet behöver en specifik modell – för kostnad, för licens, för reproducerbarhet – är Gro​k Bot fel lager för det kravet, och konfigurationen kommer aldrig att uttrycka det.

Siffrorna som faktiskt begränsar en setup

De flesta konfigurationsråd är vaga eftersom de flesta agentdokument är det. Dessa är inte vaga, och vart och ett har en designkonsekvens.

• Rutiner per Bot — 50. En Bot kan äga ”upp till 50 rutiner”, och appen behåller ”de 20 senaste körningsposterna för varje rutin”, så din granskningslogg är avsiktligt grund.

• Minsta schemaintervall — fem minuter. ”Rutinscheman måste ligga minst fem minuter isär”, vilket utesluter täta pollningsloopar och i tysthet knuffar dig mot händelseutlösare i stället.

• Teaching spelar in i tio minuter. “Teaching spelar in synlig datorinteraktion i upp till tio minuter. Den spelar inte in mikrofonljud.” Långa procedurer måste delas upp i segment.

• Hemligheter per Team Bot — 25, värden maskeras och redigeras bort i utdata, och dokumentationen varnar för att Bot ”kan använda varje hemlighet i vilken teamkamrats konversation som helst”, så en hemlighet är åtkomst som beviljas hela teamet.

• En dator per konto, inte per bot. "Varje bot på ditt konto använder samma dator", den "tilldelas ditt användarkonto, inte en enskild bot", filer ligger i en delad /workspace, och "filer är synliga för varje bot". Skärmarna som varje bot ser är "separata arbetsytor, inte separata säkerhetsgränser".

Den sista är den begränsning som folk upptäcker sist. Det innebär att en konfiguration är ett objekt för hela kontot: en behörighet som du beviljar en Bot är en behörighet som flottan har, och en beständig fil som skrivs av din forsknings-Bot kan läsas av din uppsökande Bot.

Konfigurera gränsen innan du konfigurerar jobbet

Dokumentationens egen automatiseringsvägledning är en kort lista över saker som är värda att göra under de första tio minuterna av en ny uppsättning. Håll skrivoperationer bakom godkännande: ”Kräv godkännande för att skicka, köpa, radera, publicera eller ändra produktionssystem.” Definiera snäv händelsematchning och undvik ”breda lyssnare som 'varje nytt meddelande'”, eftersom de genererar brus, förbrukar kvot och agerar på irrelevant indata. Använd knappen Testkörning med vetskapen om att ”en testkörning utför verkligt arbete. Den kan navigera på webbplatser, ändra filer och anropa anslutna verktyg.” Skriv ned en policy för utebliven data och en policy för inaktuella data före den första obemannade morgonen, och gör omförsök idempotenta så att en ny körning inte skickar dubbelt.

Hantera sedan borttagning, eftersom det är den enda åtgärden som inte går att ångra. ”Att ta bort en rutin sker omedelbart och går inte att ångra”, och att ta bort en Bot ”tar bort den aktiva profilen, konversationen och rutinerna” medan datorfiler och inloggningar inte är isolerade per Bot och kan finnas kvar. Att dölja är det reversibla alternativet. Det finns också en licensmässig hake som är värd att känna till snarare än att upptäcka: Bots-dokumentationen säger att backend-lagring följer tillämpliga Cursor-villkor, vilket är en mening att läsa innan du fyller en delad arbetsyta med något reglerat.

Vad som håller, vad som inte håller

Duplicering är det billigaste sättet att köra samma roll i en annan omfattning, och dokumentationen är precis om sömmen. Ett duplikat får ”profilen, inställningarna, färdigheterna, rutinerna och avataren”, och det uttryckligen ”kopierar inte konversationshistorik, inlärt minne eller chattbilagor.” Delning går längre: du bygger en mall och väljer offentlig åtkomst eller åtkomst endast för teamet, och mottagare förhandsgranskar den och lägger till en kopia — ”de får inte din maskin, dina inloggningar eller din historik.” Ta bort API-nycklar, interna URL:er och kunddata innan du delar, eftersom mallen innehåller konfigurationen, och konfigurationen är där människor gömmer autentiseringsuppgifter.

Minne förtjänar samma misstro. Dokumentationen beskriver det som en bekvämlighet, inte som sanning: fortsätt ändra fakta i källsystemet, få Boten att öppna igen eller hänvisa till aktuella data för beslut som spelar roll, och koda in säkerhetsgränser i beskrivningen i stället för att lita på att minnet håller dem. Team Bots lägger till ett andra lager – teamminne som läses av allas konversationer, och privata anteckningar som följer en person – och ett hårt faktum om fakturering: användning ”belastar den teamkamratens egen Grok Bot-kvot, inte ägarens.”

Var en router passar in utan att låtsas vara agenten

Gro​k Bot är en prenumerationsprodukt; det är inte något man kan dirigera via en tredjepartsendpoint, och ingen ärlig konfigurationsguide bör antyda något annat. Frågan som problemet med modellbrist väcker är en annan: om du medvetet vill välja motorn köper du API-åtkomst, och det är ett separat lager från Bot.

Det lagret är vad vi säljer. OrcaRouter är en enda OpenAI-kompatibel endpoint för över 200 modeller, utan påslag på leverantörens listpris, så en leverantörsprissänkning är live här samma dag; Grok 4.7 finns på den, till SpaceXAI:s egen publicerade taxa på 2,00 USD per miljon indatatoken och 6,00 USD per miljon utdatatoken för under 200K prompttokens, vilket fördubblas över den gränsen. Delarna som spelar roll för en konfiguration som den i inlägget är de som hindrar ett obeprövat steg från att bli en produktionsincident: automatisk failover mellan leverantörer när en av dem försämras, ett routing-DSL som sammanfogar flera modeller till ett anrop, och modellfusion för paneler som svarar tillsammans. Och det praktiska draget för frågan ”kan den här boten göra jobbet överhuvudtaget” är det tråkiga – skriv färdigheten, kör den en gång för hand mot modellen du tänkte lita på, och automatisera den först då. Failover är det som gör att det är överlevbart, snarare än en satsning, att prova ett steg mot en modell du inte har förbundit dig till.

Om du skriver din setup den här veckan

Skriv rollerna som operativ text, inte som jobbtitlar. Dokumentationens råd om detta är bättre än de flesta: en Bot bör ha ett tydligt syfte, tydlig verktygsuppsättning, tydlig stil, tydlig godkännandegräns eller tydligt schema, och bör utgå från ”den minsta användbara uppsättningen” med en Bot som ansvarar för ett resultat från början till slut innan specialister läggs till. Gör sedan sekvensen i den ordning dokumentationen föreskriver – en verklig uppgift, gjord tillförlitlig; metoden sparad som en färdighet; först därefter en rutin, där Bot, schema, tidszon, indatakälla, förväntat resultat, godkännandegräns och beteende vid saknad källa är nedskrivna. Testa den medan du övervakar. Ställ in tidszonen före det första schemat, eftersom rutiner använder den. Och notera det lilla skyddsnät som finns: Gro​k Bot kan fråga om rutiner ska fortsätta köras efter en lång frånvaro och pausa dem om du inte svarar.

Konfigurationen i det inlägget är inte en studio, och ordet gör inget — det är bara ett namn för det en utövare bygger när de enda riktiga kontrollerna är en beskrivning, ett färdighetsbibliotek och ett schema. Den del som inte kommer att överleva nästa produktförändring är allt som förutsatte att du valde modellen. Musks uttalande den 7 oktober är fortfarande bara ett uttalande, och dokumentationen säger fortfarande att det inte finns någon väljare; om det någonsin kommer en väljare kommer de uppsättningar som är värda att ha att vara de som varit specifika om jobbet hela tiden.