Skip to main content
The orchagent CLI lets you interact with the platform from your terminal.

Installation

The CLI also installs orch as a shorthand alias. All commands work with either orchagent or orch.

Understanding the Four Types

Before diving into commands, understand the four types on orchagent: Simple rule:
  • Want a single LLM answer? Use type: "prompt"
  • Want your code to execute? Use type: "tool"
  • Want the LLM to iterate with tools? Use type: "agent"
  • Want to share knowledge? Use type: "skill"

Quick Reference

When to Use What


Running Agents

run

Execute an agent. By default, agents run on the cloud (E2B sandbox). Use --local to download and run on your machine instead.
Options: What happens (cloud, default):
  1. CLI sends request to gateway (api.orchagent.io)
  2. Gateway spins up an E2B sandbox (ephemeral, isolated)
  3. Agent runs with your stored LLM keys
  4. Response returned through gateway
What happens (with --local):
  1. CLI downloads agent code from orchagent registry
  2. Agent runs locally on your machine
  3. Agent calls LLM API using YOUR environment keys
  4. Results returned to terminal
When to use --local:
  • Development and testing
  • Keep data on your machine (privacy)
  • Try agents without an account
  • Debug agent behavior
Requirements for --local:
  • LLM API key in environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.)
  • Agent must be downloadable (has source_url in manifest)
Dependency handling: If an agent has dependencies, the CLI prompts you to choose between server execution or downloading available dependencies. Use --with-deps to auto-download.

Agent Management

agents

List your published agents.
Options: By default, shows only the latest version of each agent grouped by name. Displays a table with columns: Agent, Version, Type, Description. When in latest-only mode, the version column shows the count (e.g., v3 (5 total)). Respects workspace context.

info

Show agent details including schemas, dependencies, and configuration.
Options: Displays: type, callable status, supported providers, server URL (for tool types), source URL, run command, local-ready status, input/output schemas, dependencies, skills, custom tools, and environment pinning. For GitHub-linked agents, fetches and displays the repository README.

tree

Show the dependency tree for an agent, including skills and nested sub-agents.
Options: Renders an ASCII tree showing the agent, its skills (tagged with (skill)), and nested dependency agents. Inaccessible nodes are dimmed. Locked skills show a lock icon. Summary line shows total agents, total skills, and max depth.

transfer

Transfer an agent to another workspace. Moves all versions, revokes existing grants, and disables schedules.
Options: The pre-transfer check shows: version count, grants to revoke, keys to delete, schedules to disable, warnings, and blockers. In interactive mode, you must type the agent name to confirm.

Installing Agents as Sub-Agents

install

Export an agent as a sub-agent for AI coding tools (Claude Code, Cursor, etc.). This writes configuration files that your AI tool reads — not the agent’s source code.
installpull. orch install writes a single IDE config file (e.g. .claude/agents/my-agent.md). It does not write orchagent.json, prompt.md, schema.json, or code bundles. If you want the agent’s source files, use orch pull instead. See the FAQ for a full comparison.
What happens:
  1. CLI downloads agent metadata from registry
  2. Converts to target format (Claude Code, Cursor, AGENTS.md)
  3. Writes configuration file to AI tool directory
  4. Tracks installation for updates
Install locations by format: When to use install:
  • You want Claude Code or Cursor to delegate tasks to specialized agents
  • You want sub-agents available across all your projects
  • You’re building a team workflow with shared agents
Set default format: Run orch config set default-format claude-code,cursor to install to multiple formats automatically.

update

Update installed agents to their latest versions.
What happens:
  1. CLI reads ~/.orchagent/installed.json to find installed agents
  2. Checks registry for newer versions
  3. Downloads and writes updated files
  4. Preserves local modifications (unless --force)
If you’ve manually edited an installed agent file, orch update will skip it to preserve your changes. Use --force to overwrite.

formats

List available export formats for agents.
Example output:

list

List locally installed agents and skills.
Options: Also available as orch ls.

Working with Skills

Skills are passive knowledge files that enhance AI tools. Install them locally to give your AI assistant domain expertise.

skill install

Install a skill to your local AI tool directories.
Options: Install locations (current directory):
Install locations (with --global):

Using Skills with Agents

When running orchagent agents, you can compose skills:

Authentication

login

Authenticate and store your API key.
The --key flag exposes the key in shell history. For CI/CD, use the ORCHAGENT_API_KEY environment variable instead.

logout

Log out of orchagent. Revokes the API key server-side and clears local credentials.
Preserves user preferences (default formats, scope) while clearing authentication fields. If the ORCHAGENT_API_KEY environment variable is set, a warning is printed since the env var will continue to authenticate requests.

whoami

Show current user and organization info.

Workspaces

Workspaces let you organize agents by team, share agents privately, and manage billing.

How Workspaces Affect Commands

When you set an active workspace, CLI commands will look for agents there by default:
Resolution order: Explicit org/agent → Active workspace → Default org (from login)

workspace list

workspace create

workspace use

Set the active workspace for agent lookups.
After this, orch run agent will look for my-team/agent.

workspace members

workspace invite

workspace leave


Agent Development

init

Initialize a new agent or skill project.
Options: When a name is provided, init creates a subdirectory with that name and writes all files there. Without a name, files are written to the current directory. The generated orchagent.json uses the specified type (defaulting to "prompt") with the canonical run_mode field.
--language javascript is supported for tool types. agent types (managed loop) currently require Python — the managed loop runner is Python-only.

scaffold orchestration

Generate a managed-loop orchestrator scaffold from existing dependency agents.
What it generates:
  • orchagent.json with:
    • manifest.dependencies pinned to concrete versions
    • custom_tools commands wired to orch_call.py
    • managed-loop defaults (max_turns, provider + orchestration settings)
  • prompt.md starter prompt with dependency tool catalog
  • schema.json starter input/output schema
Validation behavior:
  • Resolves each dependency ref and pins latest to a concrete version
  • Rejects dependencies that are skills or callable: false
  • Detects conflicting versions for the same dependency
  • Deduplicates repeated dependency refs
Use this command when you already have worker agents and want a ready-to-publish orchestrator quickly.

publish

Publish an agent or skill from the current directory.
The publish command validates the type field, infers the execution_engine from the type (with optional runtime/loop overrides), and validates all fields. The dry-run output shows: Type, Run mode, Execution engine, Callable, Providers, and Visibility. The --all flag scans immediate subdirectories for orchagent.json or SKILL.md files, builds a dependency graph from manifest.dependencies and custom_tools references, and publishes in topological order (leaf-first). If any agent fails to publish, the batch stops to prevent publishing agents whose dependencies are missing.

pull

Reconstruct a local agent project from a published version. This is the reverse of orch publish — it downloads the full agent source and reconstructs orchagent.json, prompt.md, schema.json, and code bundle files into a local directory.
pull gives you source files. install gives you IDE config. Use pull when you want to edit and republish an agent. Use install when you just want your AI tool to delegate to it. See the FAQ.
Options: What happens:
  1. CLI resolves the agent from the public registry (or falls back to authenticated owner/private lookup)
  2. Reconstructs orchagent.json manifest with canonical fields
  3. Writes prompt.md if the agent has a prompt (direct LLM and managed loop engines)
  4. Writes schema.json if input or output schemas exist
  5. For code runtime agents, downloads and extracts the code bundle
  6. Prints a summary of written files
Agent resolution: The CLI resolves agent refs using the same fallback logic as run:
  1. Tries the public download endpoint first
  2. If the agent is server-only (403) and you’re the owner, falls back to authenticated access
  3. If the agent is private (404) and you’re authenticated, resolves from your own agents
When to use:
  • Reconstruct a local project from a published agent (e.g., lost source, new machine)
  • Review the contents of a published agent version
  • Set up a local development environment from a deployed agent
Requirements:
  • No login required for public, source-available agents
  • Login required for private agents or server-only agents you own
pull is for agents only. If the target is a skill, you’ll be directed to use orch skill install instead.

delete

Delete an agent or skill you own. By default, deletes the latest version only. Requires the full org/agent reference. Use the @version syntax to delete a specific version.
Options: Deleted data is retained for 30 days before permanent removal.

fork

Fork a public, source-available agent into your workspace. This creates a private copy you can customize and deploy independently.
Options: What happens:
  1. CLI resolves the source agent from the public registry
  2. If --workspace is specified, resolves and verifies workspace membership
  3. Creates a private copy in the target workspace via POST /agents/{id}/fork
  4. Returns the new agent reference and a service key (if the agent has dependencies)
What gets copied: The fork copies everything needed to customize and deploy: name, description, tags, type, prompt, schemas, manifest, code bundle, default skills, supported providers, default models, timeout, and execution config. The forked agent resets to private (is_public = false) and records a forked_from link to the source. Not copied: run history, deploy state, schedules, stats, or services. When to use:
  • Start from a template instead of building from scratch
  • Customize an existing public agent for your team
  • Copy an agent into a different workspace
Requirements:
  • Must be logged in (orch login)
  • Source agent must be public and source-available (allow_local_download = true)
  • --workspace requires browser-auth login (orch login without --key) so workspace membership can be verified
If a name collision occurs in the target workspace, the server auto-increments the version number.

test

Run tests for your agent locally. Supports Python (pytest), JavaScript/TypeScript (vitest/npm test), and fixture-based testing for direct LLM agents.
Options: Test Discovery: The CLI automatically discovers tests based on file patterns: Fixture Format: For prompt and skill agents, create fixture files in tests/ to test your prompts against an LLM:
*At least one of expected_output or expected_contains is required. Requirements for fixture tests:
  • LLM API key in environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.)
  • A prompt.md or SKILL.md file in the agent directory
Mocked Orchestration Tests: For managed-loop orchestrator agents (type agent with custom_tools), add a mocks field to test the full agent loop with deterministic sub-agent responses — no live sub-agents needed:
The mocks field maps custom tool names to their mock responses. When the LLM calls a mocked tool during the agent loop, it receives the mock response instantly instead of executing the real sub-agent command. Built-in tools (bash, read_file, etc.) always execute normally. *At least one of expected_output or expected_contains is required.
Mocked orchestration tests are ideal for CI — they test the full LLM reasoning loop (tool selection, multi-turn reasoning, result aggregation) without requiring deployed sub-agents or network access to the gateway.
Watch mode works on all platforms (macOS, Linux, Windows) and automatically picks up new test files as you create them.

dev

Start a local HTTP development server with hot-reload. The server accepts JSON input via HTTP and runs your agent locally, reloading automatically when files change.
Options: Endpoints: Example:
How it works:
  1. Reads orchagent.json from the agent directory
  2. Starts an HTTP server on the specified port
  3. Watches for file changes (orchagent.json, prompt.md, schema.json, source files)
  4. On each POST request, executes the agent locally and returns the JSON result
  5. On file change, reloads the agent configuration automatically
The dev server supports all three execution engines: Requirements:
  • orchagent.json in the target directory
  • For LLM-based agents: API key in environment or .env file
  • For code runtime agents: Python 3 or Node.js installed
The dev server enables CORS, so you can send requests from browser-based tools or frontend apps during development.
Use orch dev alongside orch test --watch for a full development loop: the dev server handles HTTP requests while test watch validates on every save.

estimate

Show estimated cost for running an agent, based on historical run data from the last 30 days.
Options: Output includes:
  • Cost stats — Average, median (p50), and 95th percentile cost per run
  • Token averages — Average input and output tokens per run
  • Duration — Average execution time
  • Success rate — Percentage of runs that completed successfully
  • Provider breakdown — Per-provider cost averages (e.g., Anthropic vs OpenAI)
Example output:
You can also use --estimate on the run command to see the estimate before executing:
This shows the cost estimate and prompts for confirmation before proceeding.
If the agent has never been run before, the estimate will show “No run history available.” Run the agent once and the estimate will populate from subsequent runs.

diff

Compare two versions of an agent side-by-side. Shows changes in type, description, schemas, providers, dependencies, skills, custom tools, prompt, and configuration fields.
Options: Output format: Changes are shown with prefixes indicating the type of change:
  • + — field was added
  • - — field was removed
  • ~ — field was changed (shows old and new values)
Schema and prompt changes show field-level diffs with added/removed lines. Version shorthand: The second argument can be just a version string (e.g., v2) — the org and agent name are inherited from the first argument. If the second argument is omitted, the first version is compared against latest.

Secrets & Keys

secrets

Manage workspace secrets. Secrets are injected as environment variables into agent sandboxes and always-on services.
Subcommands: Options for list: Options for set: Options for delete: Secret names must start with an uppercase letter, contain only uppercase letters, digits, and underscores, and be 1-128 characters (e.g., STRIPE_SECRET_KEY, DISCORD_TOKEN).
When you update a secret that is used by running always-on services, those services are automatically restarted.

agent-keys

Manage agent service keys for programmatic access to your agents.
Subcommands: The list output shows: ID, PREFIX, CREATED, LAST USED, and whether the key is SAVED locally (~/.orchagent/keys/).
Service keys are shown only once at creation time. The CLI saves them to ~/.orchagent/keys/ automatically, but if that fails, copy the key immediately — it cannot be retrieved later.

Custom Environments

Manage custom Docker environments for tool-type agents. See the Custom Environments guide for details.

env

Subcommands: Options for list: Options for status: Options for create: Options for set-default / clear-default: The list output shows: Name, Status, Agents, Type, ID. Status is color-coded: green (ready), yellow (building), red (failed), gray (pending). The default environment is marked with (default).

GitHub Integration

github

Connect your GitHub account and import agents directly from repositories.
Subcommands: Options for scan: Options for import: Options for sync-config:
When importing from a repo with multiple agents, omit --path to scan first. If only one item is found, it imports automatically. If multiple are found, you’ll get an interactive selection prompt.

Execution Logs

logs

View execution logs. Use with no arguments to list recent runs, an agent name to filter, or a run ID for full detail.
Options: Modes:

Security

security test

Run a dynamic vulnerability scan against a deployed agent. Tests for prompt injection, persona roleplay, logic traps, and other attack categories.
Options: Summary output includes: risk level banner, attacks tested, vulnerabilities found, breakdown by severity and category, and top 5 issues.

Debugging

replay

Re-execute a previous run using the original input and configuration captured in its snapshot. Useful for reproducing bugs, testing fixes with policy overrides, or retrying failed runs.
Options: What happens:
  1. CLI resolves the run ID (supports short prefix matching)
  2. Submits a replay request — the gateway re-executes using the original snapshot (input data, execution config, agent version)
  3. By default, polls for completion and displays the result (agent name, version, status, output, stdout/stderr, duration)
  4. With --no-wait, returns immediately with the new run ID and job ID
Example output:
After a replay completes, use orch trace on the new run ID to inspect the full execution timeline — LLM calls, tool calls, token usage, and cost breakdown.

trace

View the execution trace for a run. Shows a timeline of LLM calls, tool calls, decisions, fallbacks, policy violations, and errors — with token counts, costs, and durations.
Options: Event types shown: Example output:
Use orch replay to re-execute a run, then orch trace on the new run to compare execution traces side-by-side.

metrics

Show agent performance metrics for a workspace — success rates, latency percentiles, error rates, and per-agent breakdown.
Options: Output includes:
  • Overview — Total runs, success rate, error rate (failed + timeout), p50/p95/avg latency, runs per day
  • Per-agent table — Each agent’s run count, success rate, latency percentiles, error count, and top error message
Example output:
The same metrics are available on the web dashboard at orchagent.io/metrics with interactive charts for run activity, latency trends, and success rate over time.

dag

Visualize the orchestration call graph (DAG) for a run. Shows all agents in the chain as an ASCII tree with real-time status, cost, duration, and trace summaries per node.
Options: Example output:
What it shows per node:
  • Status icon ( completed, failed, running, queued)
  • Agent name and version
  • Status, duration, self cost, LLM model
  • Trace summary: LLM call count, tool call count, error count, total tokens
Live mode clears the screen and re-renders the full DAG on each poll until the execution completes. Press Ctrl+C to stop. The same DAG visualization is available on the web dashboard’s run detail page, rendered as an interactive graph with SVG edges and clickable nodes.
Use orch dag during multi-agent orchestration runs to monitor which agents are active, see cost distribution across the chain, and quickly identify failed nodes.

Configuration

config

Manage CLI configuration.

Config File

The CLI stores configuration at ~/.orchagent/config.json:
Agent resolution: When you run orch run agent, the CLI looks for the agent in this order:
  1. Explicit org if provided (org/agent)
  2. Active workspace if set
  3. default_org (your personal workspace)

Environment Variables

Resolution order: Command-line flags > Environment variables > Config file > Defaults

Diagnostics

doctor

Diagnose CLI setup issues.
Checks performed:
  • Environment (Node.js, CLI version, Git)
  • Configuration (config file, permissions)
  • Connectivity (gateway reachable, latency)
  • Authentication (API key valid)
  • LLM Configuration (keys configured)

health

Smoke test an agent by running a minimal cloud execution. Useful for verifying an agent is deployed, reachable, and responding correctly.
Options: What happens:
  1. CLI resolves the agent (public or private)
  2. Auto-generates minimal input from the agent’s input_schema (fills required fields with sample values)
  3. Fires a real POST to the agent’s cloud endpoint
  4. Reports pass/fail with latency and run ID
Example output:
JSON output:
Use orch health in CI/CD pipelines after deploying a new agent version to verify it’s working. The --json flag and exit code (0 = pass, 1 = fail) make it easy to integrate with any CI system.

status

Check orchagent platform service status.
Options: Displays overall platform status (All Systems Operational / Partial Outage / Service Outage) and per-service status with latency. Also verifies actual API connectivity and warns if the status page and API disagree.

docs

Open orchagent documentation in your browser.
Topics:

completion

Generate shell completion scripts for tab-completion of commands, subcommands, and flags.
Setup:
Persistent install (alternative):

Scheduling

Automate agent execution with cron schedules or webhooks. See the full Scheduling & Webhooks guide for detailed usage and examples.

schedule list

List schedules in your workspace.
Options:

schedule create

Create a cron or webhook schedule for an agent.
Options:
Webhook URLs contain a secret token and are shown only once at creation time. Save the URL immediately.

schedule update

Update an existing schedule.
Options:

schedule delete

Delete a schedule permanently.

schedule trigger

Manually trigger a schedule execution (useful for testing).

schedule info

View schedule details and recent events.
Shows schedule configuration, recent run history, and event timeline.

schedule runs

View run history for a schedule.

Services

Deploy agents as always-on services for long-running workloads like Discord bots, webhook listeners, or background workers. See the full Services guide for detailed usage and examples.

service deploy

Deploy an agent as an always-on service.
Options:
Only agents with a runtime.command or loop config (i.e., code runtime or managed loop agents) are eligible for service deployment. Direct LLM agents cannot be deployed as services. Sensitive environment variables (e.g., API keys, tokens) are rejected by --env and must be passed using --secret instead.

service list

List services in your workspace.
Options:

service info

Get service details and events.
Options:

service logs

View service logs.
Options:
Sensitive values in log output are automatically redacted.

service restart

Restart a service.
Options:

service delete

Delete a service.
Options:

service env set

Set or update environment variables on a deployed service. Merges with existing variables. Triggers a restart if the service is running.
Options:

service env unset

Remove environment variables from a service. Triggers a restart if the service is running.
Options:

service env list

List current environment variables on a service.
Output:
Options:

service secret add

Attach workspace secrets to a service. Secrets are injected as environment variables at runtime. Triggers a restart if the service is running.
Options:

service secret remove

Detach workspace secrets from a service. Triggers a restart if the service is running.
Options:

Billing

billing

Open the Stripe billing portal in your browser to manage your subscription, payment methods, and invoices.
The command opens your billing portal URL directly. If the browser doesn’t open automatically, the URL is printed to stdout so you can copy it.

Exit Codes


Scripting Examples