What is the WorkerKit CLI?
The WorkerKit CLI is the open-source wk command-line tool for managing and running an account's AI workers and browsing the kit directory from the terminal.
The dashboard is one way to run a worker fleet. This is the other: a binary called wk that puts the whole fleet in your terminal, your scripts and your CI, and reads the public kit directory without so much as an account.
It is open source under MIT, published as @workerkit/cli on npm and developed at github.com/workerkit/cli.
Installing it
npm install -g @workerkit/clior, on Homebrew:
brew install workerkit/tap/wkThe npm package needs Node.js 22 or newer; the Homebrew formula brings its own.
What it covers
| Commands | What they cover |
|---|---|
wk workers | The fleet: every worker with its live state, one worker in full, start and stop, what it may touch, its spend ceilings, and cloning it into new workers |
wk run, wk runs, wk fleet | Trigger a run with a prompt for that run, watch it step by step, read the receipt, cancel or grade it; answer a run that ended by asking a question; the account-wide run feed, everything in flight, and the fleet ceiling. On a decision-model worker wk run decides, acting on what it routes and returning the per-item decisions |
wk memory, wk instruction | The rules and facts a worker carries into every run, and its standing instruction, versioned on every change with the history to roll back to. On a decision-model worker wk instruction get reads the routing table with its install questions and wk instruction set --answers fills them |
wk schedules, wk deliveries | When a worker starts on its own, in its own time zone, and where its run report goes when it finishes |
wk kit, wk publisher | The public directory: search kits, read one in full, preview an install against your account, then install it as a new worker. And authoring: wk kit tools, wk kit guide and wk kit vocabulary say what a kit may grant, wk kit validate reports every gate at once, wk kit publish --private publishes one of your own, and wk publisher keeps your profile |
wk apps, wk model-keys, wk mcp-servers | Which apps your operator can use and connecting the rest by credential (from a file, stdin or a hidden prompt, never a flag in shell history); your own model-provider keys; and registering an MCP server as your own custom MCP app when the platform does not offer the app |
The directory commands are anonymous by design: wk kit search works before any sign-in, the same way the directory itself does, and so do wk kit tools, wk kit guide and wk kit vocabulary, so a kit can be drafted before any key exists. Publishing it privately and then wk kit install is how a worker is created from scratch: a kit's permissions go through the same validators as a directory listing, which is the platform's rule for permissions written by an agent.
Create a classifier from your questions
Run wk decision sources --app email and wk decision guide without signing in. Save the request example as decision.json, then run wk decision create --file decision.json, or pipe the JSON on stdin. Creation needs publishKits and installKits; optional deploy:true also needs manageDeployments. It creates a private kit and worker, never an initial run.
Recipes cover email previews, calendar events and Google Sheets rows. Reuse the same requestId with the identical body on retries. Use the returned tokenId with wk deploy, wk run and wk instruction to run and adjust the worker. A deploymentError leaves the worker available to deploy later. Read coverage, omissions and cost from the run receipt before claiming completion.
Signing in
wk auth login runs a browser-approved sign-in. The CLI prints a short code, an account admin enters it at workerkit.ai and chooses the key's scopes, and the key lands in your OS keychain. The key itself never appears in the browser, and the login link carries neither the code nor any secret.
The credential it creates is the same scoped access key the dashboard manages under /fleet-access: per account, revocable at any time, and granting no access to any connected app. Workers reach apps; the CLI manages workers.
Built for scripts and agents
--jsonprints a stable, machine-readable envelope, byte-faithful by contract, so a script can parse it without scraping human output.--plainstrips the formatting for logs and agent transcripts.- Exit codes are documented and distinguish auth, usage and server failures, so automation can branch on what actually went wrong.
- A
WK_MANAGER_KEYenvironment variable carries the key in CI without touching a stored profile.
That makes the CLI the terminal half of AI worker fleet orchestration: the same fleet an MCP client drives conversationally, driven from a shell instead.
One definition, shared with the MCP server
Every command is generated from the same open-source tool definitions the WorkerKit MCP server serves to AI agents, published as @workerkit/core. One definition per tool is what keeps the CLI, the MCP surface and the API from drifting apart: a capability added to the platform arrives in all three at once, behaving identically.
The CLI's product page is /cli, the packages live at /npm, and the whole developer surface is summarised at /developers.
FAQ
What is the WorkerKit CLI?
It is wk, an open-source command-line tool that manages and runs an account's AI workers (runs, schedules, memory, instructions, deliveries, budgets, cloning), connects their apps, authors and publishes kits, and browses the public kit directory from the terminal. It is MIT licensed and installs from npm or Homebrew.
How do I install the wk CLI?
Either npm install -g @workerkit/cli (Node.js 22 or newer) or brew install workerkit/tap/wk. Pick one channel and stay on it; both install the same wk binary.
Can I use the CLI without an account?
Yes, for the public directory: wk kit search, wk kit get and their siblings read the catalog anonymously. Managing a fleet needs a sign-in via wk auth login, approved in the browser by an account admin.
Is the WorkerKit CLI open source?
Yes. The CLI and the core library it is built on are MIT licensed at github.com/workerkit/cli and github.com/workerkit/core, and npm releases carry provenance attestations. The license covers the software; the hosted service has its own terms.
Is the CLI different from the WorkerKit MCP server?
Same tools, different consumer. The CLI binds the tool definitions to shell commands for people and scripts; the MCP server serves the same definitions to AI agents over the Model Context Protocol. Use whichever surface sits closer to where the work happens.