ant (anthropic-cli): the Claude API in a terminal, and agents as reviewable files

The problem ant solves: API calls that belong in a script, not a notebook

The Claude API is an HTTP API. Calling it from a shell script usually means curl, a JSON string built by hand, a key exported somewhere, and output piped into jq. That works until you need to page through a list, upload a file, or read one field out of a nested response.

ant is the official CLI for the Claude Platform, written in Go. The README states that it "puts the Claude API in your terminal", covering messages, agents, sessions and file uploads, and that you can "script against every API endpoint". Its audience is therefore engineers who already treat the API as infrastructure: CI jobs that call a model, release scripts that summarize a diff, internal tools where a Python SDK would be more ceremony than the task deserves.

The command grammar is resource-based, with nested resources separated by colons: ant <resource>[:<subresource>] <command> [flags...]. So ant models list and ant beta:agents list are the same shape, and a new resource does not require a new mental model. That consistency is the main reason to prefer it over ad hoc curl wrappers.

How ant is put together: Go, urfave/cli, and a Bubble Tea explorer

The repository layout is a normal Go project: cmd/ holds the entry point, internal/ and pkg/ hold the implementation, and go.mod pins the dependencies. The module is github.com/anthropics/anthropic-cli, and the installable command lives at cmd/ant.

The dependency list tells you what kind of program this is. It requires github.com/anthropics/anthropic-sdk-go v1.72.0, so the CLI is a thin command layer over the official Go SDK rather than a separate HTTP implementation. Command parsing and help generation come from github.com/urfave/cli/v3 and github.com/urfave/cli-docs/v3. The interactive parts come from Charm: bubbletea, bubbles, lipgloss and termenv. JSON handling is split across tidwall/gjson, sjson and pretty, with goccy/go-yaml and itchyny/json2yaml for YAML. There is also a pty dependency, which fits the interactive explorer.

That mix explains two behaviours the README documents. Structured flags accept "relaxed JSON or YAML, so unquoted keys are fine", which is the YAML parser doing the work. And in a terminal, ant models retrieve --model-id claude-opus-4-8 opens an interactive explorer by default, which is the Bubble Tea stack. The same command in a pipe produces plain output, so the explorer is a terminal-only affordance rather than something scripts have to opt out of.

Installing ant and sending a first message

Two install paths are documented. Homebrew is the short one:

brew install anthropics/tap/ant

Installing from source requires Go 1.22 or later according to the README, though go.mod declares go 1.25, so the module itself expects the newer toolchain:

go install 'github.com/anthropics/anthropic-cli/cmd/ant@latest'

The binary lands in $(go env GOPATH)/bin. If the shell cannot find ant afterwards, the README suggests adding that directory to PATH in your shell profile.

Authentication has two routes. ant auth login uses a Claude Console account. The alternative is the ANTHROPIC_API_KEY environment variable, set to a key from the Claude Console. For secrets managers, the README shows piping a key on stdin so it never reaches the environment or the command line:

op read op://vault/anthropic/api-key | ant --api-key-stdin models list

Note the deprecation: passing --api-key <value> or --auth-token <value> directly is documented as deprecated because the value is visible in shell history and process listings. Use stdin or the environment variable.

A first real call looks like this. The --message flag takes an object, and relaxed JSON means the keys do not need quotes:

ant messages create \
  --model claude-opus-4-8 \
  --max-tokens 1024 \
  --message '{role: user, content: "Hello, Claude"}'

To pull one field out of the response, the README gives a jq-style transform. The path is positional, and --raw-output drops the JSON quoting:

ant messages create \
  --model claude-opus-4-8 \
  --max-tokens 1024 \
  --message '{role: user, content: "Hello, Claude"}' \
  --transform content.0.text --raw-output

Files are attached with @path syntax inside the message object, for example data: "@photo.jpg" for a base64 image source. Run ant --help for the resource list, or append --help to any command.

ant apply: agents, skills and deployments as files in a repository

The most opinionated part of the CLI is ant apply. It keeps agents, skills, environments, memory stores and deployments in step with files in your repository, so changes to them go through review like any other code. Files reference each other by path rather than by ID.

The directory a file sits in decides its resource kind, and a skill is any directory containing a SKILL.md. A .yml file holds the API request body as-is. A .md file puts the request body in its frontmatter, and the markdown text becomes the agent's system prompt (for a deployment, its first user message; for an environment, its description). Wherever the API expects another resource's ID, you write the path to that file instead. A glob works, and anything that is not a path is sent to the API unchanged, which is how a built-in skill like {type: anthropic, skill_id: xlsx} passes through.

Apply records which remote object each file became in claude-lock.json, and the README says to commit it so teammates and CI update the same resources instead of creating their own copies. The lock file carries two hashes per resource: hash fingerprints what was last sent, so a changed file is noticed, and remote_hash fingerprints what the server held afterwards, so an edit made in the Console is noticed too. That second hash is the interesting design choice. The README states plainly that edits made in the Console are not silently overwritten.

Before changing anything, apply prints a plan and prompts. Pressing d at the prompt shows each change field by field, and --dry-run prints the plan without applying it:

$ ant apply ./agents ./deployments ./environments ./skills
Preview  ./claude-lock.json

± Name                       Plan
+ ./skills/pr-writer         create
~ ./agents/code-verifier.md  update     [~system]
~ ./agents/code-reviewer.md  update     [~multiagent]

Resources  + 1 to create · ~ 2 to update · 2 unchanged

Apply these changes? (y)es / (n)o / (d)etails

Two behaviours are worth internalizing. References record a specific version: a coordinator stores its sub-agent's ID and version, so when code-verifier.md changes, code-reviewer.md is updated in the same run to point at the new version. And a skill referenced by GitHub URL keeps using the commit it resolved to on first apply, even after the branch moves on; --upgrade picks up the branch's latest commit. That is a reproducibility default, not a bug, but it means a stale skill will not announce itself.

Where ant is the wrong tool, and what it does not do

The README is silent on rollback. There is no documented command for reverting a resource to a previous version, and no documented way to undo an apply that created the wrong object. The lock file records IDs and hashes, which is the raw material a rollback would need, but the CLI as documented does not expose one. If your workflow requires a one-command revert, plan for it yourself.

ant is also not Claude Code. People search for the two together, but they are different products: Claude Code is a coding assistant that works in your repository, while ant is a client for the platform API. Installing ant will not give you an interactive pair programmer.

The apply model assumes a repository and a review process. For a single agent you tweak occasionally in the Console, writing frontmatter, committing a lock file and running a plan prompt is more process than the task needs. The same applies if you only ever send messages: ant messages create is convenient, but the Go or Python SDK gives you typed request and response objects that a shell string cannot.

Finally, the README does not document Windows support. Installation is described through Homebrew and go install, and the interactive explorer depends on terminal capabilities exposed by termenv and Bubble Tea. Whether ant behaves the same in PowerShell or Windows Terminal is not stated, so treat it as unverified rather than supported.

ant versus the Anthropic SDKs: two ways to call the same API

The real alternative is not another CLI. It is the official SDK for your language, in this repository's case github.com/anthropics/anthropic-sdk-go, which ant already depends on.

The difference is where the structure lives. With an SDK, request and response shapes are types in your program, and a compiler or type checker catches a misspelled field before the call. With ant, structure lives in strings and flags: --message '{role: user, content: "Hello, Claude"}' is parsed at runtime, and relaxed JSON means a typo may fail later than you would like. In exchange, ant needs no build step, no dependency file, and no language runtime beyond the binary. A one-line cron job or a Makefile target is genuinely shorter with ant.

The second difference is scope. An SDK covers the API surface for one language. ant covers the API surface as commands, plus two things an SDK does not: the interactive explorer for browsing responses in a terminal, and ant apply with its lock file for keeping repository files and remote resources in sync. If you are building an application, use the SDK. If you are wiring the API into shell automation, or you want agent definitions reviewed like code, ant is the shorter path.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent and versioned: v1.32.0 on 2026-09-10, v1.31.0 on 2026-09-04, v1.30.0 on 2026-09-03. The repository carries release-please configuration and a .goreleaser.yml, so versioning and binary builds are automated rather than manual. A CHANGELOG.md and SECURITY.md are present at the top level, which gives you a place to read what changed between versions and where to report a vulnerability.

The licence is MIT. In practice that means you can use, modify and redistribute the CLI, including inside a company, provided the copyright notice and licence text travel with it. It says nothing about the Claude API itself: your use of the API is governed by Anthropic's terms and your Console account, not by this repository's licence. This is a description of the licence text, not legal advice.

Upgrade cost is low by design. Homebrew upgrades and go install @latest both fetch the newest release, and the command grammar is resource-based, so a new endpoint appears as a new subcommand rather than a change to existing ones. The one place to watch is the lock file format: it carries a "version": 1 field, which is the kind of marker that changes when the schema changes. Read CHANGELOG.md before upgrading if your repository contains a claude-lock.json you cannot easily regenerate.

Editorial conclusion

Adopt ant if you already script the Claude API from shell, or if you want agent definitions, skills, environments and deployments to live in a repository and change through pull requests. Skip it if you want a conversational coding assistant in your editor: that is Claude Code, a different tool, and the README treats this one as an API client. Before committing to ant apply, verify two things in the documentation: how a conflict between an edit made in the Console and a local file is resolved, and whether the lock file's recorded resource IDs can be moved between workspaces. The repository is not archived and the last push was on 2026-09-10.

Frequently asked questions

Official sources

1. anthropics/anthropic-cli on GitHub
2. License: MIT
3. Project website
4. README
5. Releases