Grok Bot Configuration: No Studio, No Model Picker

There is a Chinese-language post circulating this week titled 我的 Gro​k Bot 工作室配置 — “my Gro​k Bot studio configuration” — and the phrasing is the tell. Anyone who has configured Gro​k Bot for real knows there is no studio: no drag-and-drop builder, no canvas of nodes, no dropdown where you pick the model. Gro​k Bot is SpaceXAI's always-on agent product, launched on 11 August 2026, and its entire configuration surface is text — a description field, a conversation, and whatever you can talk it into remembering. That is not a limitation you work around by swapping tools. It changes what a configuration even is, and it explains why two people running what sounds like the same setup get wildly different results.

The timing makes this worth writing down now. On 7 October, Elon Musk said in a post on X that Gro​k Bot would stop being limited to SpaceXAI's own models and would reach for “the best back end model for any given task,” naming Claude Opus 5.5, Midjourney and Suno — a statement, corroborated as a statement by several outlets and still carrying no rate card, no changelog entry and no outside measurement. Two days later, on 9 October, per-Bot email addresses ending in @mail.grokbot.com began rolling out. So the product underneath your configuration is moving, and the thing that decides whether that movement helps you is the same thing it has always been: how well the Bot itself is specified.

What the handed signal actually is

The post is a user showing off their own setup, and the useful reading is structural rather than literal: the pattern is that a working Gro​k Bot configuration is a written job description plus a small number of saved procedures, not a settings panel you visit once. SpaceXAI's own documentation is unusually blunt about this. “Setup is a message, not a workflow builder,” one page says. A skill is defined as “a reusable set of instructions for how to do a task,” and a routine as the thing that “tells one Bot when to run a workflow — on a schedule or, where supported, after an event.” The recommended order the docs give is the whole method in one line: “Start with a one-time task. Make it reliable, save the method as a skill, and only then automate it.”

If you have been looking for a builder UI because every other agent product shipped one, that line is the answer. The configuration artifact here is prose that survives contact with a real task — and the docs tell you exactly what a good one contains: when to use the skill, required inputs and access, the sequence of work, how to validate results, what to return, and what requires approval.

The model picker does not exist, and that is the interesting part

Ask where you choose between Grok 4.7 and Claude Opus 5.5 for a given Bot and the documentation answers flatly: “Cursor manages model selection, so there is no model picker.” There is no per-Bot model setting, no per-routine one, and no per-skill one. The Bot settings page covers Name, Label, Description, Avatar and a Notifications preference — that is the entire per-Bot surface — with time zone sitting at the account level because routines need it for schedules.

So the routing Musk described on 7 October is not a dial you turn. As of the documentation we can read, it is a platform-side decision, invisible to you except as output quality and as whatever the usage meter says afterwards. For anyone building a configuration on top of Gro​k Bot, that is the single most consequential constraint, and it is worth stating plainly: you control the work, not the engine. If that trade is acceptable, the product is coherent. If your workflow needs a specific model on purpose — for cost, for licence, for reproducibility — Gro​k Bot is the wrong layer for that requirement, and the configuration will never express it.

The numbers that actually constrain a setup

Most configuration advice is vague because most agent docs are. These are not vague, and each one has a design consequence.

• Routines per Bot — 50. A Bot can own “up to 50 routines,” and the app keeps “the 20 most recent run records for each routine,” so your audit trail is shallow by design.

• Minimum schedule interval — five minutes. “Routine schedules must be at least five minutes apart,” which rules out tight polling loops and quietly pushes you toward event triggers instead.

• Teaching records for ten minutes. “Teaching records visible computer interaction for up to ten minutes. It does not record microphone audio.” Long procedures have to be broken into segments.

• Secrets per Team Bot — 25, values masked and redacted in output, and the docs warn the Bot “can use every secret in any teammate's conversation,” so a secret is access granted to the whole team.

• One computer per account, not per Bot. “Every Bot on your account uses the same computer,” it “is assigned to your user account, not an individual Bot,” files sit in a shared /workspace, and “files are visible to every Bot.” The screens each Bot sees are “separate work surfaces, not separate security boundaries.”

That last one is the constraint people discover last. It means a configuration is a whole-account object: a permission you grant one Bot is a permission the fleet has, and a durable file written by your research Bot is readable by your outreach Bot.

Configure the boundary before you configure the job

The docs' own automation guidance is a short list of things worth doing in the first ten minutes of any new setup. Keep writes behind approval: “Require approval for sending, purchasing, deleting, publishing, or changing production systems.” Define narrow event matching and avoid “broad listeners such as 'every new message,'” because they generate noise, burn usage and act on irrelevant input. Use the Test run button knowing that “a test run performs real work. It can navigate websites, change files, and call connected tools.” Write down a no-data policy and a stale-data policy before the first unattended morning, and make retries idempotent so a re-run does not double-send.

Then handle deletion, because it is the one operation with no undo. “Deleting a routine is immediate and has no undo,” and deleting a Bot “removes the active profile, conversation, and routines” while computer files and sign-ins are not isolated per Bot and may persist. Hiding is the reversible alternative. There is also a licensing wrinkle worth knowing rather than discovering: the Bots documentation says backend retention follows the applicable Cursor terms, which is a sentence to read before you fill a shared workspace with anything regulated.

What carries, what does not

Duplication is the cheapest way to run the same role at a different scope, and the docs are precise about the seam. A duplicate gains “the profile, settings, skills, routines, and avatar,” and it explicitly “does not copy conversation history, learned memory, or chat attachments.” Sharing goes further: you build a template and choose public or team-only access, and recipients preview it and add a copy — “they don't receive your machine, logins, or history.” Strip API keys, internal URLs and customer data before you share, because the template carries the configuration, and the configuration is where people hide credentials.

Memory deserves the same suspicion. The docs describe it as convenience, not truth: keep changing facts in the source system, make the Bot reopen or cite current data for decisions that matter, and encode safety limits in the description rather than trusting memory to hold them. Team Bots add a second layer — team memory read by everyone's conversation, and private notes that follow one person — and a hard billing fact: usage “counts against that teammate's own Gro​k Bot allowance, not the owner's.”

Where a router fits without pretending to be the agent

Gro​k Bot is a subscription product; it is not something you can route through a third-party endpoint, and no honest configuration guide should suggest otherwise. The question the model-scarcity problem raises is a different one: if you want to choose the engine on purpose, you are buying API access, and that is a separate layer from the Bot.

That layer is what we sell. OrcaRouter is one Open​AI-compatible endpoint across 200-plus models with no markup on provider list price, so a vendor price cut is live here the same day; Grok 4.7 sits on it at SpaceXAI's own published rate of $2.00 per million input tokens and $6.00 per million output tokens under 200K of prompt tokens, doubling above that threshold. The pieces that matter for a configuration like the one in the post are the ones that keep an unproven step from becoming a production incident: automatic failover across providers when one degrades, a routing DSL that composes several models into one call, and model fusion for panels that answer together. And the practical move for the “can this Bot do the job at all” question is the boring one — write the skill, run it once by hand against the model you were going to trust, and only then automate it. Failover is what makes trying a step against a model you have not committed to survivable rather than a bet.

If you are writing your setup this week

Write the roles as operational text, not as job titles. The docs' advice on this is better than most: a Bot should have a distinct purpose, toolset, style, approval boundary or schedule, and should start from “the smallest useful roster” with one Bot owning an end-to-end outcome before specialists are added. Then do the sequence in the order the documentation prescribes — one real task, made reliable; the method saved as a skill; only then a routine, with the Bot, schedule, time zone, input source, expected result, approval boundary and missing-source behaviour all written down. Test it while you are watching. Set the time zone before the first schedule, because routines use it. And note the small safety net that exists: Gro​k Bot may ask whether to keep routines running after a long absence and pause them if you do not answer.

The configuration in that post is not a studio, and the word is doing no harm — it is just a name for the thing a practitioner builds when the only real controls are a description, a skill library and a schedule. The part that will not survive the next product change is anything that assumed you picked the model. Musk's 7 October statement is still only a statement, and the docs still say there is no picker; if a picker ever ships, the setups worth having will be the ones that were specific about the job all along.