Artemis CLI

Command-line interface for the Artemis AI code platform.

The Artemis CLI drives the Artemis platform from your terminal: import repositories, run Discovery, plan and chat with agents, scan and fix code-health Issues, and ship the results as pull requests. It is built for both people and coding agents. Every command can run non-interactively and emit structured JSON, so it suits scripting, CI pipelines and agent-driven workflows (for example Claude Code) as well as day-to-day terminal use.

Artemis Desktop

Using Artemis Desktop? Quick start with a coding agent shows the CLI and skills with a local model.

note

The commands on this page need Artemis CLI 1.1.18 or later. If artemis version shows an older version, run the installer again with --version 1.1.18.

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, created under Platform Settings → API Keys

1. Download and run the installer

Platform Settings → Connect Your Agent shows the exact commands for your deployment and operating system, and a setup prompt your coding agent can follow. The steps below are the same commands for the hosted platform.

The Bash installer works on Linux and macOS, including Zsh terminals. It detects your architecture, verifies the binary's 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> for a specific release, --nightly for the newest release including prereleases, or --dev for 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-premise or custom deployment.

curl --fail --location 'https://files.artemis.turintech.ai/public/artemis-cli/latest/artemis-cli-installer.sh' \
  --output artemis-cli-installer.sh
bash ./artemis-cli-installer.sh

On-premise or custom deployment

bash ./artemis-cli-installer.sh --base-url https://your-custom.artemis.turintech.ai

A specific version, or a pre-release build

bash ./artemis-cli-installer.sh --version <X.Y.Z>   # a specific release
bash ./artemis-cli-installer.sh --nightly           # newest build including prereleases
bash ./artemis-cli-installer.sh --dev               # 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 and artemis will be available everywhere.

Alternative: download the binary directly

On Windows, or for CI images, containers and air-gapped setups, download the binary yourself. No credentials are needed:

curl --fail --location 'https://files.artemis.turintech.ai/public/artemis-cli/latest/artemis-cli-linux-amd64' \
  --output 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 number. Each channel directory also has a checksums.txt. A directly downloaded binary has no deployment configured yet, so set it 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 with more than one deployment, such as a development server, 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. The selected environment is the one that 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

Projects and Branches

Command	What It Does
`project`	Import and manage Git repositories, their Scripts and their default Runner
`changeset`	Inspect, verify, publish and ship Branches (the API calls them changesets)

Discover, Plan and Chat

Command	What It Does
`discovery`	Create, follow and steer Discovery Runs
`plan`	Break complex features into Tasks with the planning agent
`chat`	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
`skills`	Manage your AGENTS.md and Skills for Artemis 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 chat) prompt at a terminal. When their input is piped, they take the answer from --answer or -m instead, or make a single request and response, 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: the selected environment's file, with a `./.artemis.env` in the current directory merged over it)
`--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)
7	Not confirmed: pass `--force` to confirm a destructive command
8	Waiting for your answer
9	Write refused, nothing saved

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. CREATE A SCRIPT - what a runner executes: setup, then the measured benchmark
artemis project scripts create --project <project> --name "Go bench" --default \
  --setup-cmd "go build ./..." --setup-cmd "go test ./..." \
  --benchmark-cmd "go test -bench=. -run=^$ ./..."

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

# 6. DISCOVER - start a Discovery Run against an objective
artemis discovery create --project <project> \
  --task "Reduce p99 latency of the request path" \
  --model <model-id> --target-files src/server.go \
  --versions 10 --script <script-id> --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 best Version's Branch
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 variant, executed and given a Composite score
baseline	The unmodified code, executed once to anchor metric comparisons
metrics	Recorded metric values for the run's executed versions

Starting a run

A run's --execution-mode decides what it does with its Script. benchmark (the default) measures a Baseline and runs each generated Version, so it needs a Script, from --script or the Project's default, and a runner. test runs Versions as a pass/fail check without using the measurements for scoring. skip runs nothing, and Versions are scored by the judge models alone, which are model judgements rather than measurements.

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

# 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 \
  --script <script-id> \
  --eval-mode until_stable --max-runs 20 \
  --runner my-runner --mode automatic

# Guided setup: create the run in setup, fill it in, then start it
artemis discovery create --project <project> --setup --task "Reduce p99 latency"

--model is required unless you use --setup, because 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. --eval-mode fixed repeats the benchmark --eval-runs times, and until_stable repeats it until the results settle, at most --max-runs times. --source-changeset starts the run from an existing Branch.

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 runner, script, review models or benchmark settings (more fields are editable during setup)
artemis discovery update <run-id> --runner other-runner
artemis discovery cancel <run-id>

Metrics and the Composite score

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 and sample count. It does not compute improvement against the baseline.

The CLI prints it as composite_score= in versions list and Composite Score in versions get. The API field is fitnessScore.

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

# Replace the run's metric schema and recompute each version's Composite score
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. Importance is a tier, high, medium, low or none, not a numeric weight:

[
  {"metricId": "<metric-uuid>", "source": "worker", "higherIsBetter": false, "importance": "high"},
  {"metricId": "<metric-uuid>", "source": "agent", "higherIsBetter": true, "importance": "low",
   "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.

Branches (changesets) and validation

A changeset is what the UI calls a Branch: the staged set of code changes that Discovery Runs, 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 Branches 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 Branch version's commands on a runner. It is the same step Discovery uses to evaluate every Version it generates, including the Baseline. The commands come from the Script named with --script, or from the Project's default Script if you leave it out. If the Project has no default Script, the command stops with an error. --version defaults to latest, the Branch's newest version, and --version original runs the code before the Branch changed anything.

Creating a Branch (changeset create) gives you exactly one version, the Project's current code, which makes it the standard way to check your Script works 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> --project <project>
artemis changeset validation logs <validation-id> --project <project>

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

# Publish and open a pull request. Without --title, the Branch's name is the title, as in the Web UI
artemis changeset pr <changeset-id> --project <project> --title "feat: add auth" --base develop

changeset pr works on any Branch regardless of where it came from, so the whole loop can be driven from the terminal. maintain issues pr is a convenience wrapper that resolves the Branch for you. changeset download and changeset save move a Branch's files to and from a local workspace, so your own agent can work on them.

Plans and chats

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"

# Answer the agent's question up front (--answer implies --wait)
artemis plan create --project <project> \
  --prompt "add unit tests for the user service" --answer 2

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 returns as soon as the plan is created. Add --wait to get the drafted plan, or the question the agent is waiting on, then 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 continue the conversation and chat messages to follow it. When the agent stops on a question card, answer it with chat answer. A reply sent with chat send doesn't answer the card, so the agent asks again. For a plan, use plan respond instead.

# 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>

# Answer the question card the agent is waiting on
artemis chat answer <chat-id>             # print the card (exits non-zero until answered)
artemis chat answer <chat-id> --answer 2  # question 1, choice 2
artemis chat answer <chat-id> --approve   # approve what it proposes
artemis chat answer <chat-id> --reject    # reject it

A chat answers questions and makes no code changes. A Plan breaks a feature into Tasks before any code is written.

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. Add rules: import the default rules you want, or write your own
artemis maintain rules defaults --all           # browse the platform catalogue
artemis maintain rules import-defaults --project <project> --rule <default-rule-id>
artemis maintain rules create --project <project> --markdown-file rule.md
artemis maintain chat --project <project> \
  -m "Create a rule that flags 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> \
  --focus "error handling in src/auth" --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 (archives it)
artemis maintain issues archive <issue-id>     # off the board without ruling on validity

# 4. Fix with Artemis's agent, or export a prompt for your own agent (Copy for local agent in the Web UI)
artemis maintain issues fix <issue-id-1> <issue-id-2>
artemis maintain issues prompt <issue-id> --project <project> | my-agent
# ...and send your agent's fix back to the Issue from your working tree
artemis maintain issues submit-local-fix <issue-id> --project <project>

# 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 has a display ID (ISS-143, RUL-7) as well as a UUID, and commands take either. A display ID is looked up within one project, so pass -p <project> with it (artemis maintain issues get ISS-143 -p my-service).

scans run --count is the approximate number of issues a scan raises. artemis maintain scans run --help shows its default and range, which match the Web UI's scan dialog. --no-limit removes the limit, like switching off Limit the number of issues in that dialog. As the dialog warns, a scan without a limit can use many tokens.

issues fix accepts several issue IDs at once: all the fixes land on one Branch, 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, --lane, --complexity, --rule and --path-prefix, and sorts with --sort and --order.

Rule authoring

rules create takes a markdown file that is the rule: its name and the sections describing what to scan for, how to fix it and what to check on review. The file is stored as written. To describe a rule in prose instead, ask the maintain agent with artemis maintain chat --project <project> -m "Create a rule that ...". It reads the project's code and writes the rule, which then shows in rules list.

rules update renames a rule (--name) or rewrites its definition from markdown (--markdown-file). A rewrite is re-processed, so the rule may show as [DRAFT] until that finishes; check rules list before scanning.

Maintain chat

artemis maintain chat holds a conversation with the maintain agent about a project's board. The agent reads both the board and the project's source, so you can look for a problem by describing it instead of 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 (leave out --branch to use the repository's default branch)
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>

# Scripts and a default runner
artemis project scripts create --project <project> --name "bench" \
  --setup-cmd "make" --benchmark-cmd "make bench" --default
artemis project scripts list --project <project>
artemis project runner set --project <project> --runner my-runner

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

Projects are created with auto-sync off, so Artemis doesn't update a project from its remote before it creates each Branch. To bring a project up to date, run artemis project pull <project>. It fetches the tracked branch and moves Artemis's copy of the repository to the new commit. The pull runs in the background, so wait until the project's gitHash (in artemis --output-format json project get <project>) shows the new commit before you create a Branch. Add --force to pull even when the copy already looks up to date. Agent work and pull requests don't need auto-sync.

Skills

artemis skills manages what your Artemis agents know before you ask them anything, the same as Platform Settings → Skills. Both parts are personal: they apply only to agents you run.

AGENTS.md is one document given to every agent. Conventions that always apply go here, and they cost tokens on every run.
Skills are named references agents read on demand. An agent sees only a skill's name and description up front and opens the body when it needs it.

# Conventions that always apply
artemis skills instructions set --body "We use conventional commits"

# Reference material agents open when they need it
artemis skills add --name deploy-runbook --description "How we ship" --body-file runbook.md

# Inspect and manage
artemis skills list --enabled
artemis skills get deploy-runbook
artemis skills usage      # upfront context size against the token budget
artemis skills delete <skill-id>

artemis context still works as an older name for artemis skills.

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 (for example claude-sonnet-5)
the catalogue ID (a UUID), which chat create needs

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 <entry-id>
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 the selected environment's file under ~/.config/artemis/. A ./.artemis.env in the current directory is merged over it as a project-local override, and a ./.env is never read. If one names a different deployment, commands stop until you delete it or rename it to .artemis.env; otherwise the CLI notes it once.

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 how Discovery explores and scores versions, see Discover.

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​

Projects and Branches​

Discover, Plan and Chat​

Maintain​

Resources​

Conventions​

Global flags​

Exit codes​

Typical Workflow​

Discovery​

Starting a run​

Following and steering a run​

Metrics and the Composite score​

Branches (changesets) and validation​

Validation​

Shipping​

Plans and chats​

Plans​

Chats​

Maintain​

Rule authoring​

Maintain chat​

Projects and Git Keys​

Supported Git providers​

Managing keys​

Importing and managing projects​

Skills​

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

Projects and Branches

Discover, Plan and Chat

Maintain

Resources

Conventions

Global flags

Exit codes

Typical Workflow

Discovery

Starting a run

Following and steering a run

Metrics and the Composite score

Branches (changesets) and validation

Validation

Shipping

Plans and chats

Plans

Chats

Maintain

Rule authoring

Maintain chat

Projects and Git Keys

Supported Git providers

Managing keys

Importing and managing projects

Skills

Models and providers

Provider connections

Background processes and platform logs

Interactive TUI

Configuration

Common commands

Environment variables

Getting Help