Skip to content
/

opcode

opcode · getAsterisk/opcode · ★ 22k · last commit 2025-10-16

Primitive shape 3 total
Subagents 3
00

Summary

opcode — Summary

opcode (formerly "Claudia") is a cross-platform Tauri 2 desktop application that wraps Claude Code's CLI in a visual command center, adding project/session browsing, custom CC Agent authoring, usage analytics, MCP server management, and a timeline/checkpoint system for branching session history.

Problem it solves: Claude Code ships only a terminal interface; opcode provides a visual layer that makes session history navigable, agent creation point-and-click, cost tracking real-time, and code checkpointing visual — without requiring the user to understand JSONL internals or CLI flags.

Distinctive trait: The CC Agent system lets users define named agents as JSON files (*.opcode.json) with a system prompt, model, icon, and default task; agents run as isolated background subprocesses and are tracked in an execution history database. This is the closest thing to a GUI-native "agent IDE" for Claude Code.

Tech stack: Tauri 2 (Rust backend) + React 19 + TypeScript + Tailwind + Zustand; the Rust layer handles Claude process spawning, checkpoint diffing, MCP server testing, and persistent SQLite storage via commands/ modules.

Target audience: Individual Claude Code users who prefer a desktop GUI over the terminal, teams wanting shared agent libraries and usage dashboards.

Production-readiness: v0.2.1, AGPL-3.0, 21,948 stars; last pushed October 2025. The project transitioned from the name "Claudia" (kept as forks at basilisk001/claudia etc.) to "opcode" at some point; both repos carry the same README and feature set.

differs_from_seeds: Unlike any of the 11 seeds (all of which are methodology/skill/command packs), opcode is a pure visual GUI shell — it adds no prompting methodology, no skills, no hooks, and no slash-commands. The closest architectural cousin would be Archetype 4 (markdown-scaffold, zero primitives) but inverted: instead of structured text files, it is a structured desktop app. Compared to claude-conductor (Archetype 4), opcode adds interactive process management, checkpoint branching, and cost analytics but subtracts the methodology layer entirely.

01

Overview

opcode — Overview

Origin

opcode is an independent developer project by @getAsterisk and team, originally named "Claudia." The README carries a disclaimer: "This project is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC. This is an independent developer project using Claude."

The repository was created June 19, 2025 under winfunc/opcode (canonical), and the getAsterisk/opcode URL points to the same repository. Numerous forks preserve the original "claudia" branding. The project gained 21,948 GitHub stars — notable for a relatively early stage project.

Philosophy

opcode approaches Claude Code as an operator problem, not a prompting problem. Rather than injecting methodology into the agent's context (like superpowers or BMAD), opcode builds an operating environment around Claude Code that surfaces what the CLI hides:

  • Which sessions ran, when, and how much they cost
  • What each session changed (diff viewer, checkpoint branches)
  • What agents are available and how they performed

The Discord community and "follow for early access to asteria-swe-v0" phrasing suggest the team views opcode as a launch vehicle for a commercial SWE product (asteria).

Manifesto-style positioning

From the README:

"Think of opcode as your command center for Claude Code - bridging the gap between the command-line tool and a visual experience that makes AI-assisted development more intuitive and productive."

The feature list emphasizes visual context over workflow discipline: session metadata at-a-glance, branching timelines, visual diff viewers, and usage charts. There is no equivalent to a spec file, a plan file, or an approval gate.

Naming history

The project launched publicly as "opcode" but earlier commits, fork READMEs, and the website claudiacode.com all use the "Claudia" branding. The rename likely coincided with rebranding for the broader asteria-swe product roadmap.

02

Architecture

opcode — Architecture

Distribution

Desktop application built with Tauri 2. At analysis time (v0.2.1), binaries were "published soon" — users must build from source.

Build requirements:

  • Rust toolchain
  • Bun (latest)
  • Git
  • Claude Code CLI (separately installed)
  • macOS 11+, Windows 10/11, Ubuntu 20.04+

Directory tree (key paths)

opcode/
├── src/                          # React frontend (TypeScript)
│   ├── App.tsx
│   ├── components/               # UI component library
│   ├── contexts/                 # React context providers
│   ├── hooks/                    # Custom hooks
│   ├── services/                 # API service layer
│   ├── stores/                   # Zustand state stores
│   └── types/                    # TypeScript types
├── src-tauri/                    # Rust backend (Tauri)
│   ├── src/
│   │   ├── main.rs               # Tauri builder + plugin init
│   │   ├── checkpoint/           # Session versioning logic
│   │   ├── commands/
│   │   │   ├── agents.rs         # CC Agent CRUD + execution
│   │   │   ├── claude.rs         # Claude subprocess management
│   │   │   ├── mcp.rs            # MCP server operations
│   │   │   ├── proxy.rs          # Proxy settings
│   │   │   ├── storage.rs        # SQLite operations
│   │   │   └── usage.rs          # Analytics queries
│   │   ├── claude_binary.rs      # Claude CLI path resolution
│   │   └── process.rs            # Process registry
│   └── tauri.conf.json           # App config (title, CSP, permissions)
├── cc_agents/                    # Example bundled CC Agent templates
│   ├── git-commit-bot.opcode.json
│   ├── security-scanner.opcode.json
│   └── unit-tests-bot.opcode.json
├── package.json                  # Frontend deps (React, Radix, Recharts...)
└── web_server.design.md          # Architecture design notes

Data flow

  1. Session reading: Rust backend reads ~/.claude/projects/**/*.jsonl and parses them into structured session models; frontend renders via React
  2. Agent execution: User creates/selects a CC Agent (JSON config); Rust spawns claude subprocess with the agent's system prompt; output streams to frontend via Tauri events
  3. Checkpoints: Rust monitors filesystem state at checkpoint moments; stores diffs in SQLite; frontend shows branching timeline with get_checkpoint_diff
  4. MCP management: Backend calls Claude CLI's mcp subcommands and reads/writes ~/.claude/claude_desktop_config.json
  5. Usage analytics: SQLite queries aggregated by model/date/project, rendered via Recharts

Required runtime

  • Claude Code CLI (authenticated)
  • No Python, no Node server, no cloud backend — fully local

Target AI tools

  • Claude Code only (reads ~/.claude/ structure, spawns claude binary)
03

Components

opcode — Components

opcode ships no Claude Code primitives (commands, skills, hooks, MCP servers). Its components are desktop UI modules and Rust backend modules.

Rust backend commands (tauri IPC)

agents.rs — CC Agent system

  • create_agent — Create a new CC Agent with name, icon, model, system_prompt
  • list_agents — List all saved agents
  • get_agent — Fetch single agent by ID
  • update_agent / delete_agent — CRUD
  • execute_agent — Spawn Claude subprocess with agent config on a project
  • import_agent / export_agent — Import/export .opcode.json files
  • import_agent_from_github / fetch_github_agents — GitHub agent marketplace
  • list_agent_runs / get_agent_run — Execution history
  • get_live_session_output / stream_session_output — Real-time streaming
  • kill_agent_session — Terminate running agent

claude.rs — Session management

  • execute_claude_code / continue_claude_code / resume_claude_code — Start/resume sessions
  • list_projects / get_project_sessions — Project/session enumeration
  • load_session_history — Load JSONL transcript
  • track_session_messages — Message tracking
  • create_checkpoint / restore_checkpoint / fork_from_checkpoint — Versioning
  • list_checkpoints / get_checkpoint_diff — Diff viewer
  • read_claude_md_file / save_claude_md_file — CLAUDE.md editor
  • get_claude_settings / save_claude_settings — Settings management
  • get_hooks_config / update_hooks_config — Hooks viewer

mcp.rs — MCP server management

  • mcp_add / mcp_remove / mcp_list — Server CRUD
  • mcp_test_connection — Connectivity test
  • mcp_add_from_claude_desktop — Import from Claude Desktop config
  • mcp_serve / mcp_get_server_status — Runtime management

usage.rs — Analytics

  • get_usage_stats — Aggregate totals
  • get_usage_by_date_range — Time-range queries
  • get_session_stats — Per-session breakdown
  • get_usage_details — Detailed model/token breakdown

storage.rs — SQLite operations

  • storage_execute_sql / storage_read_table / storage_list_tables
  • storage_insert_row / storage_update_row / storage_delete_row
  • storage_reset_database

Example CC Agent files (bundled)

git-commit-bot.opcode.json

  • Purpose: Analyze git diff, write Conventional Commits message, push changes
  • Model: sonnet

security-scanner.opcode.json

  • Purpose: Scan codebase for security vulnerabilities

unit-tests-bot.opcode.json

  • Purpose: Multi-phase test generation — spawns 6 sub-agents (Analyzer, Planner, Writer, Verifier, Optimizer, Docs Writer) using Claude's Task tool
  • Model: opus

Frontend modules (src/)

Module Purpose
services/ IPC bridge to Tauri backend
stores/ Zustand global state (sessions, agents, settings)
components/ UI components (session viewer, diff viewer, agent builder, timeline)
contexts/ React context (theme, settings)
05

Prompts

opcode — Prompts

opcode ships no methodology prompts, skills, or hooks. Its "prompts" are the system prompts embedded in example CC Agent .opcode.json files bundled in cc_agents/.

Excerpt 1 — unit-tests-bot.opcode.json (full system_prompt)

Prompting technique: Hierarchical task decomposition with explicit sub-agent spawning instructions. Uses <task_spawn> XML tags to delimit each phase and tells the agent to call the Task tool with precise instructions. This is the "task-tool-spawn" subagent definition format.

{
  "agent": {
    "name": "Unit Tests Bot",
    "model": "opus",
    "system_prompt": "# Unit Tests Generation Agent\n\n<role>\nYou are an autonomous Unit Test Generation Agent ...\n</role>\n\n<primary_objectives>\n1. Analyze the existing codebase structure ...\n5. Ensure 100% critical path coverage and >80% overall code coverage\n</primary_objectives>\n\n<workflow>\n\n## Phase 1: Codebase Analysis\n<task_spawn>\nSpawn a **Codebase Analyzer** sub-agent using the `Task` tool with the following instruction:\n```\nAnalyze the codebase structure and extract:\n- Programming language(s) and frameworks\n- Existing test framework and patterns\n...\n```\n</task_spawn>\n\n## Phase 2: Test Planning\n...\n## Phase 3: Test Generation\n...\n## Phase 4: Test Verification\n...\n## Phase 5: Coverage Optimization\n...\n## Phase 6: Documentation Generation\n</workflow>"
  }
}

Key technique: XML-sectioned role + objectives + 6 <task_spawn> phases. Each phase spawns a named sub-agent via Task tool with verbatim instructions. Includes a <final_checklist> with checkbox items as self-verification.

Excerpt 2 — git-commit-bot.opcode.json (full system_prompt)

Prompting technique: Sequential step instruction with conditional branching for merge conflicts. Uses numbered lists and <task>, <instructions>, <notes> XML tags.

{
  "agent": {
    "name": "Git Commit Bot",
    "model": "sonnet",
    "system_prompt": "<task>\nYou are a Git Commit Push bot. Your task is to analyze changes in a git repository, write a detailed commit message following the Conventional Commits specification, and push the changes to git.\n</task>\n\n<instructions>\nFirst, check if there are commits in the remote repository that have not been synced locally:\n1. Run `git fetch` ...\n2. Check if the local branch is behind the remote ...\n3. If there are unsynced commits from the remote:\n   - Perform a `git pull` ...\n   - If merge conflicts occur:\n     a. Carefully analyze the conflicting changes\n     b. Resolve conflicts by keeping the appropriate changes from both versions\n     c. Mark conflicts as resolved using `git add`\n     d. Complete the merge\n4. Only proceed with the following steps after ensuring the local repository is up-to-date\n\nAnalyze the changes ...\n\nBased on your analysis, write a commit message following the Conventional Commits specification:\n1. Use one of the following types: feat, fix, docs, style, refactor, perf, test, or chore\n...\n</instructions>\n\n<notes>\n- Replace [branch_name] with the appropriate branch name ...\n- When resolving merge conflicts, prioritize maintaining functionality ...\n</notes>"
  }
}

Key technique: XML-tagged sections (<task>, <instructions>, <notes>) with numbered procedure lists. The <notes> section provides behavioral guardrails and fallback rules.

Observation

Both agents use XML tags (not markdown headers) for structural separation — a prompting pattern Anthropic's own documentation recommends for Claude models. The unit-tests-bot demonstrates "agentic orchestration via prompt" where the agent's system prompt explicitly scripts the multi-agent topology it should create at runtime.

09

Uniqueness

opcode — Uniqueness & Positioning

differs_from_seeds

opcode is architecturally unlike all 11 seed frameworks:

  • vs. superpowers / BMAD / spec-driver (Archetype 1): Those are skill packs that inject methodology into the agent's workflow. opcode adds no methodology — it is a viewport onto the workflow Claude already runs.
  • vs. spec-kit / openspec (Archetype 2): Those ship commands + skills with matching pairs. opcode ships no commands, skills, or hooks of any kind.
  • vs. claude-flow / taskmaster-ai / ccmemory (Archetype 3): Those embed MCP servers with tools that extend what Claude can do. opcode has no MCP server.
  • vs. claude-conductor / agent-os (Archetype 4): These are markdown-scaffold systems — the value is structured text files that shape agent behavior. opcode is the opposite: a rich interactive GUI with no behavioral overlay.
  • vs. kiro (Archetype 5): kiro is a closed-source IDE with proprietary primitives. opcode is an open-source companion app that wraps the Claude Code CLI rather than replacing it.

opcode is best described as Archetype 0: the visual shell — a category the seed taxonomy did not need because none of the seeds are desktop apps.

Positioning

opcode occupies the gap between Claude Code (terminal-only) and a full IDE. It targets:

  • Users who dislike raw terminal interfaces
  • Teams wanting shared cost visibility
  • Users who want visual session replay and checkpoint branching without writing JSONL parsers

The CC Agent marketplace concept (GitHub import) suggests an eventual platform play where agent definitions are distributed and discovered like plugins.

Observable failure modes

  1. No methodology: Users expecting a workflow framework will be disappointed — opcode is an organizer, not an advisor.
  2. CLI dependency: If Claude Code CLI breaks, is rate-limited, or changes its JSONL format, opcode breaks with it.
  3. AGPL license: The AGPL-3.0 license is restrictive for commercial use; teams wanting to embed opcode must comply with copyleft terms.
  4. Star inflation risk: 21k stars with 14 contributors and no published binaries at v0.2.1 suggests viral Reddit/HN attention before production-readiness.
  5. Telemetry: CSP includes posthog.com — user sessions and interactions are analytics-tracked.
  6. Checkpoint storage growth: SQLite-based checkpoints with no TTL policy could consume significant disk space on long-running projects.
04

Workflow

opcode — Workflow

opcode does not prescribe a development workflow or methodology. It is a session management interface. Below is the user interaction flow:

User Interaction Flow

Session Management

Launch opcode → Welcome Screen → Choose "Projects" or "CC Agents"
    ↓ Projects path
List Projects → Select Project → View Session History
    → Resume Session (launches claude subprocess)
    → Start New Session
    → View Session Details (JSONL rendered as conversation)

### Timeline & Checkpoints
Create Checkpoint → Named snapshot of current file state
    → View Timeline (branching graph)
    → Restore Checkpoint (reverts files)
    → Fork from Checkpoint (new branch)
    → Diff Viewer (see changes between checkpoints)

CC Agent Workflow

CC Agents → Create Agent
    → Set name, icon, model, system_prompt, permissions
    → Save as .opcode.json
    → Execute Agent on project
        → Background subprocess spawned
        → Real-time output streamed to UI
        → Execution history logged to SQLite

Usage Analytics

Menu → Usage Dashboard
    → Token usage by model/project/date
    → Cost breakdown
    → Export data

MCP Management

Menu → MCP Manager
    → Add server (manual JSON or Claude Desktop import)
    → Test connection
    → Manage per-project vs global configs

Artifacts

Artifact Location Purpose
CC Agent definitions ~/.opcode/agents/ or project dir Agent configs
Checkpoint snapshots SQLite DB Session versioning
Usage data SQLite DB Analytics
Session transcripts ~/.claude/projects/**/*.jsonl Read-only source

Approval gates

None — opcode does not impose any gates. The user drives all actions via GUI.

Phases

opcode has no phases. All features are available at any time from the GUI.

06

Memory Context

opcode — Memory & Context

State storage

opcode uses two storage mechanisms:

SQLite database (via Tauri plugin)

  • Agent definitions: All CC Agents (name, system_prompt, model, icon, permissions)
  • Execution history: Every agent run with status, timestamps, metrics
  • Checkpoint state: File snapshots and diff data for session versioning
  • Usage data: Token counts, costs, model, project, date — for analytics dashboard

Filesystem (read-only for sessions)

  • Session transcripts: Reads ~/.claude/projects/**/*.jsonl — opcode does not write these
  • CLAUDE.md files: Read and written via the built-in editor
  • MCP configs: Reads/writes ~/.claude/claude_desktop_config.json

Persistence scope

  • Global: SQLite DB lives in the app data directory (global, not per-project)
  • Session transcripts: Per-project, owned by Claude Code CLI

Context compaction

opcode does not handle context compaction — that is the Claude Code CLI's responsibility. opcode reads whatever JSONL files Claude wrote.

Cross-session handoff

No programmatic handoff. The user can visually inspect past sessions and manually resume them, which opens the session in Claude Code with existing context. The checkpoint/fork system provides a form of session branching but does not inject context automatically.

Audit log

The execution history SQLite table serves as an audit log for all agent runs: agent name, project, model, start/end times, exit status, and token metrics.

07

Orchestration

opcode — Orchestration

Multi-agent support

opcode supports a basic form of multi-agent orchestration through its CC Agent system: the unit-tests-bot example agent spawns 6 sequential sub-agents via Claude's Task tool (Codebase Analyzer → Test Planner → Test Writer × N → Test Verifier → Coverage Optimizer → Documentation Writer). This is runtime orchestration scripted inside the agent's system prompt, not a built-in opcode feature.

Orchestration pattern

Sequential (for multi-phase agents). The user launches one top-level agent; the agent's system prompt dictates the multi-step delegation pattern. opcode itself does not orchestrate — it delegates to the Claude model's own agent loop.

Isolation mechanism

None. Agents run in the same filesystem context as the user. There is no container, sandbox, or worktree isolation.

Execution mode

Interactive GUI. The user launches agents, monitors progress via the streaming output panel, and can kill sessions. There is no continuous/daemon loop — each agent run is discrete.

Multi-model support

No built-in multi-model routing. Users select a model per agent (sonnet, opus, etc.) but opcode does not route tasks to different models based on type.

Consensus mechanism

None.

Auto-validators

None built into opcode. The unit-tests-bot agent includes a <verification_steps> section in its prompt that instructs the agent to self-verify, but this is prompt-level, not framework-level.

Audit log

SQLite execution history table logs all agent runs with status and metrics. The Rust ProcessRegistryState tracks running processes at the OS level.

08

Ui Cli Surface

opcode — UI & CLI Surface

Desktop application

opcode IS the UI surface — the entire value is the desktop app. Key screens:

Screen Function
Welcome Choose Projects or CC Agents entry point
Project Browser List all ~/.claude/projects/ with session counts
Session History Sessions per project with first message + timestamp
Session Detail Full JSONL rendered as conversation with tool calls
CC Agent List Library of saved agents with icons
Agent Builder Form UI for name, icon, model, system prompt, permissions
Agent Execution Real-time streaming output + kill button
Execution History Log of all past agent runs with metrics
Usage Dashboard Recharts graphs for cost/tokens/model/date
MCP Manager Server list with add/remove/test
Timeline Branching checkpoint graph
Checkpoint Diff Side-by-side file diff viewer
CLAUDE.md Editor Split editor with live preview

CLI binary

None. opcode is a GUI-only application with no CLI companion.

IDE integration

None. opcode opens projects detected from ~/.claude/projects/ and can trigger claude subprocess but has no VS Code, Cursor, or Zed plugin.

Observability

  • Real-time streaming output for running agents (via Tauri events)
  • Execution history in SQLite (queryable via storage_execute_sql IPC command)
  • Usage analytics dashboard with cost/token breakdown
  • Debug: The app_data_dir/debug/ path is referenced in source (mirrors Claude Code's debug log location)

Tauri window configuration

  • Window: 800×600, no OS decorations, transparent background, macOS vibrancy effect
  • CSP includes posthog.com for analytics (telemetry)
  • File system scope: $HOME/** read+write

Distribution

Build from source (Bun + Rust + Tauri). Signed release binaries described as "coming soon" at time of v0.2.1.

Related frameworks

same archetype · same primary tool · same memory type

Goose (Block/AAIF) ★ 46k

General-purpose AI agent (not just code) with security-first tool inspection, recipe-based shareable configurations, and 15+ LLM…

Vibe Kanban ★ 27k

Eliminate the overhead of planning, switching between agent terminals, and reviewing diffs by providing a single web dashboard…

1Code ★ 5.5k

Cursor-like desktop experience for Claude Code and Codex with cloud background agents, event-driven automations, and a full…

Crystal (stravu) ★ 3.1k

Manage multiple parallel AI coding sessions in isolated git worktrees from a single desktop GUI.

Maestro (RunMaestro) ★ 3.0k

Orchestrate unlimited parallel AI agent sessions with a keyboard-first desktop app including Group Chat coordination and Auto Run…

AgentsMesh ★ 2.1k

Multi-tenant workforce platform that gives every team member a squad of AI coding agents coordinated through channels, pod…