The Databricks coding agent,
on the model you choose.
Genie Code is the best coding agent for data engineering because it can see your workspace. OpenGenie gives an open-source agent the same kind of reach — Unity Catalog, SQL warehouses, notebooks, jobs — and hands back the two decisions Genie Code makes for you: which model does the work, and who you pay for it.
Why it exists
Genie Code gets one thing right that most coding agents get wrong: the agent works inside Databricks. It reads the catalogue, runs SQL on a warehouse, opens notebooks and inspects jobs, so its answers come from your data instead of from a guess. That context is why it is good.
Two things come with it that a team cannot change. The model is chosen for you, and the bill is metered by a product you do not configure. Raphael Mansuy built OpenGenie to keep the context and return those two decisions to the team: use the model you already pay for, or the one that is best at the task, and run the whole thing as a Databricks App in your own workspace.
Measured, not assumed
The model is the biggest lever on whether the work gets done
Same agent, same tools, same rules, eight development tasks graded against a live workspace. Only the model changed.
One run per model. The fractions, the caveats and the command that regenerates these numbers are on the evidence page.
What the agent can reach
Each conversation starts its own tool server. It calls the Databricks APIs as you, the signed-in user, so Unity Catalog permissions still decide what the agent can see.
Unity Catalog
Lists tables, reads columns, types and comments, and searches table and column names across the catalogue — so it looks a column up instead of guessing it.
SQL warehouses
Runs the query rather than describing it, reads the result or the engine's error, and corrects the next attempt from what actually came back.
Notebooks
Reads, searches and writes notebooks, then runs them and reports the first failing cell in the engine's own words.
Jobs
Creates and runs jobs under the conversation's name prefix, then checks that the latest run succeeded rather than assuming it did.
Lakebase and Apps
Creates a Lakebase Postgres instance, runs SQL against it, and scaffolds a Databricks App — each named inside the same prefix.
Skills
4 written playbooks — notebook authoring, ETL pipelines, Lakebase and Databricks Apps — that the agent loads only when a task needs one.
That is the 20-tool core profile the app starts. The tool server has 28; catalogue and schema listings, lineage, grants, pipelines and warehouse lookups are in its full profile, and left out of the app by default because an agent advertises every tool on every request and pays for it in tokens.
Three rules the server enforces
Not instructions in a prompt. Each one is code you can read, with tests.
The model is a setting
13 models from 4 providers ship in the catalogue — Databricks serving endpoints, OpenAI, Anthropic and Google Vertex — and the serving endpoints your workspace exposes are discovered at run time. A personal provider key is stored encrypted, with the key held in a Databricks secret.
Writes stay inside the fence
A conversation's tool server is started with one folder, one schema and one job-name prefix. A write anywhere else is refused by that server, with the reason; a write you make from the app outside the folder waits for your approval.
Done means proven
When the agent says a requirement is met, the claim is matched against the tool calls it actually made. A citation to a call that never happened is reported as exactly that.
How it fits together
One Databricks App process. For each conversation it starts an opencode agent over the Agent Client Protocol and a fenced tool server beside it.
- Youin the browser, signed in to Databricks
- OpenGenie AppFastAPI and React, acting as you
- Agent
opencode acp, one per conversation - Tool serverfenced to your folder, schema and prefix
- Your workspaceUnity Catalog, warehouses, notebooks, jobs
What working with it looks like
It keeps working when you leave
The work runs on the server and is journalled. Close the tab and come back to the result; after a restart, the app says what was interrupted instead of replaying it blindly.
A notebook, not a chat log
Run all stops at the first failure and shows where it is. Fix with agent sends the engine's own error, bound to that cell. Python cells, run on serverless by an administrator, draw their plots under the cell.
Show it, don't describe it
Attach a file or paste a screenshot of a failing dashboard. If the chosen model cannot see images, the app names that model and tells you to pick one that can, instead of sending pixels nobody reads.
Genie Code or OpenGenie?
They solve the same problem with different trade-offs. Pick on the trade-off, not on the logo.
Stay on Genie Code if
- you want nothing to deploy, configure or operate;
- one model is fine for your work, and the metered cost is acceptable;
- your hardest problem is finding the right table among thousands, where Genie's business semantics help most;
- you need inline completion, or Python running as you on your own clusters.
Use OpenGenie if
- you want to choose the model per task, or use one you already pay for;
- writes must stay inside a named folder and schema, enforced by the server;
- you want the agent's “done” checked against what it actually ran;
- you want to read, change and self-host the code under Apache‑2.0.
What this is not
- Not a replacement for Genie's understanding of business terms. The exams named their tables. Finding the right table in a catalogue of ten thousand is where an ontology earns its keep, and it is untested here.
- Not a cost comparison. We measured tokens, not money, and hold no Genie Code usage history. Any saving quoted from this repository would be invented, so none is.
- Not a hosted demo. The app needs your workspace, so there is nothing to click here. The tour shows real screenshots of it running.
- Not a guarantee. Small, clean data; one run per setup on most configurations; tasks that name their own tables. Where that matters, it is written on the claim.
Every score on this site is computed at build time from the run files in exams/results, and every count of models and tools is read from the application's source. If a figure and its source disagreed, the build would fail rather than publish.
Start here
Tour
Real screenshots: the notebook, the assistant, the mission view, approvals, recovery and the model picker.
Deploy
Put it in your workspace as a Databricks App, run it locally against your workspace, or start from a single notebook.
Tutorial
From a notebook in Databricks to an agent that runs real SQL and proves it. No local shell.