Artemis CLI

Command-line interface for the Artemis AI code platform.

The Artemis CLI drives the full Artemis platform from your terminal: import repositories, run AI-driven evolutionary discovery, build with AI agents, scan and fix code-health issues, and ship the results as pull requests. It is built for both humans and LLM agents — every command runs non-interactively and can emit structured JSON — which makes it ideal for scripting, CI/CD pipelines, and agent-driven workflows (e.g. Claude Code) as well as day-to-day terminal use.

Install the Artemis CLI

Prerequisites

macOS, Linux, or Windows
A bash shell on macOS/Linux, or PowerShell 5.0+ on Windows
Internet connection for download and API access
An Artemis API key — generate one from the Artemis web UI

1. Download and run the installer

The installer downloads the right artemis binary for your OS and architecture, verifies its checksum, installs it to ~/.local/bin, and points the CLI at your Artemis deployment. Two independent choices are available:

Which build to install — --version <X.Y.Z> (a specific release), --nightly (newest release including prereleases), or --dev (the rolling development build). The default is the newest stable release. The three are mutually exclusive.
Which deployment to talk to — --env prod (the hosted Artemis platform, and the default), or --base-url <url> for an on-prem/custom deployment.

curl -L --digest -u "Artemis_User:Artemis_Custom_Runner_2025" \
  "https://files.artemis.turintech.ai/artemis-cli/latest/artemis-cli-installer.sh" \
  -o installer.sh && chmod +x installer.sh && ./installer.sh --env prod

On-premise / custom deployment

curl -L --digest -u "Artemis_User:Artemis_Custom_Runner_2025" \
  "https://files.artemis.turintech.ai/artemis-cli/latest/artemis-cli-installer.sh" \
  -o installer.sh && chmod +x installer.sh \
  && ./installer.sh --base-url https://your-custom.artemis.turintech.ai

Install a specific version, or a pre-release build

./installer.sh --version 2.3.0 --env prod   # a specific stable release
./installer.sh --nightly --env prod         # newest build incl. prereleases
./installer.sh --dev --env prod             # rolling development build

Other installer flags: --install-dir <dir> (default ~/.local/bin) and --help.

note

If ~/.local/bin is not on your PATH, the installer prints the line to add to your shell profile. Reload your shell (or source ~/.bashrc) and artemis will be available everywhere.

Alternative: download the binary directly

For CI images, containers, or air-gapped setups, download the binary yourself:

curl -L --digest -u "Artemis_User:Artemis_Custom_Runner_2025" \
  "https://files.artemis.turintech.ai/artemis-cli/latest/artemis-cli-linux-amd64" \
  -o artemis && chmod +x artemis

Swap artemis-cli-linux-amd64 for artemis-cli-linux-arm64, artemis-cli-darwin-amd64, artemis-cli-darwin-arm64, or artemis-cli-windows-amd64.exe as needed, and swap latest for nightly, dev, or a version like 2.3.0. Each channel directory also carries a checksums.txt. When you download the binary directly the installer hasn't configured anything — set the deployment yourself in the next step.

2. Connect and authenticate

artemis login points the CLI at a deployment and stores your API key. It writes exactly two values — ARTEMIS_BASE_URL and ARTEMIS_API_KEY — and every service endpoint is derived from that single base URL. The command verifies the URL is reachable and validates the key against it before storing either.

# Interactive — prompts for the deployment URL and API key
artemis login

# Non-interactive — pass prod (hosted Artemis) or a full URL
artemis login --url prod --api-key <your-api-key>
artemis login --url https://your-custom.artemis.turintech.ai --api-key <your-api-key>

The installer already set the base URL, so after running it you can simply supply the key:

artemis login --api-key <your-api-key>

API keys are per-deployment: changing the URL clears any previously stored key. artemis logout removes the stored API key but keeps the base URL.

3. Verify

artemis status

status reports your configuration, whether you're authenticated, and health-checks each derived service endpoint. It exits non-zero if the configuration is invalid or no API key is set, so scripts can gate on it.

Environments

If you work against more than one deployment — a dev box, staging, and production — artemis env gives you kubectl-style contexts instead of re-running login each time. Each environment is its own config file under the user config directory (envs/<name>.env) holding that deployment's URL and API key, and the selected one is what login, config set, and every other command read and write.

# Create environments and switch between them
artemis env add staging --url stg --api-key <key>
artemis env add production --url prod --use
artemis env use staging

# Where am I?
artemis env current
artemis env list

# One-off command against another environment
ARTEMIS_ENV=production artemis project list

# Back to the pre-environments config
artemis env use default
artemis env remove staging

env add --url takes a full base URL or a named deployment; the API key can be supplied here or set later by switching to the environment and running artemis login.

note

Environments are entirely opt-in. Until you create one, the CLI keeps using its single default config exactly as before, and the name default always refers to that config.

Feature Overview

The CLI is organized into command groups, grouped by workflow stage.

Getting Started

Command	What It Does
`login` / `logout`	Connect the CLI to a deployment and store/remove your API key
`status`	Show configuration and connectivity status
`env`	Switch between deployments (named environments)
`config`	Show, set, or edit configuration values
`tui`	Launch the interactive terminal dashboard

Optimise

Command	What It Does
`project`	Import and manage Git repositories
`changeset`	Inspect, validate, publish, and ship the staged code changes behind PRs

Build with AI

Command	What It Does
`discovery`	AI-driven evolutionary code discovery
`task`	Create and execute AI coding tasks (single work items)
`plan`	Break complex features into structured tasks with AI
`chat`	AI-powered conversations about your codebase

Maintain

Command	What It Does
`maintain`	Scan, triage, and fix code-health issues, then ship the fixes

Resources

Command	What It Does
`context`	Manage durable context injected into your agents
`key`	Manage Git authentication keys
`runner`	View the Artemis Runner fleet
`model`	View available LLM models and manage registered model entries
`profile`	Manage the platform's LLM provider connections
`process`	Inspect background processes started by async commands
`logs`	Browse the platform's own service logs (admin-only)
`version`	Print CLI version information

Run artemis <command> --help for full details on any group or subcommand.

Conventions

Every command follows the same house rules, which make the CLI predictable for both people and agents:

Structured output. Add --output-format json to any command to get one JSON document on stdout; human-readable progress and errors go to stderr. The default is text.
ID or name. Wherever a command takes -p, --project, you can pass either the project ID or its name. Name resolution is scoped to your user; on an ambiguous name the CLI lists the candidates rather than guessing.
Positional IDs. The primary resource ID is a positional argument (artemis discovery get <run-id>), not a flag.
Pagination. List commands accept --page / --per-page, and --all to fetch and aggregate every page.
Long-running ops. Async commands accept --wait (block until a terminal state) and --timeout (default 20m). A wait that times out exits with code 6.
Destructive ops. Commands that delete or overwrite accept -f, --force to skip the confirmation prompt.
Interactive when interactive. Commands whose agent can ask a question (plan create, plan respond, maintain rules create, maintain chat) prompt at a terminal, and fall back to --answer / -m flags or a single request/response turn when piped — so the same command works for a person and for an agent driving the CLI.

Global flags

Flag	Description
`--debug`	Enable verbose debug output
`--config <path>`	Path to the config file (default: `./.env` if present, else the selected environment's file)
`--output-format <fmt>`	`text` (default) or `json`
`-h`, `--help`	Show help for the command

Exit codes

Code	Meaning
0	Success
1	Generic error
3	Authentication error (HTTP 401/403)
4	Not found (HTTP 404)
5	Server error (HTTP 5xx)
6	Wait timed out (`--wait` / `--timeout` expired)

Typical Workflow

A complete end-to-end run, from an empty account to a pull request:

# 1. SETUP — verify your connection
artemis status

# 2. ADD A GIT KEY — register your Personal Access Token
artemis key add --name "github-work" --provider github --token <PAT>

# 3. IMPORT A PROJECT — clone a repo into Artemis
artemis project import \
  --git-url https://github.com/your-org/your-repo.git \
  --key-id <key-id>

# 4. SET BUILD COMMANDS — what a runner executes to compile, test, benchmark
artemis project commands set --project <project> \
  --compile "go build ./..." --test "go test ./..." --benchmark "go test -bench=."

# 5. CHECK THE COMMANDS WORK — validate the unmodified code on a runner
artemis changeset create --project <project> --name "baseline"
artemis changeset validate <changeset-id> --project <project> \
  --version original --runner my-runner --wait

# 6. DISCOVER — run the AI optimisation loop against a task
artemis discovery create --project <project> \
  --task "Reduce p99 latency of the request path" \
  --model <model-id> --target-files src/server.go \
  --versions 10 --runner my-runner

# 7. INSPECT — review what the agent produced and how it scored
artemis discovery get <run-id>
artemis discovery versions list <run-id>
artemis discovery metrics <run-id> --stats

# 8. SHIP — open a pull request from the winning changeset
artemis changeset list --project <project>
artemis changeset pr <changeset-id> --project <project> --title "Performance improvements"

Discovery

Discovery is Artemis's continuous AI-driven optimisation loop. An agent proposes experiments (testable hypotheses about what might improve the code), implements each attempt as a code version, executes it on a runner, and scores it against the run's metric schema — bounded by the run's version budget.

Entity	What it is
run	The top-level optimisation loop for a task
experiment	A testable hypothesis, concluded validated / refuted / inconclusive
version	A generated code candidate, executed and scored by fitness
baseline	The unmodified code, executed once to anchor metric comparisons
metrics	Recorded metric values for the run's executed versions

Starting a run

Execution runs (the default) measure a baseline and run each generated version, so they need a benchmark command and a runner. The project's stored build commands are used as defaults, matching the UI; --compile-cmd / --test-cmd / --benchmark-cmd override them. With --skip-execution, versions are graded by review instead and no commands or runner are needed.

# Minimal run — no commands or runner needed
artemis discovery create --project <project> \
  --task "Speed up JSON parsing" --model <model-id> --skip-execution

# Full configuration
artemis discovery create --project <project> \
  --task "Reduce p99 latency" \
  --model <model-id> \
  --target-files src/handler.go --target-files src/cache.go \
  --versions 10 \
  --compile-cmd "go build ./..." \
  --test-cmd "go test ./..." \
  --benchmark-cmd "go test -bench=." \
  --runner my-runner --mode automatic

--model is required — the API does not pick a default. It takes a model-catalogue UUID or a model-type code (see Models). --target-files and --review-model are repeatable.

Following and steering a run

artemis discovery list --project <project>
artemis discovery get <run-id>
artemis discovery versions list <run-id>
artemis discovery versions logs <version-id>
artemis discovery experiments list <run-id> --status validated

# Redirect an active agent mid-run
artemis discovery steer <run-id> --message "Focus on algorithmic changes, don't touch build flags"

# Extend a finished run's version budget
artemis discovery continue <run-id> --versions 5

# Change a run's commands, runner, or status
artemis discovery update <run-id> --runner other-runner
artemis discovery cancel <run-id>

Metrics and fitness

Each metric is measured once per benchmark repetition, so a metric can have many raw samples per version. metrics lists the individual samples by default; --stats shows the summary statistics over them — mean, standard deviation, standard error, min, max, sample count, and improvement against the baseline — the same numbers the UI shows.

artemis discovery metrics <run-id>
artemis discovery metrics <run-id> --stats --all

# Replace the run's fitness metric schema and recompute version fitness
artemis discovery metrics-schema set <run-id> --file schema.json

# Set or (re)execute the baseline
artemis discovery baseline set <run-id> --metrics-schema schema.json
artemis discovery baseline execute <run-id>

A metric schema is a JSON array of metric descriptors:

[
  {"metricId": "<metric-uuid>", "source": "worker", "higherIsBetter": false, "importance": 0.7},
  {"metricId": "<metric-uuid>", "source": "agent", "higherIsBetter": true, "importance": 0.3,
   "description": "Code readability", "extractionHint": "Judge naming and structure"}
]

Discovery also exposes experiments create/update/delete and versions create/execute/update for finer control — see artemis discovery --help.

Changesets and validation

A changeset is the staged set of code changes that discovery runs, tasks, plans, chats, and maintain fixes produce before they become pull requests. Your git remote stays untouched until you publish a branch or open a PR. See Changesets for the UI equivalent.

artemis changeset list --project <project>
artemis changeset get  <changeset-id> --project <project>
artemis changeset diff <changeset-id> --project <project> --stat
artemis changeset diff <changeset-id> --project <project> --base <sha> --head <sha>

Validation

changeset validate runs a version's compile, test, and benchmark commands on a runner. This is the same primitive discovery uses to evaluate every version it generates, including the baseline — so it's the exact code path real runs take, not an approximation. The commands come from the project's configured build commands, or from a named validation script via --script.

Creating a changeset gives you exactly one version — the project's current original code — which makes it the standard way to check your build commands actually work before starting a run:

artemis changeset create --project <project> --name "baseline"
artemis changeset validate <changeset-id> --project <project> \
  --version original --runner my-runner --wait

# Per-command results and the full process log
artemis changeset validation get  <validation-id>
artemis changeset validation logs <validation-id>

Shipping

# Publish to a branch, without opening a PR (auto-named unless --branch is given)
artemis changeset publish <changeset-id> --project <project> \
  --branch my-fix --commit-message "fix: nil deref"

# Publish and open a pull request — title and description are AI-generated when omitted
artemis changeset pr <changeset-id> --project <project> --title "feat: add auth" --base develop

changeset pr works on any changeset regardless of where it came from, so the whole loop can be driven from the terminal. task pr and maintain issues pr are convenience wrappers that resolve the changeset for you.

AI Coding

Tasks

A task is a single work item for an AI agent to implement. Tasks move through todo → in_progress → done / failed / cancelled.

# Create and auto-start a task, waiting for it to finish
artemis task create --project <project> \
  --prompt "Add input validation to user registration" \
  --auto-start --wait

# Or create now, start later
artemis task create --project <project> --prompt "Implement rate limiting"
artemis task start <task-id> --model <model-type> --wait --timeout 30m

# List, inspect, and follow a task
artemis task list --project <project> --status done
artemis task get  <task-id>
artemis task logs <task-id>
artemis task stop <task-id>

# Ship the result as a PR
artemis task pr <task-id> --title "feat: add input validation"

Plans

A plan breaks a large feature into ordered tasks with AI assistance. The agent asks clarifying questions, analyzes your code, and produces an implementation roadmap.

# Interactive planning (the agent asks questions)
artemis plan create --project <project> \
  --prompt "implement user authentication with OAuth2"

# Skip the Q&A for simple, well-defined work
artemis plan create --project <project> \
  --prompt "add unit tests for the user service" --skip-interaction

artemis plan list --project <project>
artemis plan get <plan-id>

At a terminal the agent's questions are asked inline. Elsewhere — agents, CI, anything that pipes stdin — the command prints what is being asked and stops, and you answer the same plan with plan respond:

# See what the plan is waiting on
artemis plan respond <plan-id>

# Answer the first question with its second choice
artemis plan respond <plan-id> --answer 2

# Answer several questions, targeting them by number
artemis plan respond <plan-id> --answer "1=comprehensive" --answer "2=3"

warning

Don't re-run plan create to supply an answer — that starts a second plan, whose agent asks its own question, leaving the first one parked forever. plan create also accepts --answer up front, which implies --wait.

Chats

Chats are AI-powered conversations about your codebase — for understanding, debugging, or architecture questions. Use chat send to answer an agent's questions and chat messages to follow the conversation; this is the same mechanism that drives interactive rule and plan authoring.

# Async chat (runs in the background)
artemis chat create --project <project> --message "Explain the authentication flow"

# Real-time streaming
artemis chat create --project <project> --message "Where are the vulnerabilities?" --sync

# Continue an existing chat
artemis chat send <chat-id> --message "Now focus on the login handler"
artemis chat messages <chat-id>
artemis chat cancel <chat-id>

Chat vs Task vs Plan: Chat answers questions (no code changes); Task is a single coding work item; Plan breaks a feature into multiple tasks.

Maintain

Maintain finds, triages, and fixes code-health issues, then ships the fixes. The flow is: author rules → scan the code against them (which creates issues) → triage the issues → fix them (with Artemis's agent, or by exporting a prompt for your own) → publish a branch or open a PR → sync the board as the code moves on.

# 1. Get rules in place — import the default catalogue, or author your own
artemis maintain rules defaults                 # browse the platform catalogue
artemis maintain rules import-defaults --project <project>
artemis maintain rules create --project <project> \
  --prompt "Flag any SQL query built with string concatenation"
artemis maintain rules update <rule-id> --project <project> --name "No raw SQL"

# 2. Scan the code (creates issues on the board; --rule is required, repeatable)
artemis maintain scans run --project <project> --rule <rule-id> --count 10 --wait
artemis maintain scans run --project <project> --rule <rule-id> \
  --path src/ --path lib/ --commit <sha>

# 3. Triage the findings
artemis maintain issues list --project <project> --severity high --status open
artemis maintain issues confirm <issue-id>     # true positive
artemis maintain issues dismiss <issue-id>     # false positive (closes it)
artemis maintain issues close   <issue-id>     # close without ruling on validity

# 4. Fix — with Artemis's agent, or export a prompt for your own agent
artemis maintain issues fix <issue-id-1> <issue-id-2>
artemis maintain issues prompt <issue-id> --project <project> | my-agent

# 5. Ship — publish a branch, or open a PR
artemis maintain issues publish <issue-id> --project <project>
artemis maintain issues pr <issue-id> --project <project> --title "fix: sanitize query"

# 6. Keep the board honest as the code changes
artemis maintain syncs run --project <project> --wait

Every issue and rule carries a human-friendly display ID (ISS-143, RULE-7). Those are for readability only — commands take the underlying UUID.

issues fix accepts several issue IDs at once: all the fixes land in a single changeset, and the agent's work streams into one chat you can follow with artemis chat messages <fix-chat-id>. issues list filters on --severity, --status, --validity, --fix-status, --complexity, --rule, and --path-prefix, and sorts with --sort / --order.

Rule authoring

Rule authoring is agent-driven. By default rules create waits for the authoring agent and approves the rule it proposes, so it returns a rule you can scan with straight away. Pass --auto-approve=false to get the [DRAFT] back immediately with the agent left waiting — a draft cannot be scanned.

A question is never auto-answered. At a terminal the CLI asks you; otherwise pass --answer, which also wins over the prompt so scripts stay deterministic. Rule editing supports renaming (--name) and rewriting the definition from markdown (--markdown-file); category, severity, and tags come from the rule definition and aren't editable directly.

Maintain chat

artemis maintain chat holds a conversation with the maintain agent over a project's board. The agent reads both the board and the project's source, so you can hunt for a problem by describing it rather than scanning for it — and have the agent raise the issue once you agree what it is. It can also manage rules and start scans and fixes from the same conversation.

# Back-and-forth session at a terminal (empty line to end)
artemis maintain chat --project <project>

# One turn, for scripting
artemis maintain chat --project <project> \
  -m "is there anywhere we parse the same response twice?" --output-format json

Issues raised this way land on the board like any other, and can be fixed with artemis maintain issues fix.

Projects and Git Keys

Supported Git providers

GitHub (github)
GitLab (gitlab)
Bitbucket (bitbucket)
Azure DevOps (azure)

Managing keys

Artemis needs a Personal Access Token to clone private repos, create branches, and open PRs. Keys are encrypted at rest and referenced by ID.

artemis key add --name "github-work" --provider github --token ghp_xxxxxxxxxxxx
artemis key add --name "bitbucket" --provider bitbucket --token <token> --email you@example.com
artemis key add --name "azure" --provider azure --token <token> --organization myorg
artemis key list
artemis key delete <key-id>   # does not revoke the underlying token

Required token scopes:

Provider	Token Type	Scopes
GitHub	PAT / Fine-grained PAT	`repo`
GitLab	PAT	`api`, `read_repository`, `write_repository`
Bitbucket	App Password	Repositories read/write
Azure DevOps	PAT	Code read/write

Importing and managing projects

# Import (auto-sync enabled by default)
artemis project import \
  --git-url https://github.com/your-org/repo.git \
  --key-id <key-id> --name "My API Service" --branch develop

# Track a different branch/commit, or pull upstream changes
artemis project branch <project> --branch main
artemis project pull   <project>
artemis project compare <project>

# Set build/test/benchmark commands and a default runner
artemis project commands set --project <project> \
  --compile "go build ./..." --test "go test ./..." --benchmark "make bench"
artemis project commands get --project <project>
artemis project runner set --project <project> --runner my-runner

# Search, filter, and clean up
artemis project list --search "my-api" --language python
artemis project delete <project>

Auto-sync mirrors your repository to Artemis's internal Gitea, which is required for task execution and PR creation. It's on by default at import; if you imported with --auto-sync=false, enable it later with artemis project sync <project>.

Context

Contexts are durable knowledge about how you work, applied to every agent you run. They're personal — they apply only to agents you run.

Availability	Behaviour
`always_on`	Injected into every agent's system prompt (counts against the upfront token budget)
`on_demand`	Agents see the name and description only, and choose when to read the body
`disabled`	Stored but not offered to agents

# Store an always-on convention
artemis context add --name "code style" --body "We use conventional commits" --always-on

# On-demand reference material from a file, with the description agents see
artemis context add --name "deploy runbook" --description "How we ship" --body-file runbook.md

# From a pipe — e.g. an agent recording what it learned
echo "staging DB resets nightly" | artemis context add --name "staging db" --source agent

# Inspect and manage
artemis context list --availability always_on
artemis context get <context-id>
artemis context update <context-id> --availability always_on
artemis context usage      # upfront context size against the token budget
artemis context delete <context-id>

New contexts are on-demand unless --always-on or --disabled is given.

Models and providers

Commands that generate code or reason about it accept --model. Each model has two identifiers, and different commands want different ones:

the model-type code (e.g. claude-sonnet-5) — used by task create / task start
the catalogue ID (a UUID) — used by chat create

discovery create, maintain scans run, maintain issues fix, and maintain chat accept either form. artemis model list prints both.

artemis model list                  # the preset tiers agents can use, with both IDs
artemis model groups --task coding  # models organized by task type

If no model is specified, Artemis uses the configured default for each task type — except discovery create, where --model is required.

Provider connections

artemis profile manages the platform's LLM provider connections: the credentials and endpoints through which agents reach Anthropic, OpenAI, Azure, Bedrock, or a local Ollama instance. Each profile holds one provider's credentials; the models it exposes are managed with artemis model.

# What providers can be connected, and what credentials they take
artemis profile providers

# Connect a provider
artemis profile create --name anthropic-prod --provider anthropic --api-key sk-ant-...
artemis profile create --name local-ollama --provider ollama --no-auth --base-url http://localhost:11434
artemis profile create --name bedrock --provider bedrock \
  --credentials '{"type":"aws_iam","access_key":"...","secret_key":"...","region":"eu-west-2"}'

# What the provider offers, then register some of it
artemis profile catalog <profile-id>
artemis model add --profile <profile-id> --from-catalog claude-sonnet-5 --from-catalog claude-haiku-4-5

# Register a custom deployment manually
artemis model add --profile <profile-id> \
  --model-id my-tuned-model --base-model claude-sonnet-5 --name "Tuned Sonnet"

# Inspect, verify, and clean up
artemis model registry --profile <profile-id>
artemis model validate
artemis profile list

--base-model takes a model id from the litellm model catalog; it tells the platform which catalog entry a custom-named model should inherit capabilities, token limits, and pricing from.

Background processes and platform logs

Async commands hand back a processId instead of blocking. A process's overall status can read success while an individual step inside it was a no-op or a failure, so use status for the summary and progress-detail breakdown, and logs for the full step-by-step trace.

artemis process status <process-id>
artemis process logs   <process-id>

artemis logs browses the logs of the platform's own services — APIs, workers, and infrastructure like postgres or kafka. It requires an admin user; other users get a permission error. It defaults to the last hour, newest first.

artemis logs services                          # what can be queried
artemis logs falcon --level error
artemis logs falcon --search "changeset" --since 6h
artemis logs falcon --follow                   # live tail

Interactive TUI

For a richer terminal experience, launch the dashboard:

artemis tui

The TUI (built on Bubble Tea) provides a two-panel view — projects on the left, details on the right — with ↑/↓ or j/k to navigate, Tab to switch panels, r to refresh, and q to quit.

Configuration

The CLI loads configuration from environment variables and a .env file. Priority: environment variables > .env file > defaults. The file is resolved as ./.env in the current directory if present (a project-local override), otherwise the selected environment's file under ~/.config/artemis/.

Common commands

# Show current configuration
artemis config
artemis config show

# Set a single value
artemis config set ARTEMIS_API_KEY <your-api-key>

# Open the config file in your editor
artemis config edit

The recommended way to (re)point the CLI at a deployment is artemis login — it writes and validates ARTEMIS_BASE_URL and ARTEMIS_API_KEY for you.

Environment variables

Required

Variable	Description
`ARTEMIS_BASE_URL`	Deployment base URL. Every service endpoint is derived from it. Accepts a full URL, or `prod` for hosted Artemis.
`ARTEMIS_API_KEY`	Your Artemis API key

A single ARTEMIS_BASE_URL is all most users need — the services are path prefixes on one host, so the CLI derives the user-management, Artemis backend, and Falcon endpoints from it. For advanced setups you can still override an individual endpoint by setting its explicit variable (USER_MGMT_URL, ARTEMIS_API_URL, FALCON_URL); an explicit override shadows the derived value.

Optional preferences

Variable	Default	Description
`ARTEMIS_ENV`	—	Named environment to use for this invocation (overrides the selected one)
`ARTEMIS_DEBUG`	`false`	Enable verbose debug output
`ARTEMIS_OUTPUT_FORMAT`	`text`	Output format: `text` or `json`
`ARTEMIS_TIMEOUT`	`120s`	Request timeout (e.g. `30s`, `2m`)
`ARTEMIS_RETRY_ATTEMPTS`	`3`	Number of retry attempts
`ARTEMIS_RETRY_DELAY`	`1s`	Delay between retries
`ARTEMIS_MODEL_TYPE`	—	Default model for code generation and analysis

Getting Help

Every command and subcommand has its own help text with examples:

artemis --help
artemis maintain --help
artemis discovery create --help

For runner setup, see Artemis Runner. For genetic-algorithm-based optimization details, see Artemis Intelligence.

Install the Artemis CLI​

Prerequisites​

1. Download and run the installer​

Alternative: download the binary directly​

2. Connect and authenticate​

3. Verify​

Environments​

Feature Overview​

Getting Started​

Optimise​

Build with AI​

Maintain​

Resources​

Conventions​

Global flags​

Exit codes​

Typical Workflow​

Discovery​

Starting a run​

Following and steering a run​

Metrics and fitness​

Changesets and validation​

Validation​

Shipping​

AI Coding​

Tasks​

Plans​

Chats​

Maintain​

Rule authoring​

Maintain chat​

Projects and Git Keys​

Supported Git providers​

Managing keys​

Importing and managing projects​

Context​

Models and providers​

Provider connections​

Background processes and platform logs​

Interactive TUI​

Configuration​

Common commands​

Environment variables​

Getting Help​

Install the Artemis CLI

Prerequisites

1. Download and run the installer

Alternative: download the binary directly

2. Connect and authenticate

3. Verify

Environments

Feature Overview

Getting Started

Optimise

Build with AI

Maintain

Resources

Conventions

Global flags

Exit codes

Typical Workflow

Discovery

Starting a run

Following and steering a run

Metrics and fitness

Changesets and validation

Validation

Shipping

AI Coding

Tasks

Plans

Chats

Maintain

Rule authoring

Maintain chat

Projects and Git Keys

Supported Git providers

Managing keys

Importing and managing projects

Context

Models and providers

Provider connections

Background processes and platform logs

Interactive TUI

Configuration

Common commands

Environment variables

Getting Help