Installation
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.
What happens (cloud, default):
- CLI sends request to gateway (
api.orchagent.io) - Gateway spins up an E2B sandbox (ephemeral, isolated)
- Agent runs with your stored LLM keys
- Response returned through gateway
--local):
- CLI downloads agent code from orchagent registry
- Agent runs locally on your machine
- Agent calls LLM API using YOUR environment keys
- Results returned to terminal
--local:
- Development and testing
- Keep data on your machine (privacy)
- Try agents without an account
- Debug agent behavior
--local:
- LLM API key in environment (
OPENAI_API_KEY,ANTHROPIC_API_KEY, etc.) - Agent must be downloadable (has
source_urlin 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.
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.
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.
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.
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.- CLI downloads agent metadata from registry
- Converts to target format (Claude Code, Cursor, AGENTS.md)
- Writes configuration file to AI tool directory
- Tracks installation for updates
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
update
Update installed agents to their latest versions.- CLI reads
~/.orchagent/installed.jsonto find installed agents - Checks registry for newer versions
- Downloads and writes updated files
- 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.list
List locally installed agents and skills.
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.
Install locations (current directory):
--global):
Using Skills with Agents
When running orchagent agents, you can compose skills:Authentication
login
Authenticate and store your API key.logout
Log out of orchagent. Revokes the API key server-side and clears local credentials.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:org/agent → Active workspace → Default org (from login)
workspace list
workspace create
workspace use
Set the active workspace for agent lookups.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.
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.orchagent.jsonwith:manifest.dependenciespinned to concrete versionscustom_toolscommands wired toorch_call.py- managed-loop defaults (
max_turns, provider + orchestration settings)
prompt.mdstarter prompt with dependency tool catalogschema.jsonstarter input/output schema
- Resolves each dependency ref and pins
latestto a concrete version - Rejects dependencies that are skills or
callable: false - Detects conflicting versions for the same dependency
- Deduplicates repeated dependency refs
publish
Publish an agent or skill from the current directory.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 oforch publish — it downloads the full agent source and reconstructs orchagent.json, prompt.md, schema.json, and code bundle files into a local directory.
What happens:
- CLI resolves the agent from the public registry (or falls back to authenticated owner/private lookup)
- Reconstructs
orchagent.jsonmanifest with canonical fields - Writes
prompt.mdif the agent has a prompt (direct LLM and managed loop engines) - Writes
schema.jsonif input or output schemas exist - For code runtime agents, downloads and extracts the code bundle
- Prints a summary of written files
run:
- Tries the public download endpoint first
- If the agent is server-only (403) and you’re the owner, falls back to authenticated access
- If the agent is private (404) and you’re authenticated, resolves from your own agents
- 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
- 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 fullorg/agent reference. Use the @version syntax to delete a specific version.
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.
What happens:
- CLI resolves the source agent from the public registry
- If
--workspaceis specified, resolves and verifies workspace membership - Creates a private copy in the target workspace via
POST /agents/{id}/fork - Returns the new agent reference and a service key (if the agent has dependencies)
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
- Must be logged in (
orch login) - Source agent must be public and source-available (
allow_local_download = true) --workspacerequires browser-auth login (orch loginwithout--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.
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.mdorSKILL.mdfile in the agent directory
agent with custom_tools), add a mocks field to test the full agent loop with deterministic sub-agent responses — no live sub-agents needed:
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.
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.
Endpoints:
Example:
- Reads
orchagent.jsonfrom the agent directory - Starts an HTTP server on the specified port
- Watches for file changes (orchagent.json, prompt.md, schema.json, source files)
- On each POST request, executes the agent locally and returns the JSON result
- On file change, reloads the agent configuration automatically
Requirements:
orchagent.jsonin the target directory- For LLM-based agents: API key in environment or
.envfile - For code runtime agents: Python 3 or Node.js installed
estimate
Show estimated cost for running an agent, based on historical run data from the last 30 days.
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)
--estimate on the run command to see the estimate before executing:
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.
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)
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.
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.
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
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.
Options for
scan:
Options for
import:
Options for
sync-config:
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.
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.
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.
What happens:
- CLI resolves the run ID (supports short prefix matching)
- Submits a replay request — the gateway re-executes using the original snapshot (input data, execution config, agent version)
- By default, polls for completion and displays the result (agent name, version, status, output, stdout/stderr, duration)
- With
--no-wait, returns immediately with the new run ID and job ID
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.
Event types shown:
Example output:
metrics
Show agent performance metrics for a workspace — success rates, latency percentiles, error rates, and per-agent breakdown.
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
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.
Example output:
- 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
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.
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:
- Explicit org if provided (
org/agent) - Active
workspaceif set default_org(your personal workspace)
Environment Variables
Resolution order: Command-line flags > Environment variables > Config file > Defaults
Diagnostics
doctor
Diagnose CLI setup issues.- 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.
What happens:
- CLI resolves the agent (public or private)
- Auto-generates minimal input from the agent’s
input_schema(fills required fields with sample values) - Fires a real POST to the agent’s cloud endpoint
- Reports pass/fail with latency and run ID
status
Check orchagent platform service status.
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.completion
Generate shell completion scripts for tab-completion of commands, subcommands, and flags.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.schedule create
Create a cron or webhook schedule for an agent.Webhook URLs contain a secret token and are shown only once at creation time. Save the URL immediately.
schedule update
Update an existing schedule.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.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.service info
Get service details and events.service logs
View service logs.Sensitive values in log output are automatically redacted.