Grok Bot routines and skills: the reported 10-minute recording limit, explained

The demonstration feature is Grok Bot’s genuinely novel idea: perform a task once while the Bot watches, then ask it to keep the path. Two numbers govern whether that works for your workflow, and xAI publishes neither of them. A recording is reportedly capped at ten minutes, and reportedly only the twenty most recent run records are retained. Both limits were reported by Daily Dose of Data Science and remain unconfirmed by xAI. This page covers how routines and skills differ, how to structure a demonstration around the cap, how schedules behave, and where Grok Automations does a job routines cannot.

By the Continuum team. We build a workbench that runs Claude Code, Codex, and their peers, so the model rates quoted here are the ones our own cost analytics ship with.

The short version

A Grok Bot routine is a saved multi-step path a Bot learned by watching you perform it once, re-runnable on demand or on a schedule. A skill is the same demonstration saved as a reusable procedure a Bot can invoke inside a larger job rather than as a standalone scheduled run. Both are created the same way, by asking the Bot at the end of the walkthrough to save what it just saw. The reported ceilings are a 10-minute cap on a single teach-by-demonstration recording, 50 routines per Bot, 50 Bots and group chats per account, and only the 20 most recent run records retained, which on a busy account means visible history disappears within days. All were reported by Daily Dose of Data Science and remain unconfirmed by xAI. Grok Automations is a separate xAI product with schedules and email triggers that prompts the chatbot rather than operating apps, and it has no API either.

What you need to know
  • Routine and skill come from the same act. You demonstrate once, then ask the Bot to "save it as a skill or create a routine". The difference is how it gets invoked afterwards.
  • Ten minutes is the reported demonstration cap. It was reported by Daily Dose of Data Science and remains unconfirmed by xAI. Design the walkthrough as several short recordings chained by the Bot, not one long one.
  • Only 20 run records are reportedly retained. The figure was reported by Daily Dose of Data Science and remains unconfirmed by xAI. An hourly routine retains 20 hours around the clock; just over two business days at nine runs/day. Do not treat run records as an audit trail.
  • Schedules are per routine, and the docs say a routine can "re-run it on a schedule or on demand". Nothing published describes retries, overlap handling, or failure alerts.
  • Email triggers are Automations, not Bot. Grok Automations fires on sender, recipient, and subject filters, but it prompts the chatbot and cannot operate your apps.
  • No dry run anywhere. Testing a routine performs the real work, every time. Rehearsing a send is sending.

What a routine is, in xAI’s own words

The documentation is short on this and worth quoting exactly. From docs.x.ai/grok-bot/overview, retrieved 22 August 2026: "Ask a Bot to follow along once through a multi-step or multi-system path. It persists that path as a routine and can re-run it on a schedule or on demand." And separately: "It can learn workflows from live demonstration."

That is the whole documented surface. Three things follow from it and are worth stating because most write-ups skip them.

  • The unit of learning is a path, not a prompt. You are not describing a procedure in words and hoping the model interprets it the same way next time. You are performing it, and the Bot keeps the sequence of screens, clicks, and steps it observed.
  • It is explicitly multi-system. The interesting case is not a routine inside one app, it is a routine that pulls from one place, transforms, and puts the result somewhere else.
  • Re-running is either scheduled or on demand. There is no third trigger type documented for Bots. Event triggers, webhooks, and anything fired from your own systems do not exist here, because Grok Bot has no public API.

Skill or routine? The distinction xAI does not spell out

The launch material uses a single phrase for both outcomes: at the end of the walkthrough you "ask the Bot to save it as a skill or create a routine". Two names, one gesture, and no documentation page explaining when to pick which. Here is the working distinction, drawn from how each behaves rather than from a spec, and flagged as such.

How the two saved forms differ in practice. Behavioural description, not a documented specification; xAI has published no page defining either term.
SkillRoutine
What it isA reusable procedure a Bot can call inside a larger jobA standalone job the Bot performs end to end
How it firesThe Bot chooses to use it while working on something elseYou run it, or a schedule runs it
Good for"How we format an invoice", "how we log into the vendor portal""Every Monday, produce the pipeline report"
SchedulingNot the point. It is a building blockYes. This is the scheduled unit
Reported ceilingNone published50 per Bot, reported by Daily Dose of Data Science; unconfirmed by xAI

The practical rule: save the reusable fragment as a skill, and the whole scheduled job as a routine. A routine that logs into a portal, exports a CSV, reformats it, and emails it is better built as one routine calling three skills, because when the portal redesigns its login page you re-teach one skill rather than re-recording the entire job. That decomposition also works around the recording cap, which is the next section.

The 10-minute recording cap, and how to design around it

A single teach-by-demonstration recording is capped at ten minutes. That figure comes from a Daily Dose of Data Science teardown, which as of 22 August 2026 is the only place any of Grok Bot’s numeric ceilings appear in writing. xAI has not published it, has not confirmed it, and could change it without telling anyone. Treat it as reported.

Ten minutes is more generous than it sounds for a click-through and much less generous than it sounds for a real workflow, because real workflows contain waiting. An export that takes four minutes to generate has eaten 40% of your budget doing nothing.

01

Split at every wait

Anywhere the procedure waits on a system (a report generating, a batch job, an email arriving), end the recording. Teach the before as one skill and the after as another. The Bot can hold the gap; a recording cannot.

02

Record the unusual, describe the obvious

Demonstration is expensive per second and text is free. Spend the recording on the parts a model could not guess: which of four identically named menu items, which filter preset, the exact column order the downstream system expects. Say the rest in a sentence.

03

Do a clean run, not a real one

Fumbling counts. Every wrong click, every back-navigation, and every "actually, not that one" is inside the ten minutes and inside what the Bot learned. Walk the path yourself once with the recording off, then record the clean version.

04

Name the exit condition out loud

A demonstration shows the Bot what to do, not when it is finished. State the stopping condition explicitly at the end ("the routine is done when the row appears in the tracker"), because a routine with no exit condition is the failure mode that burns tokens on a meter with no cap.

05

Chain, then test the chain

Once the fragments exist as skills, ask the Bot to run them in order as one routine. Test that composition before scheduling it. There is no dry run, so the test does the real work, which means testing against real data on a real account.

Schedules: what is documented and what is not

The documented surface for scheduling is one clause: a routine "can re-run it on a schedule or on demand". Everything a person running production automation needs to know beyond that is unpublished. It is worth listing the gaps precisely, because they are the questions that decide whether you can rely on a routine.

Scheduling questions, and the state of the published answer as of 22 August 2026.
QuestionDocumented answer
Can a routine run on a schedule?Yes. Stated in the overview docs
What schedule granularities exist?Not published for Bots. Automations documents once, daily, weekdays, weekly, monthly, yearly
What happens if a run overruns the next trigger?Not published
Is there a retry on failure?Not published
Am I alerted when a scheduled run fails?Not published
Do several Bots’ routines run in parallel?Implied yes. Each Bot has its own screen on the shared computer
Can a routine be triggered by an event or a webhook?No. Grok Bot has no public API and no webhook surface
How much history can I see?The 20 most recent run records, reported by Daily Dose of Data Science; unconfirmed by xAI

The parallelism row is the one piece of good news. Because each Bot gets its own screen on the shared machine, two Bots can drive two browsers at the same time. Several routines firing at 09:00 across different Bots is a supported shape, not a queue. What they share is the filesystem and the logins underneath, so two routines touching the same file or the same authenticated session are contending for the same resource with nothing arbitrating between them.

The 20-run ceiling: why your history vanishes

Of all the reported limits, this is the one that changes how you should use the product. Only the twenty most recent run records are reportedly retained. The figure was reported by Daily Dose of Data Science and remains unconfirmed by xAI. Do the arithmetic against a real schedule.

How long twenty retained run records lasts, by cadence. Retention figure reported by Daily Dose of Data Science; unconfirmed by xAI.
Routine cadenceRuns per dayHistory you can still see
Hourly, business hours~9Just over two days
Every 30 minutes, business hours~18Just over one day
Four times a day4Five days
Daily1Under three weeks
Weekly~0.14About five months

A daily routine keeps under three weeks of visible history. An hourly routine keeps 20 hours around the clock; just over two business days at nine runs/day. If a routine started producing subtly wrong output last Tuesday and you notice on Friday, the evidence may be gone. eesel’s review makes the related point that the docs describe an audit view as coming, twice, and that today there are only per-Bot chat transcripts rather than anything queryable across an account.

Routines vs Grok Automations: two different products

People searching for "grok automation" land on a different xAI product, and conflating the two produces a wrong plan. Grok Automations was announced on 16 July 2026 (it is the feature previously called Tasks, rebuilt) and lives at grok.com plus the mobile apps. It has two trigger types: schedules, and email triggers that fire on sender, recipient, and subject filters.

The email trigger is the thing Bot routines cannot do, and it is worth knowing about. But the payload is different in kind: an Automation prompts the chatbot and gets you an answer. It does not have a computer, it does not log into your apps, and it cannot drive a browser.

Grok Bot routines against Grok Automations, on the axes that decide which one you need.
Grok Bot routineGrok Automations
Where it runsThe shared cloud computerxAI’s chatbot infrastructure
Can operate your apps?Yes. Connectors, MCP, and computer useNo. It answers, it does not act
Schedule triggersYes, granularity not publishedYes: once, daily, weekdays, weekly, monthly, yearly
Email triggersNoYes, on sender, recipient, subject
Taught by demonstrationYesNo. You write the prompt
AccessA Grok Bot eligible plan plus a Cursor accountBasic scheduling free; email triggers require SuperGrok
APINoneNone

The pattern that comes up repeatedly: people want "when an email arrives from this supplier, log into the portal and reconcile it". That is an email trigger on the Automations side and computer use on the Bot side, and no single xAI product spans both today. The workaround people use is a scheduled Bot routine that checks the inbox itself, which trades trigger latency for capability.

Six routines worth building, and three that are traps

Filtered by whether the shared-computer trust model and the missing history make them survivable.

  • Build: a morning digest that pulls from two or three sources with no clean API and writes one document. High value, no destructive action, and the output is its own log.
  • Build: a weekly export-and-reformat from a vendor portal. Classic computer-use work, low frequency so the run history survives, and easy to verify by eye.
  • Build: a stale-record sweep that reports what needs changing rather than changing it. Splitting detection from action is how you get the value without the no-dry-run risk.
  • Build: a status-page and uptime watch that pings you on change. Cheap, read-only, and genuinely better done by something that is always awake.
  • Build: a research routine that collects and summarises into a running document. The document becomes the history the 20-run ceiling will not keep.
  • Build: an onboarding-checklist walkthrough recorded as skills. Even if you never schedule it, the recorded procedure has value as documentation.
  • Trap: anything that sends external messages on a schedule. No dry run means every test is a real send, and an apology is more expensive than the automation saved.
  • Trap: anything financial that writes. Payments, invoices, refunds. There is no queryable organisation-wide audit view, no dry run, and reportedly only twenty run records to reconstruct from; the retention figure was reported by Daily Dose of Data Science and remains unconfirmed by xAI.
  • Trap: anything hourly you actually depend on. History covers 20 hours around the clock; just over two business days at nine runs/day, and no failure alerting is documented, so the first you hear about a broken routine may be when someone downstream complains.

Where scheduled agent work belongs instead

If the appeal of routines is scheduled agent work that continues without you, that property does not require a shared cloud machine holding your logins. It requires a host that stays awake and something to trigger on it.

Continuum takes the other approach. A machine you already own runs the agents, each Code session gets its own git worktree, spend is recorded per repository, and you approve a plan, read a diff, or interrupt a run from an iPhone or a browser while the host keeps working. The repository and credentials remain on your host; selected context is sent to the configured provider for inference. The history is on your disk rather than capped at the reported twenty records.

The honest trade is the one this whole cluster keeps returning to: Grok Bot needs no machine of yours to stay on, and it drives graphical software that has no API better than a terminal agent can. If those two properties are the binding constraint, use it, and keep the credentials you give it small. If they are not, running the agents yourself gets you scheduling, history, isolation, and model choice at once.

Questions people ask

How do I create a routine in Grok Bot?

Walk the Bot through the task once while it follows along, then ask it to save what it just saw. xAI’s own phrasing is to "ask the Bot to save it as a skill or create a routine". The documentation states the Bot "persists that path as a routine and can re-run it on a schedule or on demand". There is no separate routine editor documented.

What is the difference between a Grok Bot skill and a routine?

Both come from the same demonstration. A skill is a reusable procedure the Bot calls inside a larger job, and a routine is a standalone job that runs on demand or on a schedule. xAI has published no page defining either term, so that distinction is behavioural rather than specified. In practice, save reusable fragments as skills and the whole scheduled job as a routine.

How long can a Grok Bot demonstration be?

Ten minutes per recording, according to a Daily Dose of Data Science teardown, which as of 22 August 2026 is the only published source for any of Grok Bot’s numeric ceilings. xAI has never published or confirmed it. Design around it by splitting the workflow at every point where it waits on a system, and teaching each fragment as its own skill.

How many routines can a Grok Bot have?

Fifty per Bot, reported by Daily Dose of Data Science, alongside a limit of fifty Bots and group chats per account. Neither figure is confirmed by xAI. At fifty routines per Bot across fifty Bots the theoretical ceiling is large, but the practical ceiling arrives much sooner because only the twenty most recent run records are reportedly retained.

Can Grok Bot run a routine on a schedule?

Yes. The overview documentation says a routine can "re-run it on a schedule or on demand". What is not published: the available schedule granularities for Bots, what happens when a run overruns its next trigger, whether failures retry, and whether you are alerted when a scheduled run fails. Plan as if none of those exist.

Can Grok Bot be triggered by email?

Not directly. Email triggers belong to Grok Automations, a separate xAI product announced 16 July 2026, which fires on sender, recipient, and subject filters but prompts the chatbot rather than operating your apps. Grok Bot has no public API and no webhook surface, so the workaround is a scheduled Bot routine that checks the inbox itself.

How much routine history does Grok Bot keep?

The twenty most recent run records, reported by Daily Dose of Data Science and unconfirmed by xAI. That is 20 hours around the clock; just over two business days at nine runs/day, and under three weeks for a daily routine. eesel’s review notes the documentation describes a proper audit view as coming, twice, and that today there are only per-Bot chat transcripts. Have the routine write its own log somewhere you control.

Can I test a Grok Bot routine safely before running it?

No. There is no dry-run mode. eesel’s review puts it directly: "A test run performs real work, it can navigate websites, change files and call connected tools." If you rehearse an email send, you sent the email. Test against a throwaway account and real data you are willing to change, and keep destructive routines out of production until a dry run exists.

Is Grok Bot the same as Grok Tasks?

No. Tasks was renamed and rebuilt as Grok Automations on 16 July 2026, and pages quoting old Tasks limits such as "2 daily tasks free" are describing a product that no longer exists in that form. Automations schedules prompts to the chatbot. Grok Bot routines run on a cloud computer and can operate real software.

Sources

Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.

  1. Grok Bot overview, docs.x.ai the shared cloud computer, per-Bot screens, memory, routines, connectors and MCP, computer use, group chats
  2. Grok Bot get started, docs.x.ai eligible plans, Cursor sign-in, platform downloads, the Linux statement, Settings paths
  3. Daily Dose of Data Science the only published source for Grok Bot’s numeric ceilings; reported, never confirmed by xAI
  4. xAI: Grok Automations 16 July 2026, schedules and email triggers, the product formerly called Tasks
  5. eesel AI: Grok Bot review metering behaviour, compliance gaps, no dry run, audit view described as coming
  6. AY Automate: what xAI’s always-on agents actually do the only launch-week write-up with real product screenshots: credential handover, plugins panel, teach-a-task recording
  7. Composio: a guide to Grok Bot hands-on setup walkthrough and skills as reusable procedures
  8. xAI: Introducing Grok Bot launch date, beta status, positioning, enterprise waitlist
Try it

Scheduled agents.
Logs you keep.

Continuum runs agents on machines you already own, on your schedule, with the full transcript and per-repository spend on your own disk. Approve a plan or stop a run from your phone while the host keeps working.

free app · your subscriptions · local-first