OpenGenie

The Databricks coding agent, on the model you choose.

Website and documentation: https://raphaelmansuy.github.io/opengenie/ — the tour, the install guide, the evidence page and the design notes. The source is on GitHub; the current release is v1.1.0.

Genie Code is the best coding agent for data engineering because it can see your workspace: Unity Catalog, SQL warehouses, notebooks, jobs. What it does not let you do is choose the model, or control what the work costs. OpenGenie is an open-source Databricks App that gives a coding agent the same kind of workspace context and hands those two decisions back to you.

The app deployed in a Databricks workspace. The notebook is the centre of the screen; the assistant sits beside it and knows which notebook the conversation is about.

---

Why it exists

Genie Code got the important part right: the agent works inside Databricks, so its answers come from your data instead of from a guess. 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 decisions to the team. Before building it, he measured whether the model matters. Same agent, same tools, same rules, on eight development tasks scored in a live workspace. The score is the scoring points earned out of the points available across those tasks:

Model	Points earned
gpt-oss-120b	39% (60 of 152)
Gemini 3.8 Flash	86% (130 of 152)

One run each. The caveats and the command that regenerates these numbers are on the evidence page. The model was the largest lever we could measure, and it is the one a Genie Code user cannot pull.

What the agent can reach

Each conversation gets its own MCP tool server. In a deployment it calls Databricks as the signed-in user, so Unity Catalog permissions still decide what the agent sees. Run locally, it acts as the owner of the token you give it.

Area	What it does	Tools
Unity Catalog	lists tables, reads columns, types and comments, searches table and column names	dbx_list_tables, dbx_describe_table, dbx_search_tables
SQL warehouses	runs the query, reads the result or the engine's error, corrects itself	dbx_run_sql
Notebooks	reads, searches, writes and runs notebooks; reports the first failing cell	dbx_read_notebook, dbx_grep_notebook, dbx_write_notebook, dbx_run_notebook
Jobs	creates and runs jobs under the session prefix, checks the latest run succeeded	dbx_create_job, dbx_run_job, dbx_job_run_status
Lakebase and Apps	creates a Lakebase instance, runs SQL on it, scaffolds a Databricks App	dbx_lakebase_*, dbx_create_app
SQL editor	reads, updates and runs the attached query draft; retrieves the same execution in the editor	dbx_read_query, dbx_update_query, dbx_run_query, dbx_query_run_status
Skills	five playbooks: SQL queries, notebook authoring, ETL pipelines, Lakebase, Databricks Apps	dbx_skill

That is the 32-tool core profile the app starts. The server (tools/databricks_notebook_mcp.py) has 45; the full profile adds catalogue and schema listings, lineage, grants, pipelines and warehouses.

Three rules the server enforces

	Rule	Where
1	The model is a setting. 13 models from 4 providers ship in the catalogue (Databricks serving endpoints, OpenAI, Anthropic, Google Vertex), and the serving endpoints your workspace exposes are discovered at run time. Personal provider keys are envelope-encrypted with a key held in a Databricks secret.	seed/llm_models.yaml, api/adapters/llm/
2	Writes stay inside the fence. The 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 made from the app outside the folder waits for your approval.	api/adapters/mcp/registry.py, api/domain/scope.py
3	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 such.	api/domain/evidence.py

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗