This is part one of three. Part two covers the four ways to host a model on Databricks; part three walks through bringing your own provider key. Read them in order or skip to the one you need.
Start here: Genie Code, and what it can actually do
Before you pick a place to host a model, there's a chance you don't need one. Genie Code is the coding and data assistant already sitting in your workspace, and the thing that defines it is easy to mistake for a shortcoming:
You don't pick the model. You can't. No dropdown, no endpoint, no key. What you tune instead is everything around it — skills, connections, instructions, scheduled work. That turns out to be a lot more than most people realize.
Two things to know up front. It works like an agent by default — the old Chat/Agent toggle went away in June 2026, so there's only one mode now. It plans, looks things up, runs code, and fixes its own mistakes. And it's probably already turned on for you: the setting that gates it is enabled by default unless you're in a compliance-security-profile workspace. I checked three unrelated workspaces and got true on all of them:
databricks api get /api/2.0/settings/types/llm_proxy_partner_powered/names/default \
--profile <your-profile>
# → {"boolean_val": {"value": true}, "setting_name": "default"}
Regulated workspaces are the deliberate exception — off by default there. So if Genie Code looks oddly limited in one, check this setting before you blame the product.
▼ PLACE DIAGRAM HERE: model-path-post1.png
The decision-tree map with Genie Code + Genie Agents highlighted. Drag the PNG in, then delete this box.
It won't replace your IDE. It gets closer than you'd think
If you've spent fifteen years building up keybindings and plugins, you're not switching. Fair enough.
But that's not everybody. If you're an AI/ML or data engineer whose work lives where the data lives — notebooks, SQL, pipelines, dashboards, MLflow — Genie Code is a real option for most of your day. You're not giving up an editor you spent years tuning. You're getting an assistant that already sits next to your tables, already has your permissions, and needs no setup.
And this isn't shaping up as a fight over which tool wins. Databricks ships its own skills into whatever assistant you already use:
$ databricks aitools install --help
Install Databricks skills and plugins for detected coding agents.
Supported agents: Claude Code, Cursor, Codex CLI, OpenCode, GitHub Copilot, Antigravity
That's about 22 Databricks skills — Bundles, Jobs, Unity Catalog, Pipelines, Apps, MLflow, Iceberg, Lakebase — installed into the assistant you're already running. Going the other way, Genie Code reads your files: it finds AGENTS.md and CLAUDE.md on its own, walking up the folder tree, nothing to configure. Your conventions travel both directions, so using Genie Code isn't a bet against your editor.
Five things it does that most people don't know about
1. It can run on a schedule while you're asleep (Beta, July 2026). Least known, probably most useful. You schedule a prompt, and each run is a full Genie Code session that lands as a chat you can pick up later — summarize how the overnight jobs went, review your Jira tickets and start working them, re-run last week's investigation.
This feature is in Beta. Workspace admins can control access from the Previews page — see Manage Databricks previews.
Set one up by just asking for it — "every morning at 6 AM, summarize how my overnight jobs did" — or fill in the form. Three things to know before you lean on it:
- Auto-approve is forced on. Nobody's there to click Approve, so it approves its own actions, with a classifier blocking the risky ones. You can't turn that off for scheduled runs.
- It runs as you, with your Unity Catalog permissions.
- Each run starts a fresh chat instead of adding to one long thread.
2. You can teach it your own workflows. A skill is a folder with a
SKILL.md in it — a name, a description, your instructions, and scripts if you want them. Drop it in Workspace/.assistant/skills/ for everyone or /Users/{you}/.assistant/skills/ for yourself. Nothing to register — it gets picked up next session, or you can @mention it. They use the open Agent Skills format, so they move between tools.Keep this straight: skills load only when they're relevant, while instructions apply to everything (.assistant_instructions.md for you, .assistant_workspace_instructions.md for the workspace).
3. There are three places to call it from, and they don't see the same things. This isn't in the docs, and it changes how well the tool works for you:
| Surface | How to get there | What it sees |
|---|---|---|
| In-context | The Genie button on a notebook cell, at the top of the SQL query builder, or on a dashboard visual | Just that object |
| Side / docked pane | The Genie Code panel | The workspace around you |
| Full page | The command center — chat prominent, assets as tabs | Broadest; built for parallel work |
Match where you ask to how big the ask is. Fixing one cell? Use the button on that cell — you get a tighter, faster answer because it isn't reading your whole workspace to change one line. Working across notebooks and tables? Side pane. Starting something new or juggling a few things? Full page, which the docs call "the recommended experience for starting work from scratch or running multiple tasks in parallel."
The per-cell button is the one most people have never noticed.
4. It can reach things outside Databricks. Built-in connectors for Google Drive, SharePoint, GitHub, Glean, Atlassian, and Slack (Beta, admin turns them on), each with its own sign-in so tokens aren't shared. That's what turns "review my Jira tickets every morning" from a nice idea into a real scheduled task.
5. It builds whole things — pipelines, dashboards, fixes — not just snippets. Edits across several cells and files from one ask. Entire pipelines in the Lakeflow Pipelines Editor. Dashboards you'd actually ship, including Power BI and Tableau imports. MLflow debugging. Failed job diagnosis from the Jobs page via Diagnose Error. Undo that backs out a whole response at once. You can paste in a screenshot or a whiteboard photo.
When to move up
Genie Code is your assistant. It isn't your company's, and that's a design choice rather than a gap: there's no API to embed it in an app, it can see everything you can see rather than a reviewed subset, its context is your skills and instructions, and scheduled tasks can't be shared. Everything that makes it good for you is what makes it wrong to hand around.
| You need | Go to |
|---|---|
| Someone other than you using it | Genie Agents |
| An API you can embed in an app | Genie Agents |
| Row filters and column masks per person | Genie Agents |
| A bounded, reviewed set of tables | Genie Agents |
| To name the model, or bring your own | The four hosting options |
| Custom logic around the model | The four hosting options |
Genie Agents: the same thing, for everyone else
When someone else needs to ask the questions, build a Genie Agent. From the sidebar — Genie Agents → New — pick up to 30 tables or views and let Genie Code do the setup work: it will "automatically review your data and suggest context that helps Genie answer questions accurately, such as descriptions of your tables and example queries."
The difference that matters: a Genie Agent applies row filters and column masks per person asking. That's what makes it safe to hand to people who shouldn't see everything. You're still not picking a model — you're picking a warehouse and curating context.
Two things worth knowing before you build on one. Every question becomes real SQL you can audit in system.query.history, and you'll see several statements per question because the agent checks a draft query's shape before running it. And if you embed one in your own app, there are two APIs: the older conversation API gives quick single-pass answers, while /api/2.0/genie/agents/{id}/responses (Beta) runs the multi-step version that plans, queries, and iterates. The endpoint you call decides which you get — there's no setting for it.
One note on names, because search results will confuse you: a Genie space and a Genie Agent are the same thing, renamed in the UI in July 2026 while the API kept saying spaces. "Databricks Assistant" is what Genie Code used to be called, and plain "Genie" in a business context now means Genie One.
Climbing the ladder: the four hosting options
You've left step 0. From here you pick the model — and you own everything attached to it.
Why now: Unity AI Gateway went GA this week. That's what turns option 4 — bringing your own provider key — into a real governed object in Unity Catalog instead of a field on an endpoint config. The exact status:
"Service policies are in Beta. Unity AI Gateway is generally available, but its beta capabilities are enabled separately." (updated 2026-08-05)
So: the product is GA, the guardrails are still Beta. An account admin turns the Beta parts on from the Previews page.
Vocabulary for the top of the ladder
The Genie names all changed recently, and so did these. These are the terms to search for, and the ones your account team will use:
| Official term | What it is |
|---|---|
| Foundation Model APIs | Databricks-hosted frontier + open models. Two modes, not two products: pay-per-token and provisioned throughput. |
| Mosaic AI Model Serving | The serving layer generally — hosts your own custom models too. |
| Unity AI Gateway | The governance layer. GA as of this week; service policies/guardrails still Beta. |
| Model service | A Unity Catalog object standing in for a governed model endpoint, holding its routing and fallback config. |
| Model provider service | The Unity Catalog object that holds your own provider key. |
| External models in Model Serving | The earlier path — provider config directly on an endpoint. Docs now label it "(legacy)." |
One thing worth remembering: Foundation Model APIs is one product with two ways to pay. Pay-per-token and provisioned throughput are the same API and the same models. You're choosing how you pay for capacity, not a different service.
The four options at a glance
| Where the model lives | Who holds the credential | UC governance surface | Bills as | |
|---|---|---|---|---|
| 1. FM APIs — pay-per-token | Databricks | Databricks | system.ai schema + AI functions | DBU / 1M tokens |
| 2. FM APIs — provisioned throughput | Databricks | Databricks | UC-registered model required | DBU / hour |
| 3. Custom model on Model Serving | Your UC catalog | Databricks | Full: versions, aliases, lineage, tags | DBU / hour |
| 4. Model provider service (BYOK) | Your provider | You (encrypted in UC) | Unity Catalog object; runs as owner | Provider invoices you |
Where this goes next
You've got the map. Genie Code for yourself, Genie Agents when someone else needs to ask the questions, and four hosting options the moment you need to name the model.
Part two takes those four options one at a time — pay-per-token, provisioned throughput, your own model in Unity Catalog — with working examples from my golf league lakehouse and the decision rule for each.
Part three covers the fourth option on its own: bringing your own provider key, which is new enough that most people don't know it exists yet.