Command System
The Command System lets users quickly trigger specific features using /command syntax. Type text starting with /, and the frontend automatically identifies the command name and arguments, dispatching them to the corresponding handler — as efficient as a terminal command line.
Command Handling
Section titled “Command Handling”Commands are dispatched through different handling modes based on their implementation:
| Handling Mode | Description | Example |
|---|---|---|
| Frontend Direct Handling | Frontend switch case matches the command name, executes local logic or sends RPC to the backend | /compact: Frontend sends RPC to call the backend compression API |
| Special Prefix Handling | Frontend recognizes command prefix, generates a special message (isMeta: true) for the AI | /goal: Generates a goal-setting message for AI to understand the task objective |
| Custom Commands | Host application registers custom commands via API; frontend matches and calls the registered handler function | Any custom command registered by the host |
Command Parsing Flow
Section titled “Command Parsing Flow”Parsing rules:
- The first word after
/is the command name - The rest is the arguments (passed as raw string)
- Command name matching priority: exact match > alias match
Commands come from two sources: system built-in commands (/compact, /export, /goal, /persona) and custom commands registered by the host application via API.
/compact — Manual Compression
Section titled “/compact — Manual Compression”Exposes the existing auto-compression capability, allowing users to proactively trigger context compression to free up token space.
| Parameter | Required | Description |
|---|---|---|
| Custom instruction | No | Custom summarization instruction that overrides the default compression prompt |
| Key Rule | Description |
|---|---|
| Asynchronous Execution | Compression goes through a queue, does not block the current conversation |
| Completion Notification | Pushes a notification via the Live channel when compression completes |
| Duplicate Prevention | Repeated triggers are blocked while compression is in progress |
| Result Feedback | Returns {Success: true} upon completion, with notification pushed via the Live channel |
/export — Export Session
Section titled “/export — Export Session”Export the current session’s conversation history as a standalone HTML file for offline reading, archiving, or sharing. Pure frontend implementation — no server involvement required.
Export Options
Section titled “Export Options”The dialog provides the following configuration:
| Option | Type | Default | Description |
|---|---|---|---|
| Message limit | Slider | 200 | Export the most recent N messages. Step size 100, max 2000. Set above current message count to export all |
| Include tool calls | Yes / No | No | Whether to include toolcall_input and toolcall_output messages |
| Include thinking | Yes / No | No | Whether to include thinking messages |
Exported Content
Section titled “Exported Content”The generated HTML file contains:
| Content | Description |
|---|---|
| Session metadata | Title, creation time, message count, token statistics (input/output/cache read/cache write/total cost) |
| User messages | Expanded, rendered as Markdown + syntax-highlighted code |
| Assistant replies | Expanded, rendered as Markdown + syntax-highlighted code |
| Tool calls | Collapsed (optional), expandable to view parameters and results |
| Thinking process | Collapsed (optional), expandable to view AI reasoning |
File Naming
Section titled “File Naming”Filename format: rtc-{session-title}-{YYYY-MM-DD}.html
- Illegal filename characters are replaced with hyphens
- Title is truncated to 50 characters
- Spaces are replaced with hyphens
Message Filtering Rules
Section titled “Message Filtering Rules”| Rule | Description |
|---|---|
| Exclude streaming messages | Automatically filters out incomplete messages with streaming: true |
| Empty session check | Shows error when the current session has no messages |
| Content filtering | Filters tool call and thinking messages based on user options |
| Count truncation | Keeps the most recent N messages when exceeding the limit |
💡 Design principle: Export is a fully offline, frontend-only operation — the HTML file embeds all styles and can be viewed without internet access. Markdown rendering uses
marked+highlight.js+DOMPurify, consistent with the component’s internal message rendering pipeline.
/persona — Role Switching
Section titled “/persona — Role Switching”Switch the AI’s role/persona for the current session. After entering a role name, the AI adopts that role’s vocabulary, priorities, and typical reasoning patterns until the session ends or the command is overridden.
/persona <role-name>| Parameter | Required | Description |
|---|---|---|
| Role name | Yes | Role description, e.g. senior-backend-engineer, product-manager, security-expert. Enter default to revert to default behavior |
How It Works
Section titled “How It Works”/persona is a session-scoped command — it stays active for the entire session after being triggered. The backend maintains the persona through two phases:
| Phase | Description |
|---|---|
| Trigger prompt | On the first invocation, a system message is injected to activate the role |
| Sustain prompt | On subsequent turns, a reminder is injected to keep the AI in character |
| Key Rule | Description |
|---|---|
| Session-scoped | The persona is only valid for the current session; it expires when the session closes |
| Overridable | Enter a new /persona command to switch roles |
| Reversible | Use /persona default to revert to default behavior |
/loop — Loop Execution
Section titled “/loop — Loop Execution”Users describe tasks that need to be executed in a loop using natural language. The Agent understands the intent and creates a scheduled loop task that runs automatically at fixed intervals.
/loop <task description>| Parameter | Required | Description |
|---|---|---|
| Task description | Yes | Natural language description of the loop task, e.g., check deployment status every 5 minutes |
How It Works
Section titled “How It Works”/loop creates a scheduled loop task through the LLM built-in tool createLoop. Once created, the system automatically triggers new Turns at fixed intervals to perform the operations described in the task, until the user cancels.
| Related Tool | Description |
|---|---|
createLoop | Create a scheduled loop task |
cancelLoop | Cancel a loop task |
completeLoop | Mark a loop task as completed |
listLoops | List all loop tasks in the current session |
pauseLoop | Pause a loop task |
resumeLoop | Resume a paused loop task |
/goal — Goal-Driven
Section titled “/goal — Goal-Driven”The user sets a completion condition, and the AI works continuously until the condition is met. During execution, the AI self-assesses whether the goal has been achieved, declaring completion via the completeGoal tool, or cancelling via the cancelGoal tool.
Command Interaction Model
Section titled “Command Interaction Model”/goal uses special prefix handling: after the user types /goal <condition>, the frontend sends it as a regular message. The backend detects the prefix through the command registry (GoalWorkflow) and injects a system prompt to guide the AI into the goal-setting workflow.
Unlike commands with frontend direct handling like /compact, /goal does not execute an operation immediately — it triggers a multi-turn conversation workflow:
| Comparison | /compact | /goal |
|---|---|---|
| Handling mode | Frontend sends RPC directly | Special prefix → system prompt injection |
| Execution timing | Immediate | AI interprets and guides multi-turn interaction |
| User confirmation | Not required | Required to confirm the goal condition |
Core Flow
Section titled “Core Flow”Core Mechanism
Section titled “Core Mechanism”During execution, the AI continuously evaluates the goal’s completion status. When the AI determines the goal has been achieved, it calls the completeGoal tool to declare completion; when the AI determines the goal cannot be achieved or needs to be cancelled, it calls the cancelGoal tool.
| Component | Responsibility |
|---|---|
| AI | Performs work and self-assesses whether the goal is achieved, declaring state changes via completeGoal/cancelGoal tools |
Goal as an Independent Entity
Section titled “Goal as an Independent Entity”A Goal is an entity independent of the Session, with its own lifecycle:
| State | Description |
|---|---|
Active | Goal is active, AI continues working |
Completed | AI declared condition achieved via completeGoal |
Cancelled | User manually cancelled |
Exhausted | Exceeded maximum round limit (default: 50 rounds) |
Status Display
Section titled “Status Display”| Element | Description |
|---|---|
| Status Bar | Displays a summary of the current goal condition |
| Overlay Panel | Shows rounds executed, cumulative tokens, and runtime |
| Completion Notification | Pops up a notification when the goal is achieved |
Related Commands
Section titled “Related Commands”| Command | Description |
|---|---|
/goal | Display current goal |
/goal <condition> | Set a goal |
/goal clear | Clear the goal |
| Key Rule | Description |
|---|---|
| Single Goal | Only one active goal per session |
| Session-scoped | Goals are only valid within the current session |
| Safety Limit | Maximum round limit (default: 50 rounds) to prevent runaway execution |
Frontend Interaction
Section titled “Frontend Interaction”After command execution, the frontend provides feedback to the user via Toast notifications.
Command Feedback:
| Scenario | Feedback Method |
|---|---|
| Command executed successfully | Toast notification ✅ |
| Command execution failed | Toast error message ❌ |
Next Steps
Section titled “Next Steps”- Skill System — Learn how the host registers custom functions to extend AI capabilities
- LLM Built-in Tools — Learn about the built-in tools available to the AI during conversation
- RTC Protocol — Learn about the remote tool calling mechanism behind commands
- Session Management — Learn about the session context in which commands operate