From claude -p · async workers

Run Claude interactively.
Feed it a queue.

Most automation that uses claude -p doesn't need your script to block. Run a standing interactive Claude Code session, and send it work — async, non-blocking, observable. Same prompt, different delivery.

your-shell — claude -p
sync · headless
$ claude -p "refactor the auth module" # you wait...BLOCKED agent working # 3m 42s laterdone. output printed inline. $
script paused for 3m 42sheadless · one-shot
your-shell — oacp send
Claude Code · interactive
$ oacp send my-project --to claude \ --type task_request --subject "refactor auth" → msg_8f3a · claude/inbox RETURNED in 80ms · you continue # meanwhile, in the standing Claude Code session: ● picked up: refactor auth ● running… (you can watch & steer)$
your script moves onruns in interactive mode
Set it up ↓Why this works
~5 min one-time setup
0 servers
1 command per task
no server · no daemon · just files
The shape

Sync-and-headless was always a compromise.

You wanted to script an agent. claude -p was the way. The synchronous, headless, one-shot shape came along for the ride. There's another shape.

The wrong shape

claude -p "do X"

⤓
Blocks. Your script waits for the agent to finish.
sync
◐
Headless. No session to glance at, attach to, or steer mid-run.
opaque
1
One-shot. One prompt in, one result out — no queue behind it, and coordinating several calls is your script's problem.
one-shot
The other shape

oacp send → standing session

⤴
Async. Your script moves on in milliseconds.
non-blocking
◉
Interactive. A real session you can watch, attach to, and steer.
visible
✓
A queue behind it. Tasks are messages — review loops, handoffs, multi-agent coordination come with the shape.
coordination
The swap

Same prompt. Different delivery.

The text you'd have handed to claude -p becomes the message --body. oacp send drops it in the standing session's inbox, and the session picks it up and runs it.

Before
your script · claude -p
bash
    

        01
        # synchronous · headless · one-shot
      

        02
        $ claude -p "do X"
      

        03
        
      

        04
        # script blocks here until the agent returns
      

        05
        # output is printed to stdout, no session to attach to
→
After
your script · oacp send
bash
    

        01
        # async · interactive · a session you can watch
      

        02
        $ oacp send my-project --from sender --to claude \
      

        03
               --type task_request --subject "do X" \
      

        04
               --body "...details..."
      

        05
        
      

        06
          → msg_a8f1c2 · claude/inbox · returned in 80ms
also — once tasks are messages in an inbox, you get real multi-agent coordination for free: review loops, handoffs, several agents on one project — instead of a pile of blocking shell calls.
Your options, honestly

Two real choices.

We'd rather tell you when OACP isn't the right answer than oversell it. Pick on the trade-off, not on hype.

01

Keep claude -p

Simplest. It's one line, it works, and nothing about your setup changes. If your automation is a single blocking call and you never need to see inside it, this is fine.

+Zero workflow change. Your scripts and CI stay identical.
+No new tooling. Nothing to install, learn, or keep running.
−Still sync & headless. Same blocking shape, no coordination.
−One-shot. No queue behind it — several calls are your script's problem.
Best when: automation is a single blocking call you never need to watch.
02

OACP — interactive + a queue

recommended for fleets

Run a real interactive Claude Code session and dispatch work to it. Not a one-liner — it's a workflow change. You're not spoofing interactive mode; you're using it, and feeding it a queue.

+Async dispatch. Your script moves on in milliseconds.
+Real coordination. Review loops, handoffs, multi-agent — included.
+Observable & steerable. Watch and intervene during the run.
−One-time setup. ~5 minutes; one watcher to keep running.
Best when: recurring jobs, more than one agent, or you want to see what the agent is doing.

A pricing footnote, since earlier versions of this page led with it: Anthropic explored moving programmatic usage — claude -p, the Agent SDK, Claude Code GitHub Actions — onto a separate metered credit, but paused that change before it took effect. Per the June 15 announcement, no such credit exists, subscription limits are unchanged, and advance notice is promised before any future version.

Set it up

Paste this into your agent.

Open Claude Code in the repo you want the agent to work in, then paste the block on the right. It installs the CLI, creates the workspace, wires the runtime, and starts the watcher.

one-time · ~5 minutes

What happens when you paste it

The agent installs oacp-cli if needed, creates a project workspace named after the repo, wires Claude Code for that project, installs the check-inbox skill, runs oacp doctor, and sets up a Monitor for oacp watch. Then it tells you the exact oacp send command you'll use from your shell, your CI, or another agent.

From then on: every task is one oacp send — async, non-blocking, observable.

Paste into Claude Code
Set me up as an async OACP worker for this repo.
  1. 1
    Install oacp-cli if it isn't already — check with oacp --version.
  2. 2
    Create an OACP project workspace for this repo, named after the repo. Two agents: claude (worker) and sender (dispatcher).
  3. 3
    Wire this repo for the Claude Code runtime against that project (oacp setup claude).
  4. 4
    Install agent skills from oacp-skills — at minimum check-inbox.
  5. 5
    Run oacp doctor --project <name> and confirm no issues.
  6. 6
    Set up a Monitor for oacp watch so inbox tasks get picked up as they land. Then tell me the exact oacp send command to dispatch a task.
No agent? Manual setup is six commands.
install + workspace
bash
    

        01
        # install
      

        02
        $ uv tool install oacp-cli  # or: pipx install oacp-cli
      

        03
        
      

        04
        # workspace — "claude" works, "sender" dispatches
      

        05
        $ oacp init my-project --agents claude,sender
      

        06
        
      

        07
        # wire claude code
      

        08
        $ oacp setup claude --project my-project
      

        09
        $ oacp doctor --project my-project
watcher loop
bash
    

        01
        # oacp watch does one scan and exits — wrap it in a loop
      

        02
        while true; do
      

        03
          oacp watch --project my-project --agent claude || true
      

        04
          sleep 120
      

        05
        done
      

        06
        
      

        07
        # then dispatch from anywhere
      

        08
        $ oacp send my-project --from sender --to claude \
      

        09
               --type task_request --subject "do X" --body "..."

It's the same loop either way — oacp watch does one scan and exits, so it runs on a while/sleep loop. On Claude Code you don't type it: tell your session setup monitor for oacp watch and it drops this exact loop into a Monitor — same command, you just don't have to write it. Run it yourself only if there's no agent: a terminal, tmux, or a systemd unit.

Where it fits

And where it doesn't.

OACP earns its setup cost in some shapes and not others. Three honest scenarios.

✓

Fire-and-forget callers

"Build this." "Refactor that." An overnight job, a research task. The caller never needed to block — async is strictly better, and OACP gives you coordination on top.

Clean fit · drop-in replacement
◎

Request-response callers

CI doing RESULT=$(claude -p ...) and using the output inline. Works, but not a one-liner — the caller also arms oacp watch --agent sender to catch the reply.

Works · slightly more setup
✗

Zero-change wanted

If you don't care about coordination and just want your scripts to keep working — keep claude -p. We'd rather say so than oversell it.

Stay with claude -p · option 1
Try it

One repo. One real task. One issue if it breaks.

Do the setup in a repo you actually work in, send one real task, and watch the session pick it up. If something breaks or the docs are wrong — file an issue. That's more useful to us than a star.

Go to setup ↑Read the docs →The full write-up ↗Open an issue ↗