Skip to main content
datumctl ai translates natural language into Datum Cloud operations. Ask it a question — “list all DNS zones”, “which projects am I in?” — and the assistant figures out which resources to read and shows you the answer. When it wants to make a change, it always pauses and asks you to confirm first.
The assistant reasons over your resources through a large language model, so you supply your own model API key (Anthropic, OpenAI, or Gemini). Your key and requests go directly to the provider you choose.

Before you start

You need two things:
  1. A logged-in datumctl. The assistant reads and writes real Datum Cloud resources, so you must be authenticated. Run datumctl login first.
  2. A model API key for the Anthropic Console, OpenAI, or Google Gemini.

Quick start

1

Log in

2

Save a model API key

Store the key once so you don’t have to export it in every shell:
3

Set a default scope (optional)

Point the assistant at the organization or project you work in most:
4

Ask a question

Asking questions

One-shot questions

Pass your question as an argument to get a single answer and return to your shell:
You can also pipe a question in on standard input, which is handy in scripts:
When input is piped in (no terminal attached), the assistant answers questions but will not perform any write — mutating actions are skipped because they can’t be confirmed. See The confirmation gate.

Interactive session

Run datumctl ai with no question to start an interactive REPL. The assistant keeps conversation context, so you can ask follow-up questions that build on earlier answers:
At the > prompt, type your next question. Type exit or quit (or press Enter on an empty line) to leave the session.

Choosing scope

The assistant needs to know which control plane to operate against. You can set scope three ways, from most to least specific:
Scope is resolved in this order: command-line flags → environment variables → active datumctl context → saved ai config defaults. Because the active context wins over saved ai defaults, switching with datumctl ctx use is respected without having to clear your ai config values. This mirrors how every other command resolves scope. A few rules:
  • --organization and --project are mutually exclusive — set one, not both.
  • --namespace sets the default namespace for the session (defaults to default).
  • --platform-wide targets the platform root instead of a single org or project. This is a staff-only mode and can’t be combined with --organization or --project.
If no scope is set at all, the assistant still runs, but without resource tools — it can chat, but can’t read or change anything until you give it an organization or project.

The confirmation gate

Reads and writes are treated very differently:
  • Read operations run immediately. Listing, getting, and describing resources happen without a prompt.
  • Write operations always pause for confirmation. Before creating, updating, or deleting anything, the assistant prints a preview of the exact action and asks you to approve it.
The preview shows the tool and the full arguments, then waits for your answer:
Only an explicit y proceeds; anything else declines.
When datumctl ai is run without an attached terminal (for example, with a piped question or in CI), write operations are automatically declined and skipped. Perform mutations only from an interactive terminal session.

Built-in tools

Behind the scenes the assistant works through a fixed set of tools scoped to the current organization or project. Read tools run on their own; the two write tools are gated by the confirmation prompt above.
Before proposing a write, the assistant can run validate_manifest to check your change with a server-side dry run — the same safety net as datumctl apply --dry-run=server — so you see problems before you approve anything.

Configuration

Saved settings provide defaults for every datumctl ai invocation, so you don’t have to repeat flags or export environment variables. Manage them with datumctl ai config:

Configuration keys

Run datumctl ai config show to print the resolved config path along with your current values; API keys are shown redacted.

Precedence and environment variables

  • Flags always win over config file values for a single invocation.
  • API keys can also come from environment variables, which override any key stored in the config file:
This lets you keep a default key in the config file for everyday use and temporarily override it per shell when needed.

Choosing a provider and model

You don’t have to set a provider explicitly — the assistant selects one using this order:
  1. Model name prefix. claude-* → Anthropic, gpt-* / o1* / o3* → OpenAI, gemini-* → Gemini.
  2. An explicit provider setting, if you set one.
  3. Whichever API key is available (environment variable first, then config file).
Set a model per invocation with --model, or save one as a default:
Each provider has a sensible default model if you don’t pick one: claude-sonnet-4-6 for Anthropic, gpt-4o for OpenAI, and gemini-2.0-flash for Gemini.

Next steps

  • Logging in — authenticate datumctl before your first question.
  • MCP server — prefer a graphical AI client? Connect Claude Desktop, Cursor, or another MCP-aware app to the Datum MCP server.
  • Datum MCP — install the standalone MCP server and get its full tool catalog.
  • Contexts & scoping — how scope resolution decides which organization or project the assistant operates against.
  • Reading resources — the get and describe commands the assistant runs on your behalf.
  • datumctl overview — new to the CLI? See how datumctl is structured.
Last modified on July 6, 2026