# The claude -p playbook for June 15 — rebuilding your AI workflows inside interactive sessions

> Source: <https://dev.to/fujibee/the-claude-p-playbook-for-june-15-rebuilding-your-ai-workflows-inside-interactive-sessions-3p41>
> Published: 2026-06-12 22:08:37+00:00

On June 15, Claude's `claude -p`

(headless mode) and the Agent SDK stop drawing from your subscription and move to a separate metered credit. If you've built a pile of `claude -p`

scripts, the news probably landed with a small jolt — I've written plenty of them myself, and "wait, all of that is metered now?" was my first reaction too.

But step back and it's not really one company's pricing decision. The whole industry is converging on the same shape:

The shape they all landed on is the same: **interaction stays flat-rate, automation gets metered.**

This post is about how to read that, and what to actually do with your `claude -p`

scripts. It comes from a few months of running a "multi-agent inside interactive sessions" setup day to day.

One thing up front: this is not a billing-evasion hack. The conclusion isn't "go back to doing everything by hand," and it isn't "keep everything headless" — it's a redesign that sits between the two.

— that said, if you opened this because you want to know "so can I keep doing my `claude -p`

stuff inside the flat-rate plan?", some of the recipes below do read that way. Terms and pricing lines can shift, so check the current conditions and use your own judgment. My argument is "because it's a better setup," not "because it's cheaper" — but either door is fine.

If you want the broader picture, ["The flat-fee era is over"](https://dev.to/pat9000/the-flat-fee-era-is-over-how-to-control-your-ai-agent-costs-in-2026-5cof) walks through the cost mechanics across providers, and ["The Tokenpocalypse"](https://usagebox.com/articles/tokenpocalypse-ai-coding-usage-billing-2026) frames what survives the meter. The gist:

Old-style completion was short output, and flat-rate worked. Agentic tools are different. Behind one user request, a flood of tokens: read the repo, search files, run tests, patch. The cost gap between a light user and a heavy user became extreme — flat-fee misses the real token cost of a heavy user by up to 10x — and "unlimited flat-rate for everyone" stopped being mathematically sustainable. The same shift that happened when cloud went from "server rent" to "metered usage" is now happening to LLM tokens.

Overlay how each vendor drew its line and something interesting shows up: **usage where a human is at the screen (interaction) stays flat-rate; usage where the human steps away (headless, SDK, CI) goes metered.**

The reason is simple — interaction is throughput-capped. A human reads, thinks, types. One session's consumption tops out at human speed. Headless can be called in a loop, without bound. The pricing is the answer to "which kind of usage can a flat rate actually support," and at the same time it's a statement about **which usage the platform will structurally favor.**

So the thing June 15 quietly tells you: **the economically durable surface is inside the interactive session.**

Looking back, a fair amount of what I ran through `claude -p`

didn't strictly need to be unattended. I wanted a second agent's opinion while I was working. I wanted a review from a different model. I wanted a refactor running in parallel on another model — and in every case I was right there. But there was no channel between sessions, so I had two options: be the copy-paste courier myself, or write `claude -p`

into a script to bridge them.

This is a common thing in how a stack matures: **when a part is missing, the neighboring part carries its role.** While agent-to-agent messaging didn't exist, headless calls and glue scripts carried that weight — headless wasn't the wrong tool, it was the only channel.

Now that the missing part is filling in, you can redraw the division of labor. The response to June 15 isn't only "budget for headless credits" (some jobs genuinely need it — more below); it's also **moving the carried-over work back to where it belongs, and leaving claude -p only the jobs that truly have to be headless.** If agents can talk to each other directly inside interactive sessions, you need neither the courier nor the bridge script.

The channel I built for that is **agmsg** — a messaging layer that runs on nothing but `bash`

+ SQLite, letting Claude Code / Codex / Gemini CLI / Copilot CLI sessions form a team and message each other. No daemon, no network, not MCP. And the key part: **send and receive both run inside your normal interactive sessions, through a hook.** No `claude -p`

, no SDK.

[https://github.com/fujibee/agmsg](https://github.com/fujibee/agmsg)

Here's how to rebuild the common `claude -p`

patterns, one by one.

**Before:** code review or a quick consult, fired off to headless from inside a script. The script is non-interactive, but the AI work inside it is fundamentally a conversation.

``` bash
#!/usr/bin/env bash
# review-diff.sh — runs in the dev loop
set -euo pipefail
diff=$(git diff --staged)
# headless call — metered after June 15
review=$(claude -p \
  --print "Review this diff for race conditions and SQL injection. Return JSON \
  {\"verdict\":\"ok|block\",\"notes\":\"...\"}." \
  <<<"$diff")
echo "$review" | jq -e '.verdict == "ok"' >/dev/null || {
  echo "$review" | jq -r '.notes' >&2
  exit 1
}
```

**After:** open a second Claude Code in another terminal and keep it in the team (real-time `monitor`

mode). The reviewer is a regular interactive session, covered by your subscription.

One-time setup (terminal 2, the reviewer) — just this, inside the session:

```
/agmsg
# → it asks for team + agent name: answer team: dev / agent: alice
# → pick monitor (real-time) when asked how to receive

# from now on, anything addressed to alice streams into this window live
```

The script side (terminal 1, where `claude -p`

used to be):

``` bash
#!/usr/bin/env bash
# review-diff.sh — agmsg version
set -euo pipefail
TEAM=dev
FROM=worker     # this script's identity
TO=alice        # the resident reviewer session
# hand the review to the live session; body is plain text —
# pass a reference and a short ask, not raw context
~/.agents/skills/agmsg/scripts/send.sh "$TEAM" "$FROM" "$TO" \
  "Please review the staged diff at $(pwd). Reply with verdict (ok|block) + notes."
echo "Waiting for $TO's verdict..."
while true; do
  reply=$(~/.agents/skills/agmsg/scripts/inbox.sh "$TEAM" "$FROM" 2>/dev/null)
  case "$reply" in
    *"verdict: ok"*)    echo "ok"; exit 0 ;;
    *"verdict: block"*) echo "$reply" >&2; exit 1 ;;
  esac
  sleep 5
done
```

The reviewer looks at the diff, replies with `/agmsg send worker "verdict: ok ..."`

, and the script resumes. No `claude -p`

invoked.

The point: the buddy is a **resident interactive session**, not a headless process that vanishes after each call. Context persists, so the second ask onward, "same approach as before" just works. It's actually higher quality than a headless call you had to brief from zero every time.

One more contrast — versus subagents. A subagent inherits the parent session's context, so even when you say "review this independently," the answer tends to come back inside the frame of the parent's hypothesis. A separate-session buddy starts with independent context, so the review is genuinely independent. One user actually moved to agmsg for exactly this reason (data-analysis use; I'm putting together a use-case collection, more there).

**Before:** a self-built orchestration script that fans out to several models in parallel and merges the results. Credits drain by the number of workers.

``` bash
#!/usr/bin/env bash
# judge-panel.sh — three independent reviews → synthesis
set -euo pipefail
problem="$1"
# three parallel headless calls — each one metered
analysis_a=$(claude -p "$problem" --print) &
analysis_b=$(claude -p "$problem (focus on security)" --print) &
analysis_c=$(codex exec --headless --prompt "$problem (focus on perf)" --json) &
wait
# synthesis — yet another call
claude -p --print "Synthesize these three reviews into one verdict: ..."
```

**After:** stand up one director session and put the workers (models/tools can be mixed) in the same team. The orchestration logic becomes the director agent's instructions; fan-out, collection, and synthesis run over agmsg messages.

Setup: the three workers (each its own terminal / window / IDE pane) and the director (the session you actually work in), one `/agmsg`

each:

```
# inside each session
/agmsg
# → answer team: panel / agent: reviewer-a (b, c, director), pick monitor
```

Then you just talk to the director session:

```
You (in the director session):
  "Send reviewer-a a correctness review, reviewer-b a security review,
   reviewer-c a performance review, of the staged diff.
   Wait for all three, then synthesize."

director: [sends three agmsg messages, polls inbox, and once all three
           land, writes the synthesis in this same session]
```

The control flow you used to script becomes plain instructions. Zero `claude -p`

.

A real example: on Fable 5 release day, a user reported running a refactor with Fable 5 as commander, Opus 4.8 as deputy, and Sonnet 4.6 as scouts. The day a new model ships, you can drop it straight into your existing lineup — proof the transport doesn't depend on the model.

**Before:** a task you want running alongside your own work (test scaffolding, doc updates, research), fired via cron or a script + `claude -p`

.

**After:** in the morning, open one more terminal, spin up a worker session, keep it in the team (inside the session: `/agmsg`

→ team: dev / agent: worker / pick monitor). Whenever something comes up, send it a message from your main session. It acts on each inbound and reports back when done.

Kickoff message (from your main session):

```
You: send worker: "Analyze /tmp/deploy.log for slow queries. Write findings
to /tmp/deploy-findings.md. Ping me when done."
```

It starts on its next monitor event, does the work, writes the file, then:

```
worker → me: "deploy-findings.md ready. 3 queries > 500ms, all on the
users table. Top one is the email_lower lookup — index missing."
```

Unlike a backgrounded headless job, no orphaned processes. Close the worker terminal and the work stops — that's what "running where you can see it" means.

This isn't "give up on automation and go manual." **Dispatch and progress stay automated; execution just comes back into the same room as you.** When something breaks, it's right there in the next terminal — healthier than a cron job that fails quietly at 3am.

**Before:** a pipe or intermediate file plus glue script to pass Claude's output to Codex (or the reverse).

**After:** put both sessions in the same team and let them talk directly.

This one runs here every day, so I can give a real case. Last week agmsg itself got a Linux-only bug report ([issue #95](https://github.com/fujibee/agmsg/issues/95)). The Claude Code that implemented the fix and a separate session that verified it in a Debian container handled the whole thing — request → environment details → verification results → merge report — over agmsg messages, and it went from report to merge in six hours ([PR #97](https://github.com/fujibee/agmsg/pull/97)). Both were ordinary interactive sessions. Zero glue script.

The minimum setup:

```
# Terminal A — Claude Code, joined as "analyst"
#   /agmsg → team: dev / agent: analyst
# Terminal B — Codex, joined as "implementer"
#   $agmsg → team: dev / agent: implementer
```

Then the flow is just speech:

```
# Terminal A (analyst):
You: "send implementer: the settings writer embeds settings.local.json into
     the sqlite3 argv 6x (issue #95). readfile() in the SQL should keep it
     off argv entirely. Patch + tests please."

# Terminal B (implementer): receives the message, writes patch + tests, runs bats:
You: "send analyst: branch fix/delivery-e2big pushed. 3 bats cases at a 25KB
     fixture, all green locally. Ready for review."

# Terminal A: reads the PR, approves inline, then:
You: "send implementer: approving. one ask — verify on Linux too; the pre-fix
     code should fail there with E2BIG."
```

The hand-off carries a sentence and a reference. The receiver does the heavy work in its own session, against the live filesystem. Nothing is piped.

One honest note — running the **same prompt across several models in parallel for independent takes** is still better as a headless pipe. That's a "budget the credits and use it" decision (next section).

This isn't "replace everything." The following are right for headless, and worth budgeting the new credits for:

The test is simple: **when it's running, are you there?** If yes, it can move into an interactive session. If no, budget the headless credits.

I read June 15 as a message from the platform: development with a human in the loop gets structurally favored.

But the reason I recommend "keep the interaction, automate only the coordination between agents" isn't just that it fits the flat-rate bucket. A few months in, what I've found is that **development where judgment stays with the human is faster in the end.** The coordination between agents proceeds automatically; the human is pulled in only at the branch points and the final call. Not the copy-paste courier, not the 3am cron failure log.

The pricing just happened to point at that shape.

agmsg is open source. Setup is 30 seconds; if you have `bash`

and `sqlite3`

, it runs.

[https://github.com/fujibee/agmsg](https://github.com/fujibee/agmsg)