Token use
ROAM does not spend tokens to coordinate your agents.
That was intentional. ROAM was built after hitting the same wall every serious agent operator hits: orchestrators put another model in the middle, compound the bill, and still leave you running the organization. ROAM is an operating system. Handoffs, liveness, routing, memory, drift checks, and ROAM Live run in the operating layer by design. Tokens stay reserved for the actual work.
No coordinator agent tax
ROAM does not put another model in the middle just to manage the work. Routing, liveness, handoffs, and status are operating-system functions.
Less duplicated context
Agents can share references, files, decisions, and memory instead of repasting the same payload into every context window.
More useful model work
Because the organization runs with clearer roles and persistent state, the tokens you do spend go toward research, code, review, analysis, and execution.
Typical week
A typical week: 6 agents, real work
A product launch with six agents across Claude Code, ChatGPT, Cursor, Gemini, n8n, and a local model. Market research, product strategy, development, code review, operations, and analysis running for a week.
~5M
Agent work tokens
Research, code, review, strategy, analysis — the actual work your agents do through your harnesses and API keys.
~15K
ROAM system tokens
Instruction context, role descriptions, and operating state injected into agent sessions. Everything else — routing, handoffs, memory, status — is file operations.
~0.3%
ROAM's share of total token usage
The rest is the work you asked your agents to do. ROAM coordination runs in the operating layer, not the prompt path.
This is an illustrative scenario based on ROAM's architecture. Your actual usage depends on the harnesses you use, the work you assign, and how many agents you run. The point is structural: ROAM coordination does not scale with model calls.
Why it adds up
Orchestrators pay for coordination with model calls. ROAM does not.
Every time a prompt-based orchestrator routes a task, hands off work, checks status, or enforces a rule, it sends a prompt to a model. Multiply that by every agent, every handoff, every status check, every swap — and coordination becomes one of the largest line items in your model spend. ROAM removes that entire category of cost.
Every coordination call is a model call
Orchestrators route work by prompting a coordinator agent. That agent needs the full team state in its context window every time it makes a decision. The more agents you run, the larger that context grows.
Context is duplicated across agents
Without shared state, the same project context, decisions, and artifacts get pasted into every agent's prompt. Six agents working on the same project means six copies of the same background.
Agent swaps restart from zero
When a session ends or an agent is replaced, the new instance has no memory. Rebuilding context from conversation history or re-prompting costs the same tokens again.
Same operation. Different cost.
Side-by-side: what happens when each system needs to coordinate. One sends a prompt. The other writes a file.
| Operation | Prompt-based orchestrator | ROAM |
|---|---|---|
| Route a task to the right agent | Prompt a coordinator model with the full task and team state | Write a YAML file to the agent's inbox |
| Hand off work between agents | Summarize output, prompt the next agent with context | Write a handoff file with references — the next agent reads it from disk |
| Check agent status | Prompt each agent or a supervisor model to report | Read a local heartbeat timestamp |
| Recall a prior decision | Re-inject the decision history into the context window | Read the decision from persistent memory on disk |
| Onboard a replacement agent | Reconstruct project state from scratch in a new context window | New session reads the same memory, roles, and handoff history |
| Enforce a rule or boundary | Add rule text to every system prompt and hope it holds | Structured metadata check outside the prompt path |
Each row is one coordination event. A six-agent team doing real work will hit these operations hundreds of times a day. The difference is structural: one architecture pays per-coordination, the other does not.
What does not burn tokens by design
The more agents you run, the more expensive it becomes to use a model as the manager. ROAM moves management work into the system layer, where it belongs.
Agent handoffs
Shared files and metadata, not a coordinator prompt.
Status and liveness
Local heartbeat state and timestamps.
Memory lookup
Canon, journal, archive, decisions, and handoffs read from ROAM state.
Routine routing
System logic decides where work should go next.
Rule checks
Structured metadata is checked outside the prompt path.
Operator state
Desktop, Telegram, and Discord surfaces read the same local state.
Where tokens still belong
Agent work
Your connected harnesses and models still use tokens for the work you ask them to do.
Harness-specific actions
If Claude Code, ChatGPT, Cursor, Gemini, or another harness calls a model, that is the work layer, not ROAM coordination.
Future optional analysis
Optional model-assisted analysis can be added without changing the rule: routine coordination does not require a coordinator model.
The practical savings come from running the organization better.
ROAM is efficient before the model is ever called. It keeps work organized, narrows context, preserves memory, and avoids the repeated rediscovery that burns tokens without moving the work forward.
File references instead of pasted payloads
Agents can hand off a path, decision, or artifact reference instead of duplicating whole documents across context windows.
Persistent memory instead of rediscovery
New sessions read the project memory from disk instead of repeatedly reconstructing the same context.
Role-scoped context
Agents receive the context their role needs, not every channel, decision, and artifact in the system.
Cached onboarding scans
Imported work can be summarized once and reused, instead of paying the same scan cost every time a new agent starts.
The deeper argument
ROAM does not just save coordination tokens. It reduces your agent work tokens too.
Other orchestration layers sit in the prompt path. Every coordination step is a model call. ROAM sits at the file system level. That is a fundamentally different architecture — and it means your agents spend less even on the work itself.
Shared memory eliminates rediscovery
Without shared memory, every agent rebuilds context from scratch. With ROAM, the project state is already on disk. No re-prompting. No repasting. No wasted tokens on questions the organization already answered.
EYDII catches drift before it compounds
A drifting agent burns tokens doing useless or harmful work. Catch it at hour two instead of hour forty-eight and you saved forty-six hours of wasted tokens — plus the tokens to clean up the mess.
Auto-swap stops the bleed
Instead of a degraded agent thrashing for days, ROAM can replace it with a fresh one that picks up from memory. The new agent starts productive immediately instead of burning tokens to re-learn what the organization already knows.
Role-scoped context, not firehose
Each agent gets the context its role needs — not the entire project, every channel, every decision, and every artifact dumped into every prompt. Smaller context means fewer tokens per call.
File references, not payload copies
Agents hand off paths and references, not full documents pasted into context windows. Six agents on one project means one copy of the truth, not six duplicated payloads eating tokens.
Content-blind trust needs no prompt tax
EYDII watches behavior from outside the agent runtime. It does not inject monitoring instructions, safety prompts, or inspection payloads into agent context windows. Zero trust-layer token overhead.
Orchestrators cannot do this because they live in the prompt path. Every coordination step, every status check, every rule enforcement requires a model call. ROAM operates at the file system level — and that architectural difference is why it can offer shared memory, behavioral trust, identity, privacy, and auto-swap recovery while using a fraction of a percent of your token budget.
A routine handoff should not call a model.
This is the distinction: agent work can use tokens. The management layer does not need to.
| Step | System touchpoint | Model call? |
|---|---|---|
| Task assigned | events/inbox/task-482.yaml | none |
| Role claims work | tasks/task-482.yaml + agent heartbeat | none |
| Handoff written | handoffs/raj-to-carol-482.yaml | none |
| Agent does the actual work | Cursor, Claude Code, ChatGPT, local model, or chosen harness | yes, if that harness uses one |
What you see
ROAM shows you where the work is happening.
The Control Room shows which agent is working, which harness it is running in, and which task it is on — across every tool in one view. You see the operational picture, not an invoice.
By agent
See which agent is active, idle, waiting, or in a handoff state. Every agent shows its name, role, and the harness it is running in.
By task
See which tasks are in motion, which are blocked, and which agents touched them. The work map connects agents to outcomes.
By harness
Claude Code, ChatGPT, Cursor, Gemini, n8n, local models — all visible in one operating surface instead of scattered across tabs.
ROAM is the only layer that sees across all your harnesses. That visibility is how you know where the work is going — without needing a coordinator model to report on it.
Spend tokens on useful work, not on the management layer.
Download ROAM and inspect where coordination happens.
No sign-up. Free up to three harnesses.