xAI Release Notes

Grok Bot is now available for enterprises.

Grok and Cursor Enterprise customers have free usage for the next two weeks, and can invite their whole organization, including people without an existing seat.

Grok Bot is your team of helpful AI teammates. You delegate real tasks to them and they carry the job through end to end, working autonomously around the clock inside the same tools you use.

Enterprises need the ability to govern Bots at scale and today's release adds access, network, and audit controls that make that possible.

A Bot for every job

A Bot is a worker you create inside Grok Bot for a specific job. Each Bot runs on its own computer in the cloud and can use every app and website the same way you do. You message a Bot like a coworker, and it comes back when the work is done or it needs a decision from you.

You'll usually manage several Bots for different jobs and each runs independently. To teach a Bot a workflow, have it follow along once. It saves the routine, takes your corrections, and runs it on its own from then on. When you've built a Bot that works well, you can hand it to the person next to you as a template. Bots can also message each other and share context, so you're not having to pass context between them.

How customers use Grok Bot

Thousands of organizations have adopted Grok Bot since launch, including customers like Legora, Supermicro, and ServiceTitan. These teams use Grok Bot every day, and the heaviest use is outside engineering. Here are a few popular examples of the [millions] of bots created in the past few weeks:

• Sales. Bots can watch webinars and podcasts by people at target accounts, then leave LinkedIn and email drafts for morning review. During a call, a Bot updates the deck from live notes so next steps are on the slide even before the meeting is over.

• Recruiting. A Bot prospects overnight and builds a morning shortlist with outreach queued for review. It texts candidates good luck before they walk in, and after interviews it submits scorecards from that day's Gong calls.

• Marketing. After a webinar, a Bot pulls the Zoom Q&A and sends Slack messages to the AEs whose customers showed up. The messages include notes on the questions the customer asked as well as draft replies.

• Finance. A specialized procurement Bot monitors vendor spend, usage, and renewals, then finds places to cut costs or negotiate better terms. It has surfaced tens of thousands of dollars in savings across SaaS, recurring purchases, and vendor services.

• Engineering. Bots monitor PRs for bugs, security findings, failing builds, and merge conflicts, then keep every task moving until it's ready for review. Overnight audits improve code quality, performance, and security, giving engineers more time for the hardest problems.

Secure by default

Each user's work in Grok Bot runs in its own secure and isolated environment, separate from every other user. A Bot has no access by default and reaches only the accounts you sign it into.

Free for Enterprise for the next 2 weeks

Grok and Cursor Enterprise customers get Grok Bot free for the next two weeks and can invite their whole organization, including people without an existing seat.

Activate Grok Bot today in your admin dashboard.

To learn more, contact sales.

How we designed Grok Bot for agents that persist beyond a single session

How we designed Grok Bot for agents that persist beyond a single session — from a chat history to a Bot roster, presence, a computer of the Bot’s own, and work that starts without a prompt.

When we started designing Grok Bot, one of the central questions was how the interface should shape the relationship between user and agent. Most AI interfaces are organized around a chat session the user operates. Each session begins with setup, unfolds as the user looks on, and ends when the conversation stops.

We wanted to design for an agent that persists beyond any one session and can carry responsibility on its own. That meant reconsidering some of the basic objects and signals of the interface, including what belongs in the sidebar, how an agent shows progress, and when its work should become visible.

AI products have accumulated a large vocabulary in a short time. Chats, sessions, models, context windows, memories, system prompts, projects, skills, connectors, agents, tools, sandboxes, permissions, and automations all describe real parts of these systems.

But exposing each one as a separate product concept asks users to understand more than they need to. We started by asking which concepts a person actually needs in order to work with an agent.

We kept coming back to five:

• Bots are persistent agents with their own identity, memory, runtime, and tools.
• Chats are the conversational interface for working with a Bot.
• Prompts give a Bot context or instructions. They can be used once, saved as Skills, or triggered automatically as Routines.
• Tools let Bots access information and take action through software, APIs, connectors, the shell, or computer use.
• Artifacts are the documents, designs, code, data, and other durable outputs that Bots create or modify.

Everything else could remain beneath the interface until the user had a reason to care about it. The next question was which of these five objects should organize the product.

Chats are disposable. We start a conversation to solve a problem. It gets pushed down the sidebar. A week later, we start another one. You rarely go back beyond the most recent five.

That behavior is perfectly reasonable when the unit of interaction is a question. It becomes strange when the thing on the other side of the interaction is supposed to know you, remember previous work, and take responsibility over time.

So the main objects in Grok Bot are Bots, not conversations. A Bot has a name. It has an avatar and a title. It remembers its conversations with you. It has its own computer and tools. When you come back tomorrow, you are coming back to the same Bot.

Once a Bot was something you maintain over time rather than a session you start, the way Bots appear in the product had to answer three questions at once:

• Who is this?
• What are they doing?
• How much do I need to know?

A roster only works if it can be scanned quickly. As the roster grows, we did not want people to have to read every name each time they opened the product. They should be able to recognize a Bot from its avatar almost peripherally.

At the same time, we wanted to keep the avatars consistent enough to read as one system. We studied character systems across illustration, animation, games, and interface design, exploring everything from initials and emojis to pixel art, watercolor, claymorphism, Noritake-style line art, silhouettes, and identicons.

Most approaches solved one side of the problem better than the other. Watercolor and clay gave individual Bots plenty of character but carried too much detail at sidebar scale. Simpler systems sat more naturally in the interface, but often left the Bots looking interchangeable.

The system we landed on keeps the basic construction consistent, using simple shapes and expressive eyes, then introduces distinction through controlled variations and accessories. Each Bot remains recognizable at a glance without appearing to come from a different visual world.

Once the avatar became the Bot’s identity, it was also the natural place to show state. A Bot may be idle, thinking, working, waiting, blocked, or done. We could have represented each state with a separate indicator, but that would have added another layer of UI for the user to interpret.

Instead, we explored how much of the lifecycle the avatar itself could carry.

At rest, the Bot is calm and slightly curious. When work arrives, it acknowledges the task. As work begins, it kicks into gear. Its motion changes again when it is waiting or needs help, then settles once the work is done. The avatar now shows what the Bot is doing as well as which Bot it is.

A related design question was how much of the Bot’s execution to show. One approach would have been the standard “three animated dots” but that would have been too little information, making it hard for users to tell whether the Bot was working or stuck.

We also tried showing a short written description of the Bot’s current action, but once people could see one step, they wanted to see the rest. User research showed us that they were asking for that detail mainly for reassurance that the Bot was still working and on the right track.

In the final design, the avatar’s motion provides the first bit of reassurance by showing that the Bot is active. If someone wants to check what it is doing, they can hover to see its current action.

Each Bot has its own computer, which it can use to browse the web, work with files, and run software. This created another interface problem. How visible should that computer be and when should the user be able to control it?

We explored four arrangements:

• Floating window: kept the computer easy to reach but covered the conversation.
• Side by side: made the work continuously visible and encouraged users to watch it.
• Modal: made checking in easy but treated the Bot’s workspace as a temporary interruption.
• Full screen: gave the computer plenty of room but displaced the conversation entirely.

The more prominent we made the computer, the more the product encouraged users to supervise it. We decided it should remain the Bot’s workspace, with the interface providing different levels of access as the user needed them.

The final design has three levels, which allow the user to enter the Bot’s workspace without being drawn into operating it:

• Status: the title-bar icon turns purple while the computer is active.
• Preview: opening it reveals a pinned side panel where the user can follow the work without leaving the conversation.
• Takeover: when the Bot needs help, the user can open the computer full screen, take control, and then hand it back.

We also designed wallpapers that shift throughout the day, becoming lighter in the morning and darker at night. The detail gives the Bot’s computer its own sense of time and makes it feel separate from the user’s desktop.

It is closer to working with a coworker than operating a remote machine. You can tell that they are working, glance at their screen when you need context, and sit down when something requires your help.

Early versions of Grok Bot responded to almost every request with prose. It described a five-day forecast instead of showing one and narrated a set of tasks instead of laying them out as a board. The user then had to restructure the answer. This led us to treat the form of a response as part of the answer.

To support this, we built inline cards and widgets into Grok Bot. A Bot can answer in prose when prose fits the information and use structured UI when it does not.

The same principle applies to actions. When a Bot creates a Routine, changes a setting, or messages another Bot, the event can appear directly in the transcript. The user can open it when there is more to inspect.

The result is a heterogeneous transcript in which conversation, system events, interactive objects, and visualizations share one timeline.

Once people create several Bots, the product also has to organize how those Bots work together. We needed to decide which context should belong to each role, how Bots should share context when their work overlaps, and how to coordinate them without turning the user into a dispatcher.

We saw one answer emerge as people created more Bots. Some made a Chief of Staff Bot responsible for coordinating several specialists. They could give direction to one Bot instead of checking each one and routing every task themselves.

Giving Bots distinct roles also forced us to decide what each role should know. A legal Bot may need the history of an ongoing dispute, while a finance Bot may need years of financial records. Combining those histories into one large memory would make it harder to give each Bot the information relevant to its work.

Capabilities and context therefore follow different boundaries in Grok Bot. Tools and Skills live at the account level because many Bots may need to browse the web, work with documents, or send email. Memory and Routines belong to the Bot because they reflect what that particular role knows and does over time. Put another way, capabilities can be shared broadly while context remains with the role that needs it.

Some work crosses those role boundaries. Group chats provide shared context for a project or team while allowing each Bot to retain its specialized memory. A designer, engineer, PM, and data scientist can work in the same conversation, hand work to one another, and share what the project requires.

We considered adding dashboards, assignment boards, and explicit handoff controls to manage these groups. Each one gave the user more coordination work. Instead, coordinating Bots handle routine routing and bring the user in when a decision requires judgment.

Most agent sessions begin when a user sends a prompt. That leaves even a persistent Bot waiting for someone to activate it. Routines let users give a Bot a standing responsibility that runs on a schedule or in response to an event, such as watching an industry or preparing a briefing every morning. The user defines the work once, and the Routine activates the Bot when it needs to happen.

We initially treated Routines as secondary configuration. As they became more important to autonomous work, we moved them into the Bot’s main interface. The transcript shows what ran and gives the user a place to review the result or handle an exception.

This also changes the role of conversation. A prompt can start a session, but so can a schedule, an event, or another Bot. Over time, more work may begin without the user being present at all.

By the end of the project, much of the design work involved taking things away. We removed window and panel controls, computer-view options, and agent metadata. We also set practical limits of roughly 50 Bots per account and six per group chat. Each decision came back to the same question: Did this help someone delegate, or did it give them one more thing to manage?

The line between operating an AI and delegating to a coworker keeps moving as models improve. Grok Bot reflects where we think it sits today. Designing Grok Bot from its earliest explorations through launch has been about finding that line and helping the interface change with it. As agents take on more responsibility, the interface should ask less of the person.

Grok Bot now has a tighter integration with X.

Connect your X account in Grok Bot and we'll create a developer account for you if you don't have one. Paid Grok Bot users get free X API credits to start.

To get started, open Grok Bot and sign in with the X connector.

Then ask a Bot to search posts, read your timeline, check mentions, or pull together what's happening on X. This is the first version of this integration, and we're excited to keep making it easier for Grok Bot to do real work on X.

Download Grok Bot here.

Length-truncated responses continue automatically instead of failing the turn

Hooks can ask you to confirm a tool call instead of only allowing or denying

Pasted images show a live pixel preview in the prompt box on iTerm2

Transient inference failures (stalls, drops, 5xx) retry automatically instead of ending the turn

Windows users can correctly open ~/.grok and worktree sessions

Session data is saved more reliably after prompts and on power loss

Compaction failures show the actual error instead of a generic message

Truncation error messages show the right guidance instead of an unhelpful retry suggestion

Truncated tool calls execute when arguments are complete instead of failing the turn

Images larger than 2000px no longer brick sessions on many-image requests

Wrapped hyperlinks in the pager stay fully clickable on Windows Terminal

Recurring scheduled tasks include a reminder to stop the monitor when work finishes

Scheduled task IDs use full UUIDs to avoid collisions when tasks are created in the same millisecond

Subagent spawning is faster when connections drop during bursts

Session startup with MCP servers is much faster when auth is already configured

MCP server startup no longer stalls behind a fixed batch size

CLI downloads are compressed, making fresh installs and updates substantially faster

Auto quality

The quality parameter on grok-imagine-image-2.0 now accepts auto, and the default when quality is omitted has moved from medium to auto. Auto currently uses low for image generation and medium for image editing. Images are billed at the quality they are served at. Pass low or medium explicitly to pin a specific quality. See Image Generation.

Five reference images

Image editing now accepts up to 5 source images per request (was 3). See Multi-Image Editing.

New aspect ratios

Image generation and editing accept 21:9 (cinematic widescreen) and 5:2 (wide banners). See Image Generation.

Copying wrapped table cells no longer inserts unwanted spaces at line breaks

MCP server connections that fail transiently retry instead of staying unavailable

Waiting on subagents after an interjection no longer blocks on unrelated background work

Prompt blocks show friendly hook descriptions instead of internal IDs

Truncation error message no longer suggests asking for a shorter answer

Context estimates for conversations with reasoning are more accurate

Token usage after rewinding or switching modes matches the server-reported count instead of overestimating

Context bar updates immediately when auto-compaction begins

File system monitoring for .NET projects no longer creates excessive watchers on Linux

Auto recap no longer appears while a background task or monitor wake turn is streaming

Worktree creation is faster by skipping stale reflog copies

Headless sessions are browsable in the resume picker without mixing into default history

Default permission mode for new interactive sessions is configurable

Turn duration appears in session history after resume

Turn footers (Worked for, cancelled, failed) appear after /resume

mkdir and touch no longer prompt in auto mode or safe-command lists

Headless sessions can auto-allow permission prompts via a startup hint

Permission prompts for common command chains and subcommands are more reliable

Blocked prompts no longer appear in conversation history or scrollback after restart

Mouse input at the right margin no longer types characters into the prompt on certain terminals

Pasting text ending in a newline no longer accidentally submits the prompt on some terminals

Auto mode shows a permission card when the classifier blocks an action on interactive sessions

Image previews no longer leave ghost artifacts when using the Kitty protocol on Warp

Expanded Execute tool output no longer snaps closed during live progress

/voice falls back to parec/arecord on older PipeWire installs

Background command waits finish as soon as the process exits

Grok 4.6 is now available via Microsoft Foundry.

Today, we’re excited to announce that Grok 4.6 is now available on Microsoft Foundry. Grok 4.6 is our latest flagship model, built for long-running agents and ambitious interactive and visual work. It offers a 500k context window and configurable reasoning efforts (low, medium, high, xhigh). For more on the model, read the Grok 4.6 announcement.

Build with Grok 4.6 on Microsoft Foundry

Foundry gives organizations a single place to evaluate Grok 4.6 against other frontier models, run workload-specific tests, deploy managed endpoints, and operate with enterprise security and governance controls. If you are building coding agents, engineering copilots, research assistants, or enterprise automation, you can get started in the Foundry model catalog. See Microsoft’s announcement, Grok 4.6 comes to Microsoft Foundry Models, and our Microsoft Foundry integration guide for deployment details.

/feedback

supports attaching images such as screenshots

The / slash menu

is ordered by recency and groups skills below commands

/workflow

accepts --agent-budget N or an agent_budget JSON field to set child-agent limits

/workflow

accepts --effort LEVEL or an effort JSON field to set child reasoning effort

MCP servers receive a grok-cli User-Agent header so providers can attribute traffic

Dashboard lets you start new agents in Auto mode via Shift+Tab

Workflows appear alongside skills in the model prompt so the agent can launch them by name

/edit-prompt

opens an external editor from the full TUI, not only minimal mode

Up arrow on an empty prompt selects queued follow-ups first instead of opening history

/plugin

works as an alias for /plugins in the TUI

Plugin-provided agents appear in the /agents modal and can be toggled

/minimal and /fullscreen

switch instantly inside the running session without restarting or losing the current turn

The configurable status line row appears at the bottom of minimal mode as well as fullscreen

grok clone fetches only the selected branch tip by default, with --full-history for legacy full clones

grok clone can reuse a matching local checkout as a linked worktree instead of always fetching from the network

Subagent tasks are more resilient to temporary rate limits and retry instead of failing immediately

Narrow allow rules for Bash commands correctly permit file writes without extra prompts

Rules containing markdown headings render correctly in the prompt

/new and /clear

preserve the last-chosen reasoning effort instead of resetting to the model default

Prompt dropdowns (slash, history, file search) have consistent left alignment with the composer

History shows every command, slash command, and memory note in the order you typed them

Collapsed tool-call rows no longer show a vertical accent line beside the status diamond

Hint text above the prompt lines up with the text you type

Pressing Esc while peeking at a conversation from the dashboard closes open modals instead of leaving the view

/copy

preserves markdown formatting such as headings and code fences

Sending a new message while a shell command is running moves the command to the background instead of cancelling it

grok mcp add correctly treats bare http(s):// URLs as HTTP servers instead of stdio commands

Plan mode no longer incorrectly blocks subagent spawns as file edits outside plan.md

MCP servers that share a URL but have different names stay as separate entries instead of being collapsed

Subagents and workflow-spawned agents no longer receive the workflow tool that only top-level sessions can use

Memory results are presented as historical context to verify against live sources before use

Minimal mode no longer truncates subagent wake-turn replies after the first token

Concurrent subagents no longer trigger rate-limit errors during bursts

MCP server connections no longer delay session startup when many servers are configured

Grok 4.6 is now available via Google Enterprise Agent Platform.

Today, we’re excited to announce that Grok 4.6 is now available on Google Enterprise Agent Platform. Grok 4.6 is our latest flagship model, built for long-running agents and ambitious interactive and visual work. It offers a 500k context window and configurable reasoning efforts (low, medium, high, xhigh). Now, Google Enterprise Agent Platform users can use the model through Model Garden.

Capabilities & Pricing

Grok 4.6 is available for:

• Input: $2 per 1 million tokens
• Cached input: $0.50 per 1 million tokens
• Output: $6 per 1 million tokens

For more on the model, read the Grok 4.6 announcement.

Build with Grok 4.6 on Google Enterprise Agent Platform

Grok 4.6 is now available to developers in Model Garden. To get started, visit the Grok 4.6 model card. We're excited to see what you build!

Grok Bot is now available for SuperGrok Plus, Cursor Pro+, and all Cursor Teams plans.

We launched Grok Bot in beta on August 11 to give people highly capable AI teammates who could get real jobs done and be incredibly easy to work with.

Since then, people who tried Grok Bot were surprised at how easy it was to start, and how much sharper Bots felt than other AI tools, taking jobs further without being walked through every step.

Today, we're expanding access to Grok Bot. Grok Bot is now included with all SuperGrok Plus, Cursor Pro+, and Cursor Teams plans.

With this expansion, Grok Bot is now included with:

• SuperGrok Plus
• SuperGrok Heavy
• Cursor Pro+
• Cursor Ultra
• Cursor Teams Plans (Standard and Premium)

Give Bots real work

Grok Bot is designed for people who want agents to handle anything from a project to an entire function. They're digital teammates you can message, run in parallel, and trust to finish work in the tools you already use. Bots work across apps and inboxes, keep going when you step away, and only pull you in for judgment calls.

With Grok Bot, you get:

• A text-thread UX. Message a Bot the way you would message someone on your team, from mobile or desktop, so you can pick up the same thread on either — with nothing to set up first.
• Many Bots at once. Stand up a researcher, writer, and chief of staff. Put them in a group chat so they pass work between themselves, and you're not in the middle.
• A highly capable digital colleague. They have their own computer in the cloud. It's always on, with browser and terminal access. They sign into your apps and work happens in the actual tool instead of a chat draft.
• Easy-to-set-up routines. Ask a Bot to follow along the next time you do the job, so it can run on its own after that.

Jobs Bots are doing today

• Sales prospector. Researches and enriches accounts, drafts personalized outreach. Leaves every send for you to approve in your inbox or navigator.
• Website builder. Builds the site, purchases the domain, and deploys the final version. Helps configure plugins, delivers a live URL, and adds redirect rules.
• Digital declutterer. Audits email, Drive, and paid subscriptions around the clock. Only discards or unsubscribes if you say so.
• Customer support. Reads support mail and connects into your payments provider. Handles all the routine refunds within your policy.
• Game artist. Visits the art pipeline and makes the custom assets according to your creative direction. Comes back with what the game needs.
• Office manager. Intakes work orders, plans capacity, and books jobs across Gmail, Slack, ServiceTitan, Quo, and the client portal. Handles the browser work in those portals so a shop owner does not have to live in six tools.
• Inbox manager. Works through the inbox and clears tons of email. Leaves you only the messages that need a person.
• Meeting stand-in. Joins meetings when you can't make it and lets the room know you're there. Takes detailed notes and sends a summary so you stay informed.
• Refunds manager. Finds the claim, files it, and follows it through. Comes back with the refund or discount it recovered.

Try Grok Bot today

Download Grok Bot so you can create your first teammate and give it a job you already do. You'll see what useful AI looks like when the work comes back finished.

Enterprise users can join a waitlist as we ramp access for larger team and company rollouts.

Read the original announcement and see what Bots can do to learn more.

MCP servers can ask for form input or URL consent through the same popup used for questions

Ctrl+S stashes the current prompt draft so you can send something else and restore it later

/workflow autocompletes saved workflow names and shows only valid runs for pause/resume/stop/save

Downloading a folder that contains only one file produces a zip that still extracts as a folder

Failed tool calls for tools the model invented clearly state the tool does not exist in UI

Status line refresh timer uses consistent naming and no longer shows errors on deliberately hidden rows

Workflow agent rows display current context usage instead of cumulative token counts

Follow-up messages send immediately while waiting on a subagent or task, including after using /btw

Subagents and workflow-spawned agents no longer see the workflow tool, which can only be launched from a top-level session

Opening many subagents at once no longer freezes the interface while loading their history

Concurrent subagents start much faster and no longer freeze the parent session

Startup connect budget can be raised with the GROK_CONNECT_UI_TIMEOUT_SECS environment variable

Permission prompts show Always allow and Never allow options by default

Scheduled background loops can be deleted directly from the tray

Status line command scripts can run on a timer via refresh_interval in config.toml

Permission prompts offer a Never allow choice for MCP tools and web-fetch domains that persists per project

Workflows tab in the extensions modal (Ctrl+L or /plugins) lists installed workflows with name, source, and description

New /workflows command opens the Workflows catalog tab; /workflow runs shows live workflow runs

Bare /workflow (or /workflow runs) lists active and recent workflow runs with status and progress

Workflows row in the Ctrl+P command palette opens the Workflows catalog tab

MCP server connections in non-interactive sessions no longer incorrectly require authentication for tokenless servers

Startup timeouts caused by concurrent auth refreshes across multiple sessions are fixed

Tool call loops are interrupted earlier to avoid wasting time on repeated identical actions

Subagents no longer receive the ask-user-question tool

Bare email addresses become clickable mailto links in the pager