Skip to main content

RPC Mode

RPC mode enables headless operation of the coding agent via a JSON protocol over stdin/stdout. This is useful for embedding the agent in other applications, IDEs, or custom UIs. Note for Node.js/TypeScript users: If you’re building a Node.js application, consider using AgentSession directly from @bastani/atomic instead of spawning a subprocess. See src/core/agent-session.ts for the API. For a subprocess-based TypeScript client, see src/modes/rpc/rpc-client.ts.

Starting RPC Mode

Common options:
  • --provider <name>: Set the LLM provider (anthropic, openai, google, etc.)
  • --model <pattern>: Model pattern or ID (supports provider/id and optional :<thinking>)
  • --context-window <tokens>: Select a supported context-window size for the startup model (400k, 1m, or raw tokens)
  • --name <name> / -n <name>: Set the session display name at startup
  • --no-session: Disable session persistence
  • --session-dir <path>: Custom session storage directory

Protocol Overview

  • Commands: JSON objects sent to stdin, one per line
  • Responses: JSON objects with type: "response" indicating command success/failure
  • Events: Agent events streamed to stdout as JSON lines
All commands support an optional id field for request/response correlation. If provided, the corresponding response will include the same id.

Framing

RPC mode uses strict JSONL semantics with LF (\n) as the only record delimiter. This matters for clients:
  • Split records on \n only
  • Accept optional \r\n input by stripping a trailing \r
  • Do not use generic line readers that treat Unicode separators as newlines
In particular, Node readline is not protocol-compliant for RPC mode because it also splits on U+2028 and U+2029, which are valid inside JSON strings.

Commands

Prompting

prompt

Send a user prompt to the agent. The command response is emitted after the prompt is accepted, queued, or handled. Events continue streaming asynchronously after acceptance.
With images:
During streaming: If the agent is already streaming, you must specify streamingBehavior to queue the message:
  • "steer": Queue the message while the agent is running. It is delivered after the current assistant turn finishes executing its tool calls, before the next LLM call.
  • "followUp": Wait until the agent finishes. Message is delivered only when agent stops.
If the agent is streaming and no streamingBehavior is specified, the command returns an error. Extension commands: If the message is an extension command (e.g., /mycommand), it executes immediately even during streaming. Extension commands manage their own LLM interaction via pi.sendMessage(). Input expansion: Skill commands (/skill:name) and prompt templates (/template) are expanded before sending/queueing. Response:
success: true means the prompt was accepted, queued, or handled immediately. success: false means the prompt was rejected before acceptance. Failures after acceptance are reported through the normal event and message stream, not as a second response for the same request id. The images field is optional. Each image uses ImageContent format: {"type": "image", "data": "base64-encoded-data", "mimeType": "image/png"}.

steer

Queue a steering message while the agent is running. It is delivered after the current assistant turn finishes executing its tool calls, before the next LLM call. Skill commands and prompt templates are expanded. Extension commands are not allowed (use prompt instead).
With images:
The images field is optional. Each image uses ImageContent format (same as prompt). Response:
See set_steering_mode for controlling how steering messages are processed.

follow_up

Queue a follow-up message to be processed after the agent finishes. Delivered only when agent has no more tool calls or steering messages. Skill commands and prompt templates are expanded. Extension commands are not allowed (use prompt instead).
With images:
The images field is optional. Each image uses ImageContent format (same as prompt). Response:
See set_follow_up_mode for controlling how follow-up messages are processed.

abort

Abort the current agent operation.
Response:

new_session

Start a fresh session. Can be cancelled by a session_before_switch extension event handler.
With optional parent session tracking:
Response:
If an extension cancelled:

State

get_state

Get current session state.
Response:
The model field is a full Model object or null. Its contextWindow is the active/effective token budget; selectable models may also include defaultContextWindow and contextWindowOptions. The sessionName field is the display name set via set_session_name, or omitted if not set.

get_messages

Get all messages in the conversation.
Response:
Messages are AgentMessage objects (see Types).

Model

set_model

Switch to a specific model.
Response contains the full Model object:

cycle_model

Cycle to the next available model. Returns null data if only one model available.
Response:
The model field is a full Model object.

get_available_models

List all configured models.
Response contains an array of full Model objects:

logout_provider

Remove a provider’s stored credential in the authoritative agent process, refresh its available-model catalog, and return the remaining authentication status and new catalog. Environment variables and models.json authentication are reported but are not modified.
Response:
models preserves the refreshed catalog order. scopedModels is optional. If authentication remains through an environment variable, authStatus.source is "environment" and authStatus.label names the variable.

Context Window

get_available_context_windows

List the context-window token budgets supported by the current model and read the active/effective runtime selection.
Response:
  • contextWindows: supported token budgets for the active model, sorted ascending.
  • currentContextWindow: the active/effective token budget on model.contextWindow; omitted when no model is selected.
  • supportsSelection: true when the active model exposes more than one supported budget.

set_context_window

Set the active context-window token budget for the current model at runtime.
Compact string values are also accepted:
Response:
This command calls AgentSession.setContextWindow(...) without { persistDefault: true }: it updates the active model, appends a context_window_change session entry and emits context_window_changed when the budget changes, but it does not write context-window defaults to settings. Use startup --context-window or an interactive context-window selection when you intentionally want the effective selection persisted under defaultContextWindows["provider/modelId"]. Unsupported or malformed selections return the standard RPC error response:
Larger provider context windows may consume more credits/cost. For catalog-advertised GitHub Copilot long-context models (including github-copilot/gpt-5.5, github-copilot/claude-sonnet-5, and github-copilot/gemini-3.1-pro-preview), selecting 1m raises Atomic’s local budget and sends X-GitHub-Api-Version: 2026-06-01; GitHub applies the long-context billing tier server-side by prompt token count. That tier consumes more Copilot AI credits and requires Copilot long-context/usage-based billing entitlement, otherwise requests over GitHub’s server cap are rejected with a friendly hint.

Thinking

set_thinking_level

Set the reasoning/thinking level for models that support it.
Levels: "off", "minimal", "low", "medium", "high", "xhigh", "max". xhigh and max are available only when the active model’s capability mapping supports them; unsupported levels are clamped by the session model controls. Response:

cycle_thinking_level

Cycle through available thinking levels. Returns null data if model doesn’t support thinking.
Response:

get_available_thinking_levels

Return the thinking levels supported by the current model, in cycle order.
Response:

Queue Modes

set_steering_mode

Control how steering messages (from steer) are delivered.
Modes:
  • "all": Deliver all steering messages after the current assistant turn finishes executing its tool calls
  • "one-at-a-time": Deliver one steering message per completed assistant turn (default)
Response:

set_follow_up_mode

Control how follow-up messages (from follow_up) are delivered.
Modes:
  • "all": Deliver all follow-up messages when agent finishes
  • "one-at-a-time": Deliver one follow-up message per agent completion (default)
Response:

Compaction

compact

Run Atomic’s verbatim line compactor. The selected session model receives the complete active numbered transcript except for exactly the newest preserve_recent context-visible messages and returns bare start,end deletion records; Atomic validates them and mechanically reconstructs retained lines with (filtered N lines) markers. The default tail is two messages, with no user-turn alignment. A value of zero sends the entire active transcript and persists firstKeptEntryId: null. The command appends a durable compaction entry with details.strategy: "verbatim-lines".
Response:
firstKeptEntryId is a string when at least one ordinary message remains outside compaction and null when none does. RPC clients must accept both values.

set_auto_compaction

Enable or disable automatic compaction when context is nearly full.
Response:

Retry

set_auto_retry

Enable or disable automatic retry on transient errors (overloaded, rate limit, 5xx).
Response:

abort_retry

Abort an in-progress retry (cancel the delay and stop retrying).
Response:

Bash

bash

Execute a shell command and add output to conversation context.
Response:
If output was truncated, includes fullOutputPath:
How bash results reach the LLM: The bash command executes immediately and returns a BashResult. Internally, a BashExecutionMessage is created and stored in the agent’s message state. This message does NOT emit an event. When the next prompt command is sent, all messages (including BashExecutionMessage) are transformed before being sent to the LLM. The BashExecutionMessage is converted to a UserMessage with this format:
This means:
  1. Bash output is included in the LLM context on the next prompt, not immediately
  2. Multiple bash commands can be executed before a prompt; all outputs will be included
  3. No event is emitted for the BashExecutionMessage itself

abort_bash

Abort a running bash command.
Response:

Session

get_session_stats

Get token usage, cost statistics, and current context window usage.
Response:
tokens contains assistant usage totals for the current session state. contextUsage contains the actual current context-window estimate used for compaction and footer display. contextUsage is omitted when no model or context window is available. contextUsage.tokens and contextUsage.percent are null immediately after compaction until a fresh post-compaction assistant response provides valid usage data.

export_html

Export session to an HTML file.
With custom path:
Response:

switch_session

Load a different session file. Can be cancelled by a session_before_switch extension event handler.
Response:
If an extension cancelled the switch:

fork

Create a new fork from a previous user message on the active branch. Can be cancelled by a session_before_fork extension event handler. Returns the text of the message being forked from.
Response:
If an extension cancelled the fork:

clone

Duplicate the current active branch into a new session at the current position. Can be cancelled by a session_before_fork extension event handler.
Response:
If an extension cancelled the clone:

get_fork_messages

Get user messages available for forking.
Response:

get_entries

Get all session entries in append order (excluding the session header). The session is an append-only tree of entries with stable ids, so an entry id works as a durable cursor: pass the last entry id you have seen as since to get only entries strictly after it, even across client restarts. Unlike get_messages, this includes pre-compaction history and abandoned branches.
With a cursor:
Response:
leafId is the id of the current leaf entry (null for an empty session), so a client can tell in one round trip whether the active branch moved. If since does not match any entry id, the response is success: false.

get_tree

Get the session as a tree of entries. Each node is {entry, children, label?, labelTimestamp?}. A well-formed session has a single root; orphaned entries (broken parent chain) also appear as roots.
Response:

get_last_assistant_text

Get the text content of the last assistant message.
Response:
Returns {"text": null} if no assistant messages exist.

set_session_name

Set a display name for the current session. The name appears in session listings and helps identify sessions.
Response:
The current session name is available via get_state in the sessionName field. To set the initial name when starting RPC mode, pass --name <name> or -n <name> to the atomic --mode rpc process.

Commands

get_commands

Get available commands (extension commands, prompt templates, and skills). These can be invoked via the prompt command by prefixing with /.
Response:
Each command has:
  • name: Command name (invoke with /name)
  • description: Human-readable description (optional for extension commands)
  • source: What kind of command:
    • "extension": Registered via pi.registerCommand() in an extension
    • "prompt": Loaded from a prompt template .md file
    • "skill": Loaded from a skill directory (name is prefixed with skill:)
  • location: Where it was loaded from (optional, not present for extensions):
    • "user": User-level (~/.atomic/agent/)
    • "project": Project-level (./.atomic/)
    • "path": Explicit path via CLI or settings
  • path: Absolute file path to the command source (optional)
Note: Built-in TUI commands (/settings, /hotkeys, etc.) are not included. They are handled only in interactive mode and would not execute if sent via prompt.

Events

Events are streamed to stdout as JSON lines during agent operation. Events do NOT include an id field (only responses do).

Event Types

agent_start

Emitted when the agent begins processing a prompt.

agent_end

Emitted when the agent completes. Contains all messages generated during this run.

turn_start / turn_end

A turn consists of one assistant response plus any resulting tool calls and results.

message_start / message_end

Emitted when a message begins and completes. The message field contains an AgentMessage.

message_update (Streaming)

Emitted during streaming of assistant messages. Contains both the partial message and a streaming delta event.
The assistantMessageEvent field contains one of these delta types: Example streaming a text response:

tool_execution_start / tool_execution_update / tool_execution_end

Emitted when a tool begins, streams progress, and completes execution.
During execution, tool_execution_update events stream partial results (e.g., bash output as it arrives):
When complete:
Use toolCallId to correlate events. The partialResult in tool_execution_update contains the accumulated output so far (not just the delta), allowing clients to simply replace their display on each update.

queue_update

Emitted whenever the pending steering or follow-up queue changes.

context_window_changed

Emitted when the active context-window token budget changes through RPC set_context_window, AgentSession.setContextWindow() in an SDK-backed runtime, or because in-place tree navigation replayed a branch-scoped context_window_change entry. Navigation replay updates the active model for accurate budgeting and compaction but does not append another session entry or write context-window defaults to settings.
Larger provider context windows may consume more credits/cost. Prefer the model default unless the additional repository/session context is useful for the current task. For catalog-advertised GitHub Copilot long-context models such as github-copilot/gpt-5.5, github-copilot/claude-sonnet-5, and github-copilot/gemini-3.1-pro-preview, a 1m selection raises Atomic’s local budget and sends X-GitHub-Api-Version: 2026-06-01; GitHub applies the long-context billing tier server-side by prompt size, consumes more Copilot AI credits, and requires long-context/usage-based billing entitlement.

compaction_start / compaction_end

Emitted when default Verbatim Compaction runs, whether manual or automatic. The result records deletion targets and stats rather than a generated summary.
The reason field is "manual", "threshold", or "overflow".
If reason was "overflow" and compaction succeeds, willRetry is true and the agent will automatically retry the prompt. Public prompt/RPC callers wait for that post-compaction continuation before the prompt is considered complete. If compaction was aborted, result is null and aborted is true. If compaction failed (e.g., API quota exceeded), result is null, aborted is false, and errorMessage contains the error description. If overflow recovery exhausts the same-model compact-and-retry attempt, compaction_end includes "unresolvedOverflow": true and an errorMessage. Workflow orchestration treats that signal as a context-length failure that can advance configured model fallback tiers. There is no context_compact command; Atomic reports it as an unknown command. Use compact. Only compaction_start and compaction_end events are emitted.

auto_retry_start / auto_retry_end

Emitted when automatic retry is triggered after a transient error (overloaded, rate limit, 5xx).
On final failure (max retries exceeded):

summarization_retry_scheduled / summarization_retry_attempt_start / summarization_retry_finished

Emitted when compaction planning or branch summarization retries after a transient provider error. These events use the same retry settings as automatic assistant-turn retries.
For branch summaries, source is "branchSummary" and no reason is present. The loop then emits:

extension_error

Emitted when an extension throws an error.

Extension UI Protocol

Extensions can request user interaction via ctx.ui.select(), ctx.ui.confirm(), etc. In RPC mode, these are translated into a request/response sub-protocol on top of the base command/event flow. There are two categories of extension UI methods:
  • Dialog methods (select, confirm, input, editor): emit an extension_ui_request on stdout and block until the client sends back an extension_ui_response on stdin with the matching id.
  • Fire-and-forget methods (notify, setStatus, setWidget, setTitle, set_editor_text): emit an extension_ui_request on stdout but do not expect a response. The client can display the information or ignore it.
If a dialog method includes a timeout field, the agent-side will auto-resolve with a default value when the timeout expires. The client does not need to track timeouts. Some ExtensionUIContext methods are not supported or degraded in RPC mode because they require direct TUI access:
  • custom() returns undefined
  • setWorkingMessage(), setWorkingIndicator(), setFooter(), setHeader(), setEditorComponent() are no-ops
  • getEditorText() returns ""
  • setToolsExpanded() and getToolsExpanded() maintain context-local expansion state; getChatRenderSettings().toolOutputExpanded reports the same value. This state is not sent through the client extension-UI protocol.
  • pasteToEditor() delegates to setEditorText() (no paste/collapse handling)
  • getAllThemes() returns []
  • getTheme() returns undefined
  • setTheme() returns { success: false, error: "..." }
Note: ctx.mode is "rpc" and ctx.hasUI is true in RPC mode because the dialog and fire-and-forget methods are functional via the extension UI sub-protocol. Use ctx.mode === "tui" to guard TUI-specific features like custom() that require a real terminal.

Extension UI Requests (stdout)

All requests have type: "extension_ui_request", a unique id, and a method field.

select

Prompt the user to choose from a list. Dialog methods with a timeout field include the timeout in milliseconds; the agent auto-resolves with undefined if the client doesn’t respond in time.
Expected response: extension_ui_response with value (the selected option string) or cancelled: true.

confirm

Prompt the user for yes/no confirmation.
Expected response: extension_ui_response with confirmed: true/false or cancelled: true.

input

Prompt the user for free-form text.
Expected response: extension_ui_response with value (the entered text) or cancelled: true.

editor

Open a multi-line text editor with optional prefilled content.
Expected response: extension_ui_response with value (the edited text) or cancelled: true.

notify

Display a notification. Fire-and-forget, no response expected.
The notifyType field is "info", "warning", or "error". Defaults to "info" if omitted.

setStatus

Set or clear a status entry in the footer/status bar. Fire-and-forget.
Send statusText: undefined (or omit it) to clear the status entry for that key.

setWidget

Set or clear a widget (block of text lines) displayed above or below the editor. Fire-and-forget.
Send widgetLines: undefined (or omit it) to clear the widget. The widgetPlacement field is "aboveEditor" (default) or "belowEditor". Only string arrays are supported in RPC mode; component factories are ignored.

setTitle

Set the terminal window/tab title. Fire-and-forget.

set_editor_text

Set the text in the input editor. Fire-and-forget.

Extension UI Responses (stdin)

Responses are sent for dialog methods only (select, confirm, input, editor). The id must match the request.

Value response (select, input, editor)

Confirmation response (confirm)

Cancellation response (any dialog)

Dismiss any dialog method. The extension receives undefined (for select/input/editor) or false (for confirm).

Error Handling

Failed commands return a response with success: false:
Parse errors:

Types

Source files and installed definitions:
  • node_modules/@earendil-works/pi-ai/dist/types.d.ts - Model, UserMessage, AssistantMessage, ToolResultMessage
  • node_modules/@earendil-works/pi-agent-core/dist/types.d.ts - AgentMessage, AgentEvent
  • src/core/messages.ts - BashExecutionMessage
  • src/modes/rpc/rpc-types.ts - RPC command/response types, extension UI request/response types

Model

contextWindow is the active/effective token budget used by Atomic’s local budgeting, footer/stats, and compaction logic. defaultContextWindow is the model’s scalar default before a session/runtime override, and contextWindowOptions lists selectable token budgets when the model supports more than one size. RPC clients can read/select the active runtime budget with get_available_context_windows and set_context_window; the runtime command does not persist context-window defaults to settings.

UserMessage

The content field can be a string or an array of TextContent/ImageContent blocks.

AssistantMessage

Stop reasons: "stop", "length", "toolUse", "error", "aborted"

ToolResultMessage

BashExecutionMessage

Created by the bash RPC command (not by LLM tool calls):

Attachment

Example: Basic Client (Python)

Example: Interactive Client (Node.js)

See test/rpc-example.ts for a complete interactive example, or src/modes/rpc/rpc-client.ts for a typed client implementation. For a complete example of handling the extension UI protocol, see examples/rpc-extension-ui.ts which pairs with the examples/extensions/rpc-demo.ts extension.