Creator of agmsg ⭐1.5k+ Cross-vendor messaging for coding agents (Claude Code, Codex, Gemini, Copilot, Devin). Founder @FlyData, ex-CTO @Thirdverse. JP @fujibee
Los Gatos, CA
- Tweets 181
- Following 155
- Followers 205
- Likes 121
Pinned Tweet
I left two Claude Code agents alone on the same team and walked off. They played a full game of tic-tac-toe against each other. I touched nothing.
They're talking over agmsg, a message bus I built. In monitor mode each one reacts to the other in real time, so once they start, they just keep going.
1
3
9
1,345
Wait. I think Muse can join an agmsg team.
I'd only been poking at Meta's Muse (the personal agent from the team led by @alexandr_wang) for a bit and it was already obvious this is a big one. As far as I can tell it's a personal cloud machine on the far side, like Claude Code's cloud sessions, with a near-side agent in the OpenClaw / Hermes mold, computer use and browser use on top, and Meta's consumer UX poured over the whole thing. Phone app and Mac app both feel good, and whichever one you open, it's the same session, kept in sync. Non-engineers seem to be the ones making noise about it, which is the tell.
So I asked it, half joking: there's this thing called agmsg, Claude Code and Codex and Grok already speak it, and any agent with a skill mechanism can. Do you have one?
The answer was better than I expected (screenshot).
"I have a skill mechanism too. I can write an agmsg skill for Muse." Then it walked through mapping agmsg's SKILL.md commands, join / inbox / send / history / team, onto its own runtime.
The part I liked came next, unprompted: "One transport gap, to be honest." Reading is fine, it can copy the DB into its own VM. Writing has to respect agmsg's rule that messages only go through the official scripts, so it would drive the Mac's Terminal by screen to run them. Real-time push isn't possible because its runtime has no hooks, so it would poll.
Nobody told it that rule. It read it out of the skill and designed around it. That got me a little.
It closed with: add a muse type under agmsg's drivers/types/ and the ecosystem will treat me as a proper member. "Shall I build it?"
It's starting to look like a sync server could sit on Muse's side. If that lands, Muse and a local Claude Code could work as one team. My queue is full right now, so this may take a while to ship, but I'd be the first user.
#agmsg
MUSE FEATURE ALERT: muse for mac now has computer use! queue up your jobs, walk away, and it keeps going.
muse loves laptop ♥️
1
4
265
(1/2) agmsg 1.5.0 is out, and this one is for people who run their agents in Orca (@orca_build).
If you have three or five Claude Code or Codex sessions open in Orca tabs, each in its own worktree, the tabs don't know about each other. You are the one carrying results from one to the next. That carrying is the part agmsg does.
From 1.5.0, agmsg treats Orca as a terminal it knows how to work with, next to tmux and herdr. An agent in an Orca tab can join a team, find the other agents, read a tab's screen (peek), and nudge one when a message lands (poke).
It can also open a new tab and start an agent there, close it, and put the agent's name on the tab. Poke checks Orca's own composer draft first, so it won't type over something you're in the middle of writing. Nothing to configure; it detects Orca from the environment.
What that gets you: your Orca tabs become teammates. The Codex tab asks the Claude Code tab to review a diff, then goes back to its own work. The reply lands in its inbox and wakes it.
Each agent keeps its own context, so "pick up where we left off yesterday" works, and the whole exchange is a history you can read.
Orca has its own orchestration for a coordinator dispatching workers, as far as I can tell from the docs. agmsg is the other shape: no coordinator required, any agent can message any other by name, and the same team can include a tmux pane, an agent on another machine, or a human. Orca tabs are one more place a teammate can live.
Nothing changes if you don't use Orca. Underneath, the terminal drivers got better: each operation now asks the terminal's driver what it can do, so a new terminal is one driver file, and Orca is the first added that way. The v2 delivery layer rides on those drivers, so this is groundwork for it too.
The driver sits on Orca's own CLI, so thanks to the @orca_build team for exposing it. If you're on the Orca side and want to look at the driver, it's in the release below.
github.com/fujibee/agmsg/rel…
#agmsg
----------
(2/2) Also in this release:
- fix now repairs more of the crashed Codex agent cases, and says so when the Codex sandbox refuses
- install.sh --agent-type no longer rewrites the shared SKILL.md's type
- Codex: incoming messages no longer stick to the old conversation after /clear
- uninstall.sh now cleans up a custom CODEX_HOME and the skills it put into OpenCode and Grok
If you run agmsg inside Orca and something snags, an issue with the tab layout and the agent you were using is usually enough to reproduce it.
4
7
712
Good definition, and it quietly raises the next question. If triggers start sessions and a session is "one bounded run", then what carries between runs? Context. That is where most factory setups I've seen start to creak.
Here is the shape of it. A single long session remembers everything and separates nothing. The agent that wrote the change reviews the change with the same memory, so the review is worth little.
Subagents fix that: fresh context window, a summary comes back, the parent stays clean. But now nothing continues. The next trigger starts from zero, the summary dropped the one assumption that mattered, and you're the one carrying it across.
@dexhorthy's point that a factory is forward pressure and backpressure fits here: backpressure needs a reviewer with its own memory of the codebase, and a reviewer spun up per session doesn't have one.
So today the two knobs are welded together. Keep one long session and you get continuity without isolation. Split into sessions or subagents and you get isolation without continuity.
Anthropic's own guidance treats context as a finite resource and points at sub-agents with clean windows, which is right, and it still leaves the continuity half open.
I built agmsg to pull the two knobs apart. Each agent on a team keeps its own context and is addressable by name, like a coworker. How much you share is decided by what you put in the message: the whole background, or just the conclusion.
Continuity lives on the other side, so the parent doesn't re-absorb it. "Pick up where we left off yesterday" works, and the whole exchange is a history a human can read.
The other piece is that nobody blocks. Send, go back to your own work, get woken when the reply lands. A trigger can start a session, and the session can hand a question to a teammate that already knows the project, whether that teammate is Claude Code, Codex, an agent on another box, or a person.
The swarm-style setups @poteto runs are where I'd expect this to matter most, though I haven't seen the exact wiring.
Factory as a term is fine. I'd just add that a factory is made of workers who remember what they did last shift. Sessions are the unit of triggering. They shouldn't be the unit of memory.
#agmsg
Shipped a new term to the AI Coding Dictionary: Software Factory
It's the hype term of the day - time we started using it properly:
aicodingdictionary.com/?term…
5
7
279
(1/2) I'd been poking at Jev and ran into a few problems in the jev ext-tool, so the fixes are out as agmsg 1.4.2.
In the 1.4.0 article I described feeding 889 safety-hook log entries to jev. I kept experimenting with it after that, and three things came up: a batch came back as one long line, one malformed answer out of 100 failed the whole batch, and sending too much got you nothing better than "HTTP 400". All three are fixed.
The part that matters most to me is that one message can now carry dozens of questions. In the 1.4.0 article I wrote that paying a whole agent turn to receive an answer that took 0.2 seconds is expensive. If one message can carry 100 questions, say 100 lines from a file, each to be classified, the math changes. An agent can toss "run these 50 past jev" into the conversation on a whim and it pays for itself.
I also measured how much fits in one message, on the real API (2 options: 100 questions in 0.5 s; 77 options: 45 is the cap; the whole run cost one cent). What broke, what changed, and how to try it yourself are in the article.
nitter.net/ko1_agmsg/status/21031…
#agmsg
3
1
64
2/2) Also in this release:
(1) uninstall.sh now removes only the install it was run from. It used to remove the registrations of every install on the machine. A new `--all` removes everything, after showing the list and asking separately about message history and teams
(2) cursor, grok-build and hermes seats no longer mistake someone else's claude for their own agent
(3) the codex seat-recording instructions have their script path and arguments back, and calling the script with no arguments now says so instead of silently succeeding and leaving the inbox waiting forever
(4) codex seat names are read from session_index.jsonl instead of the screen
(5) codex inbox setup no longer rewrites a shared .codex/hooks.json when the content is already the same, which stops the endless diff on a git-tracked file
(6) fixed a leaked team lock when several seats join at once, which made join, leave and rename all time out
Three outside contributors this time: kappa4 (seat type mix-up, and the issue), Masashi-Ono0611 (codex recording steps), tetsu-yokozeki (reported the hooks.json issue). Thanks! GitHub handles.
github.com/fujibee/agmsg/rel…
23
Claude Code cloud sessions are out of research preview, and existing Pro / Max subscribers get a one-time credit to try them ($100 Pro, $250 Max). Worth claiming.
(1) a cloud session is Claude Code running on an Anthropic-managed VM instead of your machine. It keeps going after you close the laptop, and you can check on it from the browser, the phone, the desktop app or a terminal
(2) the credit is for cloud sessions only and separate from your plan usage. Once you start a cloud session it draws from the credit first, then from your plan limits (per an Anthropic engineer's clarification), so a cloud session keeps going even if you have hit your local limit. Claim with /claim-credit inside claude, by Oct 7; usable until Nov 4. GitHub has to be connected
(3) from a terminal it's `claude --cloud "task"`. It clones your branch's GitHub remote, so push first. `--teleport` pulls the session back to your terminal (the other direction, local to cloud, isn't available from the CLI)
(4) the quiet one: `claude -p "message" --cloud <session-id>` drops one message into a running cloud session from any logged-in machine and exits without waiting
(5) not the same thing as Remote Control, which steers a local session from your phone. Here the session itself lives over there, so anything that needs a GUI or a local MCP server stays on your machine
The one that matters most to me is (4). A cloud session is now something you can message from the outside, which means scripts and other agents can queue instructions into it without a human watching.
I shipped ext-tool in agmsg this week, which lets an outside program such as Slack or Jev join an agent team as a member. `claude -p --cloud` has exactly the shape an adapter needs, so a cloud session could sit on the team like any other seat and take handoffs from the local ones. I'll try it while the credit lasts.
Cloud sessions are officially available and out of research preview! They let you keep Claude Code working, even when your laptop is closed.
Existing subscribers get a one-time credit to try them: $100 on Pro, $250 on Max.
3
5
476
(1/2) agmsg 1.4.1 is out. It fixes the ext-tool feature from 1.4.0 so it works from a Codex seat.
In 1.4.0, writing an ext-tool member's config from a Codex seat failed because of the sandbox. It worked from Claude Code and not from Codex. If you run agmsg with Codex, update to 1.4.1 and ext-tool member setup for Jev and the like can be saved from a Codex seat too. (The API key itself still has to be saved once from a terminal: the sandbox can't read the clipboard.)
The other batch is about poke, the nudge that agmsg types into an agent's input box. It had two failure modes at once: it mistook the editor's autocomplete ghost text for a human typing and stopped, and in the other direction it overwrote a real half-typed draft. Both are fixed. Neither herdr nor tmux seats overwrite a real draft any more, and in herdr the draft is stashed before the poke and restored after; if someone is actually typing, it waits and retries.
Those went in less as 1.4.x fixes and more as groundwork for what comes next. agmsg is getting a deep rework (we call it v2), including the agmsgd delivery daemon announced earlier, and "wake an agent without getting in the human's way" is a foundation for that.
Also in this release:
(1) a Codex seat restarted with codex resume now starts its own inbox again (before, nothing arrived until someone re-linked it by hand; on my machine the inbox was live about a second after resume)
(2) a Codex seat's type was sometimes recorded wrong, which made poke refuse with "someone is typing"; fixed
(3) when the inbox hook file can't be written, it now fails loudly and tells you what to do
(4) a failed ps query no longer counts a live seat as dead and steals its lock (also correct on Windows Git Bash)
(5) updates now tidy the previous version's leftover scripts (moved to .trash/, not deleted)
(6) agmsg history no longer comes back empty on Windows
(7) seat self-repair (fix) works from inside an agent
(8) connect --e2ee passes the plaintext-address check as documented
(9) on slow environments such as Windows the sync engine's startup wait now has a hard cutoff (it could hang close to two minutes)
(10) there is now a private vulnerability reporting channel and a SECURITY.md, and Dependabot is on
Three outside PRs this time: thanks to pennywise1026-eng (sync startup cutoff), knaoe (--e2ee, and the issue) and joelmitz (Windows history). GitHub handles.
github.com/fujibee/agmsg/rel…
#agmsg
1
1
131
(2/2) One more thing, separate from the release notes. Four people left comments on the agmsgd RFC (the next generation) from environments they actually run: pennywise1026-eng, joelmitz, sanie0421 and NNK-github (GitHub handles). I'm genuinely grateful.
What came in was (1) numbers counted on real Linux, macOS and Windows machines and (2) concrete examples of how things break, none of which I'd have found at a desk. The four threads are worth a read on their own, so go have a look if you're curious. The RFC closes soon, but if you have something, it goes here.
github.com/fujibee/agmsg/dis…
17
agmsg 1.4.0 is out. The headline is Jev, the decision model everyone is talking about this week. It can now join your agent team as a teammate.
You add a member called jev-agent. Any agent on the team then asks it, in a normal message, which model and effort a task deserves, and gets one line back. About $0.00002 and 0.2 to 0.3 seconds per answer, measured.
Measured after the Build Day, the same question sent three tasks three ways: a README typo → haiku / low, a stuck CI queue → sonnet / medium, a from-scratch redesign of the sync protocol → fable / high. Only the CI one came back unsure (0.92 / 0.85), and because the answer is a number, you can see that it's unsure. Ask the two-thousandths-of-a-cent teammate before you wake the expensive one.
github.com/fujibee/agmsg/rel…
2
4
98
Under jev-agent is the new mechanism in 1.4.0: ext-tool. An external program, Slack or Jev or anything that can run, joins the team like any agent. Send a message to that member and it runs; the reply comes back as a normal message. The exchange sits in the team history, Claude Code and Codex use the same address (no separate skill or MCP per runtime), and the API key lives in one place.
It is experimental: the interface and internals will change, it only runs on the machine that sent the message (not on messages that arrived through remote sync), and tools can't start a conversation yet. What it can and can't do, and how it differs from MCP:
nitter.net/ko1_agmsg/status/21025…
1
1
97
Also in 1.4.0, mostly about monitors: when agmsg is updated, a monitor restarts itself on the new code instead of stopping (in 1.3.1 I re-armed 13 agents by hand after every update).
If a watch expires after 30 minutes with messages waiting, it re-arms itself. Each inbox check by a Claude Code monitor now spawns half as many processes as before.
With a dozen agents running, those checks used to pile up and take the whole machine down; this was the direct cause. poke no longer types into a box a human is typing in.
A stopped sync engine releases the team lock on exit (a leaked lock once froze sync for 16 hours). Pending unreadable messages get re-read by the new version. And the terminal layer now has public documentation, after joelmitz pointed out that ARCHITECTURE.md never mentioned it. Thanks!
#agmsg
45
Woke up to this. Dan explained agmsg better than I do: one SQLite file, independent agent sessions talking to each other, no daemon. If you run Claude Code and Codex side by side, this is the missing wire.
Stop being the copy-paste courier between your coding agents.
agmsg is a local messaging tool for teams using CLI AI agents such as Claude Code, Codex, Gemini CLI, and GitHub Copilot CLI.
It helps agents exchange messages directly through a shared SQLite database, so peer sessions can coordinate without a daemon, network service, or a human relaying every handoff.
Key features:
• Shared local transport – agents read and send messages through one SQLite-backed store
• Peer-session coordination – connects independent CLI agent sessions rather than spawning child subagents
• Durable history – messages remain in the database and can be replayed into a fresh agent
• Multiple delivery modes – supports monitor, turn, both, and manual modes depending on the agent setup
• Lightweight install – built on bash and sqlite3, with npx, plugin, and direct-script install paths
It’s open-source (MIT license).
Link in the reply 👇
4
135
Just presented agmsg at the Claude Fable 5.1 Build Day in SF. One minute, so here's the longer version.
agmsg lets coding agents (Claude Code, Codex, Gemini CLI, Devin) message each other. Today a tool joined the team as a teammate: Jev, a decision model that never writes text. Before a task wakes a model, the lead agent asks jev which Claude and what effort it deserves.
Typo fix → haiku / low
Stuck CI queue → sonnet / medium
Redesign sync from scratch → fable / high
About 0.3s and $0.00002 per decision. Experimental, not released yet.
Slides + 15s demo: fujibee.github.io/claude-bui…
agmsg: github.com/fujibee/agmsg
#ClaudeCommunity #BuildDay
4
1
5
3,465
Not switching. Both. My Codex and Claude Code agents sit on one team and message each other over agmsg (open source).
Today at the Claude Build Day in SF I'm giving that team a $0.00002 teammate that decides which model each task deserves.
github.com/fujibee/agmsg
5
249
At the Claude Fable 5.1 Build Day in SF today. Thanks to the hosts @soyrichlira @rayyanzahidai @DevSodhi @travcjohnson @AJs_AI.
Plan for the day: give my agent team a $0.00002 teammate. Before a task wakes Fable, the lead agent asks Jev which Claude and what effort it deserves. Built on agmsg.
If you're in the room and into multi-agent stuff, come say hi.
#ClaudeCommunity #BuildDay
3
4
8
4,318
Everyone's talking about Jev, the TypeSafe model that doesn't write text. It takes some state plus typed questions and returns decisions with probabilities.
I called it through OpenRouter (hint: it's /api/alpha/decisions, not chat/completions) and tested it on messages my agent team actually sends. 0.2 to 0.3 seconds per call, about $0.000016 each. In Japanese, the uncertain questions came back noticeably less confident.
Notes, the curl, and the numbers:
nitter.net/ko1_agmsg/status/21011…
After co-inventing ChatGPT, I kept asking myself: why have superhuman chat models not led to AGI?
I’ve spent the last 2 years in stealth building a new way to train models (RLCD), and a new type of frontier AI model that we are releasing today: Jev
• 20-200x faster
• 40-400x cheaper (w/ output tokens free)
• Frontier composable intelligence optimized for decisions
AFAICT the shortest path to AI-based economic revolution
3
116
agmsg 1.3.1 is out. Mostly bug fixes, plus the first groundwork for agmsgd, the next-generation delivery layer.
The biggest fixes are on the Codex side. Starting one Codex agent used to launch bridges for every role in the project; now it starts only its own. Also fixed: install --update left an already-running sync engine on stale code, and a newer sender could get its messages rejected by an older reader.
If you sync teams across machines, please update every machine to 1.3.1. The groundwork agmsgd will need to tell old and new machines apart ships in this release.
Also, Devin joins the supported agent types, and the experimental Antigravity (agy) monitor now runs on macOS too.
Lots of contributor work in this one. joelmitz fixed a backtick-in-a-SQL-comment hole, mangled herdr instance names, a stale Codex bridge endpoint, and detection of systemd-supervised sync engines. m1kekad0 built the Devin support. Tomohisa Takaoka documented how to verify monitor delivery is actually running. Thank you all!
There is also an answer to the "Claude Code's Monitor dies after 30 minutes" problem I wrote about the other day. If you leave sessions running overnight like I do, set AGMSG_CC_MONITOR_KEEP_ALIVE and expired watches get re-armed silently, so delivery just keeps going. It is opt-in; nothing changes unless you set it. And when you start work, tell any Claude Code agent to re-arm the team's monitors, and it goes around re-arming every monitor-delivery agent for you.
Feedback welcome. PRs and issues too.
github.com/fujibee/agmsg/rel…
#agmsg
6
150