At the 2026 Data + AI Summit, Databricks put Grok on stage next to OpenAI, Anthropic, and Google. But the supported-models documentation tells a more precise story than the keynote did, and the difference matters for how you wire it up.
Does Databricks host Grok? What the SKU roster reveals
No. Databricks does not host Grok as a native, Databricks-provisioned model. On June 18, 2026, at DAIS, Databricks positioned xAI's Grok as a selectable reasoning engine inside Agent Bricks alongside OpenAI, Anthropic Claude, Google Gemini, Alibaba Qwen, and the newly added Kimi . Yet Databricks' supported foundation-model page, last updated June 17, 2026, lists no grok-* or xAI entry among its hosted pay-per-token and provisioned-throughput families . The "on Databricks" framing is architectural shorthand for a governed external call, not a new Databricks-hosted SKU.
Quick Answer: Grok is not Databricks-hosted. As of the June 17, 2026 docs update, Databricks' foundation-model roster contains no xAI SKU. "Grok on Databricks" means inference runs on xAI infrastructure, reached through Databricks' External Models custom provider, with Databricks supplying only the governance and audit layer.
Per the official docs, Grok inference runs on xAI's infrastructure and is accessed through Databricks External Models' custom provider path. Databricks' external-model documentation states that Model Serving supports third-party models hosted outside Databricks, centralizes credentials behind a unified endpoint, and exposes a custom provider for OpenAI-API-compatible endpoints . xAI's API is OpenAI-client compatible via base_url="https://api.x.ai/v1" and model="grok-4.3" . That makes a bring-your-own-key, custom-provider integration the most accurate reading of the launch.
The arrangement divides responsibilities cleanly. Databricks owns the data governance and audit control plane; xAI owns inference, model weights, and serving. Databricks framed it this way at the summit: it holds the data and governance layer while Grok supplies the frontier reasoning model . Teams standardized on the Lakehouse can route production agents to Grok without exporting governed data to an external console, because the credential and the call both sit behind a Databricks endpoint.
The distinction is not pedantic. A native SKU would imply Databricks-negotiated pricing, private networking, and a published model card; a custom-provider external call implies you bring your own xAI key, your own rate limits, and your own retention terms. The keynote announced a partnership; the docs describe a configuration pattern. The sections that follow trace exactly how that pattern is assembled, starting with where the xAI credential actually lives.
BYOK mechanics: xAI credential held in Unity AI Gateway
The xAI credential lives in Databricks' credential store, not in notebook plaintext. That is the basis of the bring-your-own-key (BYOK) pattern. Databricks External Models exposes a custom provider path for any endpoint that speaks the OpenAI API, and xAI qualifies directly: its API is OpenAI-client compatible at base_url="https://api.x.ai/v1" with model="grok-4.3" . You register that endpoint once, attach your xAI key as a secret, and downstream code calls a Databricks-governed URL instead of api.x.ai directly.
Model Serving treats Grok as a third-party model hosted outside Databricks: it centralizes the credential behind a unified endpoint and routes requests through the platform's control plane while inference runs on xAI infrastructure (source: Databricks External Models docs). A minimal registration looks like this:
provider: "custom"
custom_provider_config:
base_url: "https://api.x.ai/v1"
api_key: "{{secrets/xai/api_key}}"
served_entities:
- external_model:
name: "grok-4.3"
task: "llm/v1/chat"The result is access scoping. The key no longer travels through code in plaintext; it sits behind the Unity AI Gateway, and service principals can be permissioned to specific endpoints rather than handed a blanket secret (source: Databricks AI Gateway docs). Application teams then reach Grok through the OpenAI client, the REST API, or the MLflow Deployments SDK (the same entry points used for any Gateway endpoint) without each consumer holding the raw xAI credential.
Auditability matters too. Where enabled, request and response payloads are logged to Unity Catalog Delta tables (inference tables), giving you queryable records of what each agent sent and received. The governance layer is real even though the inference is not local. You do not get a Databricks-hosted Grok weight; you get a governed, logged, rate-limitable proxy in front of xAI's API, which for most compliance reviews is the part that actually matters.
For deployments that require mutual TLS, xAI also publishes an mTLS endpoint at https://mtls.api.x.ai that retains the standard paths /v1/chat/completions and /v1/responses . Because the path structure is unchanged, a corporate gateway configured for the public endpoint can be pointed at the mTLS host with a base-URL swap, relevant when security policy mandates client-certificate authentication through the gateway.
Provider portability under one governance plane is the main business case, a point Edmunds frames directly. "Databricks gives us a secure, governed foundation to run multiple models and switch providers as our needs evolve. All while keeping costs in check," says Gregory Rokita, VP of Technology at Edmunds (source: Databricks, 2026-06). With BYOK, swapping Grok in or out becomes a configuration change, not a credential migration across every notebook.
Unity AI Gateway: audit logs, guardrails, and budget floors for Grok
Unity AI Gateway is Databricks' central governance layer for agents, LLM endpoints, MCP servers, and coding agents, and it is the control plane that makes a bring-your-own-key Grok deployment defensible. In Beta as of the 2026 Data + AI Summit, it adds permissions, usage tracking, inference tables, operational metrics, per-endpoint/user/group rate limits, guardrails, cost attribution, fallback routing, and traffic splitting across providers . For Grok, the result is that the xAI key lives behind a permissioned endpoint, service principals replace per-notebook secrets, and request/response payloads can be logged to Unity Catalog Delta tables where enabled .
Because traffic splitting and provider switching are configuration changes, swapping Grok for Claude or Gemini does not require rewriting agent code. Rokita at Edmunds makes the same point when he describes a governed foundation for running multiple models and keeping costs in check . That holds for Databricks-provided Gateway endpoints. Grok's actual path, an External Model custom endpoint that points at xAI infrastructure, is where the governance surface narrows, and that distinction is the one builders should verify before scoping a compliance story.
The boundary is explicit in the documentation: ai_query support applies only to Databricks-provided Gateway endpoints, not custom-created ones, and for those batch workloads only usage tracking applies: no guardrails, no inference tables, no rate limits, and no fallback routing . The table below shows which controls apply on Grok's BYOK route.
| Gateway control | Databricks-provided endpoint | Custom endpoint (Grok BYOK, batch) |
|---|---|---|
| Usage tracking / cost attribution | Yes | Yes |
ai_query SQL access | Yes | No |
| Rate limits (endpoint/user/group) | Yes | No |
| Guardrails | Yes | No |
| Inference tables (payload logging) | Yes | No |
| Fallback routing | Yes | No |
The gap matters for two reasons. First, budget floors and rate ceilings (the mechanisms that stop a runaway agent from exhausting a token allowance) are not enforced at the Gateway for custom-endpoint batch jobs, so cost and throughput guarding shifts back to xAI's own per-key limits or application-level logic. Second, the audit trail that compliance teams expect from inference tables is unavailable on that same path, leaving interactive serving endpoints as the route to payload-level logging.
On data handling, Databricks states that model partners do not retain data submitted through these features and that zero-data-retention endpoints are used . That is a vendor statement about the Databricks-managed surface, not an automatic guarantee for an External Model call that exits to api.x.ai. Teams should confirm the retention and data-residency scope of their specific Grok endpoint configuration with both vendors before treating it as a contractual control .
Grok 4.3 for Databricks: SKU facts and the November knowledge cutoff
Grok 4.3 is xAI's flagship reasoning model and the default target when you wire grok-latest into a Databricks External Model endpoint. It carries a 1,000,000-token context window, accepts text and image input, returns text output, and supports configurable reasoning, function calling, and structured outputs . The model identifier is grok-4.3, with aliases grok-4.3-latest and grok-latest; it is served from region us-east-1 with default rate limits of 1,800 requests per minute and 10,000,000 tokens per minute . Those defaults matter for capacity planning before traffic ever hits a Gateway rate cap.
Pricing is concrete and consistent across the xAI documentation. Per the xAI pricing page, last updated June 12, 2026, Grok 4.3 costs $1.25 per 1M input tokens, $0.20 per 1M cached input tokens, and $2.50 per 1M output tokens; the Grok 4.20 reasoning and non-reasoning variants share that same rate card . Cached input at $0.20 is the lever worth designing around: agentic loops that resend a stable system prompt or retrieved context can land most input tokens in the cached tier rather than the full $1.25.
Match the SKU to the workload before committing. Grok Build 0.1 (grok-build-0.1) is a coding-focused model with a smaller 256k-token context window and lower pricing, while Grok 4.20 Multi-Agent keeps the full 1M context at the flagship rate. The table below summarizes the trade-offs.
| Model | Context | Input / 1M | Cached / 1M | Output / 1M | Best fit |
|---|---|---|---|---|---|
grok-4.3 (grok-latest) | 1,000,000 | $1.25 | $0.20 | $2.50 | General reasoning, multimodal agents |
| Grok 4.20 (reasoning / non-reasoning) | 1,000,000 | $1.25 | $0.20 | $2.50 | Drop-in alternates at same price |
| Grok 4.20 Multi-Agent | 1,000,000 | $1.25 | $0.20 | $2.50 | Coordinated multi-agent runs |
grok-build-0.1 | 256,000 | $1.00 | $0.20 | $2.00 | Code generation, tighter budgets |
Source: xAI models and pricing documentation .
One constraint outranks every spec sheet line: Grok's knowledge ends at November 2024 per xAI's own documentation, and the model has no awareness of real-time events unless Web Search or X Search tools are explicitly enabled . For a Databricks team, that means a production agent answering questions about anything after late 2024 (a regulatory change, a market move, last week's incident) will hallucinate or refuse unless you turn on search tooling. Those server-side tools are billed separately from token spend, a cost the headline per-token price omits. The next section covers them.
Metered tool invocations: the budget line Grok omits from quoted price
Grok's server-side tools are billed per invocation, entirely separate from the per-token rates you model around. xAI charges $5 per 1,000 calls for Web Search, X Search, and Code Execution each, $10 per 1,000 calls for file-attachment search, and $2.50 per 1,000 calls for collections search. None of that appears in the headline $1.25 input / $2.50 output per 1M token figure. It stacks on top.
| Server-side tool | Price per 1,000 calls |
|---|---|
| Web Search | $5.00 |
| X Search | $5.00 |
| Code Execution | $5.00 |
| File-attachment search | $10.00 |
| Collections search | $2.50 |
Source: xAI pricing, 2026-06.
This matters for Databricks teams because costs compound. A single agentic turn rarely makes one tool call. An orchestration loop can fire a dozen or more Web/X Search and Code Execution invocations as it plans, retrieves, and verifies. At $5 per 1,000 calls, 50,000 search invocations across a busy production agent is $250 that no token estimate predicted. Cost modeling has to treat invocations as a second axis alongside token consumption, not a rounding error.
There is also an unconfirmed integration detail. xAI defines these tools server-side, but whether their definitions survive intact through Databricks' custom-provider wrapper is not documented. The external-models path requires an OpenAI-API-compatible endpoint , and if the wrapper does not explicitly forward xAI's tool parameters, Web Search and X Search may simply be unavailable, failing silently rather than erroring. Test tool-augmented calls end to end before assuming they work in production.
The fix is straightforward and should be in place before any search-augmented Grok agent ships. Set per-user and per-group budget caps in Unity AI Gateway so a runaway loop hits a ceiling instead of a surprise invoice . Then log invocation counts to Unity Catalog Delta tables and reconcile actual tool spend against your estimate. The same inference-table plumbing that audits requests gives you the per-tool call volume you need to true up the budget .
Before you commit to Grok in Databricks: clarity the partnership lacks
Treat the DAIS announcement as a distribution signal, not a finished commercial offer: the gaps that decide enterprise viability are still open. Databricks-tier Grok pricing was never disclosed at the June 18, 2026 launch , and there is still no native grok or xAI entry on the supported foundation-model page as of its June 17, 2026 update . That matters because Databricks-hosted SKU pricing historically differs from list API rates. Until xAI publishes Databricks-tier numbers, your cost model rests on the public xAI list price: $1.25 per 1M input and $2.50 per 1M output tokens for Grok 4.3 . Any negotiated rate, provisioned throughput, or volume discount requires a direct commercial conversation.
Two technical unknowns carry compliance weight:
- Private networking is unconfirmed. The bring-your-own-key, custom-provider pattern runs inference on xAI infrastructure , but VPC peering or PrivateLink between the Databricks VPC and xAI is not documented. If requests traverse the public internet, that may conflict with data-residency rules in regulated industries.
- The residency and retention split is unmapped. Databricks states model partners do not retain submitted data and that zero-data-retention endpoints are used , yet which vendor governs what for cross-border flows under GDPR, HIPAA, or SOC 2 is not publicly defined. xAI's separate mTLS endpoint at
https://mtls.api.x.aihints at corporate-gateway options but does not resolve the obligation boundary.
Grok now runs on Oracle Cloud Infrastructure (June 2025), Microsoft Azure AI Foundry (September 2025), Amazon Bedrock, and Databricks . But broad reach is not the same as first-class terms. SLAs, dedicated capacity, and model cards for Databricks specifically remain unconfirmed.
The takeaway: the BYOK plumbing works today, so prototype Grok behind Unity AI Gateway now. But do not sign off on production for regulated workloads until you have written answers on negotiated pricing, private networking, and the residency split. None of those three items has been put in writing yet.
Last updated: 2026-06-21. Reviewed against xAI and Databricks documentation current as of the June 2026 Data + AI Summit.
Frequently asked questions
What does 'Grok on Databricks' actually mean technically?
Grok is reached through Databricks' External Models feature using a bring-your-own-key custom-provider pattern, not as a Databricks-hosted or provisioned model. Inference still runs on xAI's servers. xAI's API is OpenAI-client compatible via base_url="https://api.x.ai/v1" with model="grok-4.3" . Databricks supplies the credential vault, governance controls, and a unified endpoint through Unity AI Gateway, while xAI handles the compute .
Is grok-4.3 listed in Databricks' supported foundation models catalog?
No. As of the Databricks documentation updated June 17, 2026, the supported foundation-model list (covering hosted pay-per-token and provisioned families such as OpenAI GPT, Google Gemini, Anthropic Claude, Qwen, GPT OSS, Gemma, and Llama) contains no grok-* or xAI entry . The most accurate reading is that the integration runs through the External Models custom-provider path, not a Databricks-managed databricks-grok-* SKU .
What governance controls does Unity AI Gateway provide for Grok requests?
Unity AI Gateway (in Beta) gives Grok requests a credential vault that removes xAI keys from notebooks, request/response logging to Unity Catalog Delta tables, per-user and per-group rate limits, guardrails, and cost attribution . The material caveat: full governance applies only to Databricks-provided Gateway endpoints. Custom-created endpoints (Grok's path) receive usage tracking only in the current Beta, without rate limits, guardrails, inference tables, or fallbacks .
What is Grok 4.3's knowledge cutoff and why does it matter in Agent Bricks?
Grok's knowledge cutoff is November 2024 per xAI's own documentation, and the model has no awareness of events after that date unless Web Search or X Search server-side tools are explicitly enabled . That matters for any Agent Bricks workflow built on real-time data, because those tools are billed separately at $5 per 1,000 calls each on top of token pricing, a cost that compounds in agentic loops beyond base spend .
How do you switch from Grok to another model in Databricks Agent Bricks?
Under Unity AI Gateway, provider switching is a configuration change rather than a code rewrite, and Agent Bricks supports OpenAI, Anthropic Claude, Gemini, Qwen, Kimi, and Grok under one governance plane . Audit the differences before switching in production: providers vary in pricing, context window, knowledge cutoff, and tool support. Grok 4.3 carries a 1,000,000-token context window at $1.25 per 1M input and $2.50 per 1M output tokens, terms that will not match every alternative .
