Forum Discussion

Wiliam_Rosa's avatar
Wiliam_Rosa
MCT
Sep 28, 2026

One Command Opens Claude Code, Another Opens Codex: How Azure Databricks Governs Coding Agents

The best frontier model changes every few days, and that creates a structural dilemma for any company trying to give its whole team access to a coding agent. Locking into a single provider saves governance headaches, but leaves you stuck with a six-month-old choice right when something better shows up. Letting each team choose freely solves the stagnation problem, but scatters API keys, spend limits, and audit logs across a pile of disconnected systems, every coding agent with its own account, its own access secret pasted onto the developer's machine.

Azure Databricks' Unity Gateway CLI attacks that dilemma without inventing a new permission system: it reuses the same Unity Catalog that already governs the rest of the company's data, and gives the developer the simplest possible experience, one command that opens the approved agent already authenticated, with no provider key pasted anywhere on the local machine.

What the single command actually solves

The Unity Gateway CLI (ug) is the single entry point for running coding agents against Unity Gateway: it handles OAuth, writes each agent's config file, and routes all traffic through whatever model or MCP server is already registered in the workspace. ug claude opens Claude Code, ug codex opens Codex CLI, ug gemini opens Gemini CLI, and the same CLI also covers OpenCode, GitHub Copilot CLI, and Pi, with ug --help listing the full supported set.

Registering a tool follows the same simplicity pattern: ug mcp add connects a native Azure Databricks MCP server, Unity Catalog function, AI Search, SQL warehouse, or external connection already discovered in the workspace, without the developer having to wire that integration by hand. ug usage returns a seven-day consumption summary straight in the terminal, no separate dashboard needed for a quick check.

The structural insight here isn't the command-line interface itself, it's what it avoids: without this central point, every team ends up pasting a provider's API key straight into each tool's local config, and the company loses aggregate visibility exactly when it needs it most, once coding-agent spend starts to scale.

How the admin governs access and spend

The detail that stands out most to anyone who already administers Azure Databricks: governing a coding agent doesn't require learning a new system. A model service is governed like any other protected Unity Catalog object, through the same three mechanisms as always.

First, permission: in Catalog Explorer, granting EXECUTE on the model service to a user or group, under the Permissions tab, decides who can use that model through a coding agent. Second, rate limiting: still in Catalog Explorer, on the model service's Overview tab, setting a queries-per-minute (QPM) or tokens-per-minute (TPM) limit, for everyone or per user. Third, budget: an account admin creates a budget that aggregates spend across every Unity Gateway endpoint, with a configurable threshold to alert on, or block, usage before cost exceeds what was agreed.

Once configured, you can confirm traffic is actually flowing through Unity Gateway and being recorded by querying the usage system table:

SELECT service_name, requester, status_code, COUNT(*) AS calls
FROM system.ai_gateway.usage
WHERE service_type = 'MODEL_SERVICE'
GROUP BY service_name, requester, status_code
ORDER BY calls DESC;

That means changing who has access to which model, or tightening a specific team's spend limit, is just another Unity Catalog permission change, not a parallel configuration the platform team has to learn from scratch.

Smart Routing: per-task savings, still in Beta

Smart Routing automatically picks the lowest-cost model capable of handling each task, so the developer doesn't have to choose a model for every prompt. The feature is in Beta and enabled per account: an account admin has to turn the preview on before any user can use it.

Activation is per agent, via the CLI's own flag:

ug codex --enable-smart-routing
ug claude --enable-smart-routing

The setting persists across sessions, and turning it off follows the same pattern (--disable-smart-routing). Two restrictions matter in practice: Smart Routing only chooses among model services prefixed system.ai, and the user needs EXECUTE on every candidate model in the routing pool, otherwise the request fails, naming exactly which model service is missing permission, not a generic error. Routing across different agents (say, from Claude Code to Codex) requires Omnigent, version 0.8.0 or later; within a single agent, routing already works on its own via the CLI.

Tracking: from the usage table to OpenTelemetry

Beyond querying system.ai_gateway.usage directly, Azure Databricks also exposes a ready-made dashboard: under Govern, in the top right of the Unity Gateway page, the Usage Dashboard tab includes a section dedicated to coding agents, with usage and cost charts per tool, no query needed.

For anyone who wants finer granularity than the aggregate usage table, Azure Databricks also supports exporting metrics and logs via OpenTelemetry straight into a Unity Catalog managed Delta table, with the metric and log schema already defined for a CREATE TABLE. Claude Code, for example, exports this by setting CLAUDE_CODE_ENABLE_TELEMETRY and a set of OTEL_EXPORTER_OTLP_* variables pointing at the workspace's /api/2.0/otel/v1/metrics endpoint, but that path requires turning on the OpenTelemetry preview in Azure Databricks first.

Hands-on: from zero to configured governance

Installation requires Python 3.12 or later and uv, done once per device:

uv tool install git+https://github.com/databricks/unity-gateway

With that installed, the developer opens the approved agent, and on first use the CLI asks for the workspace URL and authenticates on its own:

ug claude     # Claude Code
ug codex      # Codex CLI
ug gemini     # Gemini CLI
ug opencode   # OpenCode
ug copilot    # GitHub Copilot CLI

On the admin side, with no new API required: grant EXECUTE on the model service to a group in Catalog Explorer, set QPM or TPM on the same screen, and create an account budget covering the Unity Gateway endpoints. All three actions use the interface any Unity Catalog admin already knows, the coding agent just becomes one more consumer of the same model the platform already serves.

What this doesn't solve on its own

Smart Routing is still Beta, enabled per account, and restricted to regions with Unity Gateway support, so not every workspace has access today. Routing within a single agent only works if the user has EXECUTE on every candidate model, missing permission on just one candidate already breaks the request. Routing across different agents isn't native to the CLI, it depends on a specific Omnigent version. And fine-grained tracking via OpenTelemetry, while documented, requires turning on a separate preview, it doesn't come enabled by default alongside the CLI.

Beyond that, not every client is covered via ug: Cursor IDE, for example, still depends on manual configuration (base URL and key pointed straight at Unity Gateway in the editor's own settings), the CLI only covers terminal-based agents.

Is it worth adopting this way?

The strongest point here isn't the CLI itself, it's the fact that governing a coding agent doesn't require a parallel permission system: it's the same Unity Catalog EXECUTE, the same per-model-service rate limit, the same account budget any Azure Databricks admin already uses for another workload. For a company already feeling the classic symptom, scattered provider keys, spend invisible until the bill arrives, reusing this mechanism lowers the cost of adoption precisely because it asks nobody to learn new governance, just apply what already exists to one more type of consumer. Smart Routing's payoff is real, but conditional on being available in your region and your account already having the preview turned on, so it's worth confirming that before promising the team routing savings.

References

azure
azure databricks
No RepliesBe the first to reply