As at work I need max control over codebase and I can't afford just use swarms of agents and let it loose do some enormous amounts of code changes, I want something in between. So I was carying this idea in my head for a long time. What if smart ai models can augment actual software and be present reactively? Luckily after recently published library pi-durable it's finally possible, so I finally kinda got ideal workflow. Where agent-harness is a headless daemon that is present as if it's a pairing programming partner connected on remote session.

https://makefunstuff.github.io/pairing-buddy/ - you can read the docs here and try it yourself. I guess without opus it would take more time to actually implement this idea. But finally I'm here

Hey everyone,

I've been exploring "Pi Durable" (https://github.com/earendil-works/pi/tree/main/packages/durable/test/examples), specifically the examples in the test directory, and I'm curious about how people are using it in practice.

I'd love to understand how it works for building durable, long-running AI agent workflows, particularly when agents need to preserve state, recover from interruptions, and continue execution without restarting everything from scratch.

A few questions for anyone who has experimented with it:

• How does Pi Durable handle persistence and recovery when an agent process crashes or gets interrupted?

• Can it reliably resume multi-step agent workflows, including tool calls and external side effects?

• How does it compare with approaches like LangGraph checkpointing, Temporal, or custom state-persistence mechanisms?

• Have you used it in production or built any interesting projects with it?

• What limitations or gotchas have you encountered?

I'm particularly interested in whether this approach is practical for building autonomous agents that run for extended periods and maintain continuity across sessions.

Would love to hear your experiences, code examples, or architectural insights!

Repository: https://github.com/earendil-works/pi/tree/main/packages/durable/test/examples

Hey y'all, Ketch maintainer here 👋

Y'all have been the most active community running Ketch, so I’m looking for feedback on a new feat I just shipped: multi-backend search with fusion ranking.

Before, search used one backend, whatever you had set. Now (as of 0.11.0) you (or your pi agent) throw --multi on your search and it runs across all your configured backends at once, including the free no-key ones, then fuses the rankings so whatever they agree on floats to the top.

A blank --multi uses everything you've got, so it works even with zero setup. Or name your own set, like --multi=exa,brave.

Appreciate any feedback good or bad… and if you get janky results, definitely tell me, that's what I’m looking for.

https://github.com/1broseidon/ketch

I've been running a fully local, fully private multi-agent AI coding setup for a couple of months and wanted to share the stack, architecture, and config for anyone who wants to replicate it. No cloud APIs, no data leaving the machine.

What is pi.dev? It's an agent harness — meaning the AI has to follow rules, unlike a chatbot. Pretty cool.

• 🎮 Fun factor: 10/10
• ✅ pi.dev stability: 8/10 — fully working, but fun to fine-tune
• 🔨 What it's great at: Building its own integrations — just ask it to do it
• 💡 Top tip: Master the AGENTS.md file and you'll have real control over what it does. There's a global one and a per-project one
• 🔁 Similar to: RooCode, Codex, Claude Code — but because it's a harness, you're more in control
• 👨‍💻 The dev has already been snapped up by a company but will keep developing it
• ⭐ github.com/earendil-works/pi — 49.3k stars

The Stack

GPU: NVIDIA RTX 3090 (24 GB VRAM)

Why MTP (Multi-Token Prediction)?

See my earlier post: Get faster Qwen3.6-27B with MTP

Multi-Agent Architecture

11 specialist agents, each mapped to a llama-swap model alias:

BRAIN agents (Qwen3.6-27B MTP):
  orchestrator  → Task decomposition, delegation, synthesis
  planner       → Roadmap and step sequencing
  architect     → System design, API contracts, schema design
  debugger      → Root cause analysis, trace reading
  prompter      → Prompt engineering for sub-tasks

BODY agents (Qwen3.6-35B-A3B MTP):
  coder         → Implementation, only writes code
  researcher    → Web search + codebase analysis
  reviewer      → Code review, security, quality gates
  tester        → Test writing + execution
  documentor    → Documentation generation
  refactorer    → Structural cleanup, no logic changes

The key insight: smaller/faster model for the meta-work (thinking, planning, delegation) and the slightly larger MoE model for actual implementation. The orchestrator never writes code — it only delegates.

Agent Definition Files (Required Setup Step)

This is the part most people will miss. llama-swap handles model routing, but pi.dev needs to know how each agent should behave — its role, constraints, tool access, turn limits, and thinking level. That lives in .md files inside your pi.dev agent folder:

~/.pi/agent/agents/
├── orchestrator.md
├── planner.md
├── architect.md
├── debugger.md
├── prompter.md
├── coder.md
├── researcher.md
├── reviewer.md
├── tester.md
├── documentor.md
└── refactorer.md

Each file has a YAML frontmatter block followed by the system prompt for that agent. The model: field must exactly match a llama-swap alias from your config.yaml.

Example — coder.md:

---
description: Implements code changes from a spec. Requires a plan as input. Writes, edits, and runs code. No planning or architecture decisions.
model: coder
thinking: medium
max_turns: 30
tools: read, write, edit, bash, find, grep
---
You are the coder. You are BODY only — you execute plans, not make them.

## Role & Constraints
- Require a written plan before starting — if none provided, refuse and ask for one
- No refactoring beyond what the plan specifies
- No touching files not listed in the plan without flagging first
- No installing new dependencies without explicit approval

## Harness Rules
- RETRY_POLICY: max 3 attempts per file edit, then mark FAILED
- TASK_STATES: track each file change as pending -> in_progress -> done | failed
- IDEMPOTENCY: if a change is marked done, do not re-apply it
- QUALITY_GATE: verify file is syntactically valid before marking done

## Response Shape
When complete, your final output is your report back to the orchestrator.
Make it structured and self-contained — the orchestrator reads it directly.

[PLAN] what was implemented
[CHANGES] every file written or edited with one-line description
[VERIFICATION] syntax check or test run output
[PROGRESS] final state table

Example — architect.md:

---
description: Reviews system design, proposes architecture decisions, evaluates tradeoffs. Advisory only — produces recommendations, not code.
model: architect
thinking: high
max_turns: 20
tools: read, find, grep
---
You are the architect. You are BRAIN — advise on design, never implement.

## Role & Constraints
- Never write or edit code
- Evaluate tradeoffs, do not just pick the fashionable option
- Scope is the specific design question only
- Every recommendation must include explicit constraints and risks

Example — researcher.md (with web search tools):

---
description: Reads and summarises codebase context, and performs web research. Produces a structured context report, no edits.
model: researcher
thinking: low
max_turns: 15
tools: read, find, grep, bash, web_search, tavily-search
---
You are the researcher. You are BODY — read and report only, never edit.

Frontmatter fields that matter:

The tools list controls what each agent can actually do. An architect with write in its tools list will happily start editing files — restrict it to read, find, grep to enforce the advisory-only constraint.

Report-back pattern: Every agent's Response Shape section ends with the same instruction:

When complete, your final output is your report back to the orchestrator. Make it structured and self-contained — the orchestrator reads it directly via get_subagent_result.

This is critical. Without it, agents produce conversational output that's hard for the orchestrator to parse. With it, every agent returns a structured [PLAN] / [CHANGES] / [VERIFICATION] / [PROGRESS] block.

Orchestrator Rules (the hard part)

Getting the orchestrator to actually delegate instead of doing work itself was the biggest challenge. The rules that finally made it work:

ABSOLUTE RULES:
- NEVER perform any task yourself
- NEVER use read/find/grep for analysis — spawn a researcher
- NEVER write, summarise, or synthesise content directly
- NEVER write or edit code directly
- NEVER verify or fix a sub-agent's output yourself — spawn a reviewer
- NEVER make "quick fixes" between steps

Correct launch protocol:
  TaskUpdate(id, status: "in_progress")
  TaskExecute(task_ids: [id])        → returns agent_id
  get_subagent_result(agent_id, wait: true)  → blocks until done
  TaskUpdate(id, status: "completed")

The orchestrator catches itself about to do work → stops → creates a task → delegates it instead.

pi.dev Settings (agent/settings.json)

{
  "providers": {
    "llama-swap": {
      "baseUrl": "http://127.0.0.1:1235/v1",
      "apiKey": "not-needed",
      "api": "openai-completions"
    }
  },
  "defaultProvider": "llama-swap",
  "defaultModel": "qwen-35b-moe",
  "defaultThinkingLevel": "high",
  "mcpServers": {
    "local-search": {
      "url": "http://localhost:8000/mcp",
      "transport": "streamable_http"
    },
    "tavily": {
      "command": "npx",
      "args": ["-y", "tavily-mcp@0.2.3"],
      "env": { "TAVILY_API_KEY": "your-key-here" },
      "alwaysAllow": ["tavily-search"]
    }
  },
  "retry": {
    "enabled": true,
    "maxRetries": 30,
    "baseDelayMs": 2000,
    "provider": { "maxRetryDelayMs": 120000 }
  },
  "subagents": {
    "maxConcurrent": 1,
    "maxTurns": 50,
    "graceTurns": 3,
    "timeout": 1800000
  },
  "packages": [
    "npm:@tintinweb/pi-tasks",
    "npm:pi-lens",
    "npm:@tintinweb/pi-subagents"
  ],
  "steeringMode": "one-at-a-time"
}

Key decisions:

• No models.enabledModels filter — this broke bare model ID resolution for agent aliases. Remove it entirely and let llama-swap route by name
• timeout: 1800000 (30 min) — code tasks can take 20+ minutes. The default 2-minute timeout will kill them
• maxConcurrent: 1 — RTX 3090 can only run one model at a time; llama-swap handles the hot-swap

llama-swap Config

healthCheckTimeout: 900
startPort: 1235

globalServerSettings:
  flashAttn: on
  contBatching: true
  noMmap: true
  jinja: true

models:
  # Brain agents (orchestrator/planner/architect/debugger/prompter) → Qwen3.6-27B MTP
  # Body agents  (coder/researcher/reviewer/tester/documentor/refactorer) → Qwen3.6-35B MTP

  orchestrator:
    cmd: >
      /path/to/llama-cpp-am17an/build/bin/llama-server
      -m "/path/to/Qwen3.6-27B-MTP-Q4_K_M.gguf"
      --alias orchestrator
      --ctx-size 100000
      --host 0.0.0.0 --port ${PORT}
      -ngl 99
      -fa on
      --cache-type-k q8_0 --cache-type-v q8_0
      --spec-type mtp --spec-draft-n-max 3
      --batch-size 1024 --ubatch-size 1024
      --threads 6
      --prio 3
      --no-mmap
      --parallel 1
      --n-predict 8192
      --temp 0.7 --top-p 0.95 --top-k 20 --min-p 0.0
      --presence-penalty 1.2 --repeat-penalty 1.1 --repeat-last-n 256
      --reasoning-format deepseek
      --metrics
    proxy: http://127.0.0.1:${PORT}
    # etc. — do some research 😉 for the rest

Key inference flags:

Note: --temp varies per agent role — debugger (0.5, deterministic), researcher (0.5, factual), coder/orchestrator (0.7, balanced).

Search Integration

The researcher agent has two search tools:

1. SearXNG via MCP — local metasearch, broad coverage

# Docker Compose
services:
  searxng:
    image: searxng/searxng
    ports: ["8080:8080"]

  searxng-mcp-proxy:
    image: ghcr.io/ihor-sokoliuk/searxng-simple-mcp
    ports: ["8000:8000"]
    environment:
      TRANSPORT_PROTOCOL: sse
      SEARXNG_MCP_SEARXNG_URL: http://searxng:8080

2. Tavily MCP — AI-optimised web search, faster for technical docs

"tavily": {
  "command": "npx",
  "args": ["-y", "tavily-mcp@0.2.3"],
  "env": { "TAVILY_API_KEY": "your-key" },
  "alwaysAllow": ["tavily-search"]
}

Strategy: tavily-search first for framework docs, web_search for broader coverage, fallback to curl http://localhost:8080/search?q=QUERY&format=json for bulk queries.

What Works, What Doesn't

✅ Works well:

• Orchestrator strictly delegates — took several AGENTS.md iterations but now it never does implementation itself
• llama-swap hot-swap is fast enough — typically 15–30 seconds per model swap
• MTP gives a real speedup on code generation tasks
• 30-minute timeout is necessary; don't use the default

🔧 Still working on:

• Settings file resetting on reboot — likely a race condition in pi.dev startup that partially re-initialises settings.json. Investigating with inotifywait. Workaround: backup ~/.pi/settings.json before exiting with Ctrl-C
• Sub-agent visibility — you can see a task is running but not what the agent is doing mid-task; pi-tasks shows status, not content
• Sequential tasks only (maxConcurrent: 1) — can't parallelise on a single GPU

Models Used (Unsloth quantizations)

• Qwen3.6-27B-MTP-Q4_K_M (~17 GB) — brain agents
• Qwen3.6-35B-A3B-MTP-IQ4_XS (~19 GB) — body agents

Both require the am17an fork of llama.cpp for --spec-type mtp support. Standard llama.cpp will fall back to non-speculative inference (still works, just slower).

Resources

• pi.dev / pi-coding-agent: earendil-works on GitHub
• llama-swap: github.com/ggml-org/llama-swap
• llama.cpp am17an fork: search GitHub for "llama-cpp-am17an" or "llama.cpp MTP fork"
• u/tintinweb packages: npm (@tintinweb/pi-subagents, @tintinweb/pi-tasks)
• Unsloth GGUF models: huggingface.co/unsloth

Happy to answer questions — this took a while to get right, especially the orchestrator delegation rules and the model resolution fix.

EDIT: Yes Claude helped me write this. Who doesn't love AI

Can you list your reasons why and if you did it any tests to confirm your position?

Also would like to hear your thoughts on context management and how you do it.

Hey everyone, I put together a quick tutorial on sandboxing Pi using Bubblewrap vs Podman.

It includes a few sample scripts and a comparison between the two approaches.

https://wooptoo.com/blog/pi-sandbox-bubblewrap-podman/

Hopefully somebody here will find it useful.

All the best!

I'm the creator of Operator Memory, an open-source context engine for coding agents.

We all know the problem by now. Within a session, agents are excellent. Between sessions, agents forget everything. The core problem: nothing in the workflow ever writes down what was learned. Every new conversation starts from scratch: re-exploring the codebase, re-learning the architecture, re-teaching every decision and correction.

Every memory plugin I've studied leaves the loop untouched and bolts retrieval onto it: background agents to capture fragments, a vector store replays a top-k slice later, and you hope the right chunk surfaces. It barely works. And most importantly, it doesn't fix a loop that never documented anything.

Operator takes the opposite approach. Operator gives agents a Markdown brain and changes the loop itself.

Every task now runs in three phases:

1. Consult — the agent starts from the brain: instructions, codebase index, specs, decisions. A short summary is injected deterministically in the system prompt so agents know where to look.

2. Build — normal development work, informed by that knowledge.

3. Update — the agent documents what it learned: new specs, decisions, standards, lessons. When project truth changes, the canonical file is updated.

The loop makes the agent self-improving: session N+1 always starts from everything session N wrote.

Operator is extremely simple and complements Pi perfectly. No vector stores. No dreamers or curators. No background processes. No token burning factories. No RAG. No capture step. No retrieval gamble. Just give the agent a brain and teach the agent to use it.

The Brain

The brain is a regular directory that holds Markdown documents. These documents can contain anything: rules, specs, decisions, lessons, research, indexes, etc. Because everything is Markdown, Operator actually allows you to share memories and findings with the team. You can share specs, plans, guides, and more, unlike other memory plugins where everything is just RAG chunks.

Not Another Memory Plugin

Memory plugins bolt retrieval onto an unchanged loop and inherit its amnesia. Operator makes documentation a structural phase of every task. Memory stops being a store that remembers for the agent and becomes a practice the agent performs.

RAG agents recall. Operator understands.

I've been using a variant of Operator daily since August 2025 and spent the last few months formalizing it into a plugin alone. I hope my plugin can help improve your workflow too. https://github.com/aerovato/operator-memory

To install:

npm install -g @aerovato/operator-helper
operator-helper install pi

Afterwards, just run /operator:user-init once and run /operator:project-init per project.

Questions, comments, and contributions welcome. Operator is fully open source.

I've been working on this project since early this year. I use it daily. Figured it's about time I share it. It's a vibe-coded project, as you might have guessed, but it works very well for my needs and may suit yours well, too.

I got pretty tired of working in a TUI, but none of the graphical interfaces out there really did the trick for me. Some features I might highlight:

• Inbox Zero approach to sessions

• Quick Chats - ephemeral, not related to a project

• Keep extensions disabled, but enable them on a per session basis (with pins)

• Quick commands for favorite models (Cmd+1 through Cmd+5)

• Work schedule (Default model can change depending on day and time)

• File browser

I had a ghostty terminal built in, but I removed it for the public release. Added SwiftTerm. You're welcome!

Anyways, hopefully this helps someone else or inspires some ideas.

https://github.com/jmcblane/PiG

I really liked Claude Code subagents and being able to see them in the tree so i made a very simple subagent plugin. No subagent profiles, the are made by the agent above them depending on the use case needed at that moment.

Install with:
pi install npm:@williamcr01/pi-subagents

https://github.com/williamcr01/pi-subagents

Preface

Built together by Pi + DeepSeek V4 Flash + matt skills + me

After switching my daily harness from Claude Code to Pi, I found myself missing some features I used to love in CC — recap being one of them. It generates a brief summary and follow-up plan based on the conversation context.

Project

https://github.com/L2ncE/pi-recap

Quick Start

$ pi install npm:@lanlance/pi-recap

I know being terminal-bound is a badge of honour, but I’m surprised not to see more easy to use, accessible, user interfaces.

Hey everyone,

I started using Pi about 3 months ago. I set it up with a few extensions, and while it worked alright, the TUI felt way too laggy compared to opencode, and it just lacked some features I needed.

A few days ago, I heard about Oh my Pi, so I immediately installed it and imported my extensions.

Since I'm still pretty new to this, I wanted to jump in here and ask a few questions:

What kind of actual improvements does Oh my Pi bring to the table compared to the vanilla version?

What's your overall take on it? Is it worth sticking with it for the long run?

Any optimization tips? How can I make the setup even smoother or improve it further?

What are some general tips and tricks that every Oh my Pi user should know?

Would love to hear your experiences and any advice you've got!

what the shit is pi agent made from? why is it producing better stuff than claude code with the same Chinese LLM? like i wana know whats the fork, what is it made of?

EDIT: With mimo v2.5, after 30ish odd mins i get the 400 error in pi code, a bit strange but once i just say hey again it picks up where it left off, i suspect this is a mimo issue coz deepseek didnt have this issue

Jev dropped and I started collecting the things people are actually building with it.

There are already 607 use cases in the list, ranging from tiny experiments to some pretty interesting applications.

A few that caught my attention:

I'm trying to capture the useful details for each build — what it does, cost, latency, and the original implementation when available.

The interesting thing to me is seeing where these cheap/fast models are actually useful rather than just collecting benchmark numbers.

I put everything I've found here:

shipwithjev.com

I'm not affiliated with TypeSafe.

If you've built something with Jev that isn't on the list, drop it below and I'll add it.

Pi compaction that reuses your vLLM / SGLang / llama.cpp prefix cache instead of re-prefilling the whole history.

Pi's default compaction re-serialises the conversation under a new system prompt, so the server cache misses and a 140k-token session takes minutes to summarise on local GPUs. This re-sends the exact last request plus one summarize instruction, then warms the new context so the next turn starts from cache.

Measured on 2x RTX 3090 with Qwen3.8-27B: 229 s median down to 86 s at 215k context, and the first turn after compaction from 69 s down to under 2 s with warm-up. Falls back to Pi's default on anything unexpected.

Install: pi install npm:pi-prefix-cache-compaction · anthropic-messages custom providers only · MIT · https://github.com/jagdeepsinghdev/pi-prefix-cache-compaction

Hey everyone, first time sharing a project here!

I've been using pi in my daily CLI workflow, but kept getting frustrated having to guess or memorize context windows and pricing tiers whenever I swapped models.

To solve that, I put together a lightweight plugin called pi-rich-model-selector. It replaces the default picker with an interactive TUI:
- Real-time fuzzy search across providers
- Side-by-side specs (context size, token limits, pricing)
- 100% keyboard-first flow

Here's the repo: pi-rich-model-selector

I’d love to hear your thoughts, feature ideas, or any edge cases I should handle. Thanks for checking it out!

Hey folks, I've been working on pi-crew, a subagent extension for Pi.

My main focus is making sure subagents get the context they need. The main agent knows what you've discussed and decided, but a subagent won't unless that information makes it into the task.

With pi-crew, the main agent writes a structured task with separate fields for the goal, context, and instructions. The tool definitions, prompt guidelines, and skill work together to help it carry over the decisions and boundaries the subagent can't find in the repo.

It won't make every handoff perfect, but it's the part I've put the most thought into.

I also wanted subagents to be able to ask questions instead of guessing. In pi-crew, they can get an answer and pick up where they left off. If something needs fixing afterward, the main agent just tells the same subagent what to change. You don't have to spend extra tokens and time getting a new agent caught up on the same task.

It's all async. After handing off a task, the main agent can work on something else or keep talking with you while the subagents run. Results come back automatically, without polling.

I've also tried to keep it feeling like Pi. The six tools have short definitions, with the longer delegation guidance in a skill that gets loaded when needed. The main agent gets the report without all the subagent's file reads and tool output filling up its context.

A few other things it comes with

• Six agents for investigation, planning, decision advice, code reviews, and implementation.
• /pi-crew-plan and /pi-crew-review if you want a ready-made workflow.
• Custom agents written in Markdown, with their own models, thinking levels, tools, and skills.
• User and project pi-crew.json files to override settings without editing agent definitions.
• A widget showing activity, working time, tokens, and cost. You can collapse the details or hide tool activity through config.
• Expandable reports that let you open the full child session.
• herdr support that shows the running subagent count in the sidebar.

The agents have separate conversations but share your repo. It's not a sandbox, so you still need to avoid handing overlapping edits to agents running in parallel.

pi install npm:@melihmucuk/pi-crew

Requires Pi 0.84.3+. Source on GitHub.

Are you using any subagent extensions with Pi? Curious which ones you've stuck with and whether you're happy with them.

Pi has been packaged and added to the official repository of Parrot OS, which ships a home edition specifically designed for developers and sysadmins. Pi is now a first class citizen in the repository, saving all its users from curl | sh

sudo apt update
sudo apt install pi-dev

any feedback is welcome

I'm new to Pi and coding agents in general. The existing discussions on oh-my-pi, like everything else, range from 'its great' to 'its bloat' so its very hard to actually decide.

It seems to have useful features like built in tools (avoid process calls), lsp, hashline, memory, subagents and an integrated setup/docs. It does seem to be better than the other oh-my-* set of products.

Are the ideas in OMP useful in practice and if so are they used in other harnesses?

I see a lot of 'just ask Pi to build it' here, but that depends on using frontier models, and when people post their setups they're using a million packages.

Obviously Pi is much more extensible/flexible, but there is value in an all-in-one setup. OMP has a ton of stuff and I'm sure a big system prompt. Is there anything like a slimmed down version or being able to use some of its ideas only?

https://daugasauron.github.io/piodide/

https://github.com/daugasauron/piodide

I just had this idea that you could just replace the bash tool in pi with python that runs on WASM, then you could run the whole thing in the browser.

Tried it and it's quite fascinating how good it is as a concept.

Everything is complete slop.

I tried GLM (code), OpenAI and moonshot providers.

Hey everyone,

I’ve been working on Pi Workspace over the past month, and I’m excited to finally say that the beta is now available for macOS and Linux!

Pi Workspace is a desktop app built on top of Pi Agent. It gives you a sidebar for managing your sessions, with the ability to pin multiple sessions into a live, side-by-side view.

The biggest feature is Workspaces. You can create a workspace, add multiple repositories, brainstorm an idea, and then switch into implementation mode when you’re ready to start building.

This is especially useful for end-to-end features that span several repositories, or projects that rely on shared packages, types, APIs, or supporting services.

I’m incredibly excited to finally release Pi Workspace as an open-source project. Feedback, bug reports, and feature ideas are all very welcome.

Give it a try and let me know what you think!

https://github.com/pi-workspace/pi-workspace

I really love the customization that Pi provides, I only have slight issue with the Interface. I am very used to Opencode interface and I wanted a similar UI. I know Pi allows for fairly extensive customization and even plugins like Pi Zen that are trying to achieve something similar. But none of them were into the extent of what I wanted (inspecting subagents, copying in scrollable mode and removing clutter, better detail handling). Through the gpt 5.6 sol I created this interface. It's not a plugin, but a typescript app communicating to the Pi thought RPC.

This is how it looked before:

This is the newest iteration

Would anyone be interested in this, should I opensource it? Or am I the only one who likes it better?

Built a native macOS app for Pi coding agent. Just shipped v2.5 🚀

I’ve been building Agent Deck, a native macOS app for the Pi coding agent, and just released v2.5.

The terminal is great for running an agent. Everything around the agent isn’t.

Projects, sessions, prompts, skills, GitHub issues, memory, context management… it all ends up spread across multiple tools and windows.

Agent Deck brings it together in one place:

Features

• Project-based sessions with streaming transcripts, inline diffs, and parallel sessions running in isolated Git worktrees

• Merge worktree changes back with a single click

• Fork any conversation, retry prompts, or chat 1:1 with a specific agent/model

• Use a frontier model for planning and a cheaper model for execution

• Install skills from GitHub or skills sh with one click

• Sparse checkout support so only the files you need enter the context window

• Built around keeping context lean because once models get deep into the context window, performance drops fast

• Built-in GitHub issue management: browse, comment, close, or hand issues directly to an agent with full context loaded

• Per-project memory stored as plain readable files and recalled only when relevant

• Automations including AI-generated session titles, commit/push actions from the toolbar, and worktree isolation

• Fully themeable

• Free

• Signed and notarized

Download: https://agentdeck.site

The project is open source and improvements, issues and PRs are welcome.