# Auto Compact URL: /auto-compact Reduce context usage by summarizing long conversations—inline or into a new task *** title: "Auto Compact" description: "Reduce context usage by summarizing long conversations—inline or into a new task" icon: "ScanText" ---------------- # Auto Compact Auto Compact helps you keep long conversations efficient by summarizing earlier messages when your token usage grows large. You can either: * Compact in the current task (inject a compact summary so you can continue seamlessly) * Start a new task with the summary (spawn a fresh task seeded with a concise recap) ![Auto Compact overview](../assets/images/auto-compact.png) ## When Auto Compact is available Auto Compact becomes available from the token usage chip in the toolbar when all of the following are true: * The conversation isn’t streaming or executing * The chat isn’t read-only * No other compact action is pending * Total tokens ≥ 50,000 (min threshold) If the threshold isn’t met, you’ll see a tooltip explaining that more tokens are required to compact. While compacting, the chip shows a spinner with the “Compacting” label. ![Compacting in progress](../assets/images/auto-compacting.png) ## Two ways to compact ### Option A — Compact in current task Use this to stay in the same task. Pochi will: 1. Generate a concise summary of the conversation up to your latest message 2. Inject a compact block at the top of your last user message 3. Continue the conversation with the condensed context > Notes: The summary is wrapped into a compact section and prepended to your last message to preserve intent while saving context. ### Option B — Start new task with summary Use this to branch a fresh task based on the current work. Pochi will: 1. Create a summary of the existing conversation 2. Open a new task seeded with the summary and a short handoff message 3. Navigate you to the new task to continue ![Inline compact summary in current task (expandable)](../assets/images/auto-compact-with-new-task-summery.png) ## Technical Details * Trigger: You choose either “Compact task” (inline) or “New task with summary”. * Summary prompt: Pochi asks the model to produce a concise recap focused on key topics, decisions, and important context (limited to a few thousand tokens of output). * Inline compact: The recap is wrapped in a compact block and prepended to your last user message before the next response. * New task: The recap becomes the first message of a brand-new task, followed by a short instruction letting the agent analyze status and confirm next steps. * Safety/availability: Buttons are disabled during streaming/execution, or when below the minimum token threshold. ## Tips * Prefer inline compact when you want continuity within the same task. * Use “new task with summary” to cleanly branch, hand over, or checkpoint work. * You’ll see a “Compacting” state while the summary is being generated—this can take a moment for very long threads. # Checkpoints URL: /checkpoint *** title: Checkpoints icon: "Route" ------------- # Checkpoints Checkpoints automatically save a snapshot of your workspace after key steps in a task. They help you track changes, roll back when needed, and explore different implementations without worrying about breaking your code.
![Checkpoint overview](../assets/images/checkpoint-overview.png)
## How checkpoints work Pochi creates a checkpoint after important actions such as file edits or applied fixes. These checkpoints: * Run alongside your Git workflow without interference * Preserve the conversation context when restoring (chat and task context remain intact) * Track file changes using a shadow Git repository (no writes to your real repository) Example: while developing a feature, the assistant updates multiple files. Each change creates a checkpoint. You can review each modification, and if needed, roll back to any point without impacting your main branch or real Git history. ## Viewing changes and restoring After each key action, you can: 1. Click Compare to see modified files and diffs 2. Click Restore to open restore options
![Checkpoint compare](../assets/images/checkpoint-compare.png)
## Restore options To go back to a previous point: 1. Click Restore next to any step 2. Choose how you want to restore: * Restore Workspace and Task (when available): revert both code and task context * Restore Task Only (when available): keep code changes, revert task context * Restore Workspace Only: revert code while preserving task context (current default) Note: The current version focuses on “Restore Workspace Only.” Other options will appear as their capabilities are enabled.
![Checkpoint restore options](../assets/images/checkpoints-restore.png)
## Under the hood In VS Code, Pochi implements checkpoints with a shadow Git that stays separate from your real repository: * Initializes a bare repository under the extension’s storage directory (scoped per workspace) * Points the worktree to your workspace, then stages and commits changes into the shadow repo * Excludes common large/binary/cache/build artifacts (see Exclusions) to keep things fast and stable This shadow repo is fully independent. Saving or restoring checkpoints does not create commits in your actual Git repository. ## Requirements * **Git** must be installed (the shadow Git depends on it). If Git isn’t available, the checkpoint feature can’t initialize and will be disabled. ## Smart detection and exclusions Pochi automatically detects and excludes heavy or redundant files to keep checkpoints lean and fast, including: * Build artifacts and dependency folders * Media files and large binaries * Cache, logs, and temporary files * Environment configuration files * Files tracked by Git LFS With this smart filtering, checkpoints focus on core code changes—making diffs clearer and restores faster. # CLI URL: /cli Pochi CLI allows you to run an AI agent directly from the command line. *** title: CLI description: Pochi CLI allows you to run an AI agent directly from the command line. icon: "SquareTerminal" ---------------------- # CLI Pochi offers a command-line interface (CLI) that allows you to run an AI agent directly from the command line. ## Oneliner Install ```bash curl -fsSL https://getpochi.com/install.sh | bash ``` To install a specific version, pass the version tag as an argument. For example: ```bash curl -fsSL https://getpochi.com/install.sh | bash -s "pochi-v0.5.5" ``` ```bash brew install tabbyml/pochi/pochi ``` ```bash npm install -g @getpochi/cli ``` ## Authentication The Pochi CLI uses the same authentication credentials as the VS Code extension for Pochi's cloud services. When you sign in through the VS Code extension, the CLI automatically reuses these credentials. Credentials are stored in `~/.pochi/config.jsonc`. To authenticate: 1. Install and open the [Pochi VS Code extension](https://marketplace.visualstudio.com/items?itemName=TabbyML.pochi) 2. Follow the sign-in prompts in the extension 3. The CLI will automatically use the same credentials For non-Pochi models, first configure it in your Pochi configuration file (`~/.pochi/config.jsonc`). See [Models documentation](./models.mdx) for details on how to configure custom providers. Then you can use the model by specifying the provider and model ID separated by a slash: ```bash pochi --model groq/llama3-8b-8192 -p "What is the time now?" ``` ## Usage You can pass a prompt to run a task: ```bash pochi -p "What is the time now?" ``` Or pipe input as a prompt: ```bash echo "What is the time now?" | pochi ``` For detailed usage instructions, run `pochi -h`, below is the output fom version 0.5.3 ``` Usage: pochi [options] Pochi v0.5.5 Prompt: -p, --prompt Create a new task with the given prompt. You can also pipe input to use as a prompt, for example: `cat prompt.txt | pochi`. Options: --max-steps Maximum number of stepsto run the task. If the task cannot be completed in this number of rounds, the runner will stop. (default: 24) --max-retries Maximum number of retries to run the task in a single step. (default: 3) Model: --model The model to use for the task. (default: "qwen/qwen3-coder") Others: -V, --version Print the version string. -h, --help Print this help message. ``` ## Debugging To enable debug logging for the CLI, you can set the `POCHI_LOG` environment variable: ```bash POCHI_LOG=debug pochi -p "What is the time now?" ``` This will output detailed logs about the CLI's operation, which can be helpful for troubleshooting issues. For more granular control, you can specify log levels for specific components: ```bash POCHI_LOG=Pochi=debug,TaskRunner=trace pochi -p "What is the time now?" ``` # Custom Agent URL: /custom-agent Learn how to create and use custom agents in Pochi. *** title: Custom Agent icon: Bot description: Learn how to create and use custom agents in Pochi. ---------------------------------------------------------------- # Custom Agents Pochi allows you to define custom agents to handle specific tasks. These agents can be tailored with their own system prompts and sets of tools, enabling you to create specialized assistants for your workflows. ## Defining a Custom Agent Custom agents are defined in `.md` files located in either the project's `.pochi/agents/` directory or the system-wide `~/.pochi/agents/` directory. An agent definition file consists of two parts: a frontmatter section for configuration and a content section for the system prompt. Here is an example of a custom agent definition: ```markdown --- description: Description of when this custom agent should be invoked tools: - tool-1 - tool-2 - tool-3 --- Your custom agent's system prompt goes here. This can be multiple paragraphs and should clearly define the custom agent's role, capabilities, and approach to solving problems. Include specific instructions, best practices, and any constraints the custom agent should follow. ``` If the agent is saved as `my-agent.md` and the `name` attribute is omitted, `my-agent` will be used as the agent name. ### Configuration The frontmatter provides metadata for the custom agent: * `name` (optional): A unique name for your agent. If omitted, the filename (without the extension) is used as the name. * `description` (required): A short description of what the agent does. This is used to help Pochi decide when to use your agent. * `tools` (optional): A list of tools that the agent is allowed to use. This can be a comma-separated string (e.g., `tool-1, tool-2`) or a YAML array. If omitted, the agent inherits all available tools. ### Tool-specific rules Rule entries follow the format `tool` or `tool(specifier)`. The following tools support specifier-based restrictions: * `executeCommand`, `startBackgroundJob` — Command patterns, e.g. `executeCommand(npm run *)`, `startBackgroundJob(npm run dev)` * `readFile`, `writeToFile`, `applyDiff`, `editNotebook` — Path globs, e.g. `readFile(src/**)` * `webFetch` — Domain patterns, e.g. `webFetch(domain:*.example.com)` A tool declared without parentheses (e.g., `readFile`) has no restrictions. Use one declaration per rule — commas inside a specifier are not supported; add separate entries for multiple rules. #### Command Execution Restrictions Restrict which shell commands the agent can run via `executeCommand`. The specifier is matched against each individual command segment (split on `;`, `&&`, `||`, `|`). If any segment does not match at least one allowed pattern, the tool call is rejected. | Declaration | Behavior | | -------------------------------- | ------------------------------------------------------------- | | `executeCommand` | No restrictions — allows any command | | `executeCommand(npm)` | Allows commands whose first token is `npm` | | `executeCommand(npm *)` | Allows command segments matching the pattern `npm *` | | `executeCommand(npm run test)` | Allows command segments matching exactly `npm run test` | | `executeCommand(npm run test *)` | Allows command segments matching the pattern `npm run test *` | #### Background Job Restrictions Restrict which long-running commands the agent can launch via `startBackgroundJob`. The same command-pattern matching used for `executeCommand` applies here, but the two policies are independent — an `executeCommand(...)` rule does **not** authorize a `startBackgroundJob` call, and vice versa. Declare separate entries for each tool as needed. | Declaration | Behavior | | ----------------------------------- | --------------------------------------------------------------- | | `startBackgroundJob` | No restrictions — allows any background command | | `startBackgroundJob(npm)` | Allows background commands whose first token is `npm` | | `startBackgroundJob(npm *)` | Allows background commands matching the pattern `npm *` | | `startBackgroundJob(npm run dev)` | Allows starting only `npm run dev` as a background job | | `startBackgroundJob(npm run dev *)` | Allows background commands matching the pattern `npm run dev *` | #### Path-based File Restrictions Restrict which files the agent can read or modify using workspace-relative glob patterns. Applies to `readFile`, `writeToFile`, `applyDiff`, and `editNotebook`. Access to any path outside the specified patterns is rejected. | Declaration | Behavior | | ---------------------------- | ------------------------------------------------ | | `readFile` | No restrictions — allows reading any file | | `readFile(src/**)` | Allows reading all files under `src/` | | `readFile(packages/**/*.md)` | Allows reading markdown files under `packages/` | | `writeToFile(.pochi/**)` | Allows writing only to files under `.pochi/` | | `writeToFile(logs/*.log)` | Allows writing only to log files under `logs/` | | `applyDiff(src/**)` | Allows applying diffs only to files under `src/` | | `editNotebook(docs/*.ipynb)` | Allows editing only notebook files under `docs/` | #### Domain-based Web Restrictions Restrict which domains the agent can fetch via `webFetch`. The specifier must start with `domain:`. URLs whose hostname does not match any allowed pattern are rejected. | Declaration | Behavior | | -------------------------------- | ---------------------------------------------------------------------------------- | | `webFetch` | No restrictions — allows fetching any URL | | `webFetch(domain:example.com)` | Exact domain match (e.g., allows only `example.com`) | | `webFetch(domain:*.example.com)` | Glob match against subdomains (e.g., allows `api.example.com`, `docs.example.com`) | #### New Task Restrictions Restrict which agent types a custom agent can launch using `newTask`. * `newTask(_)` allows launching only the default agent (when `agentType` is omitted). * `newTask(browser)` allows launching only the `browser` agent. * `newTask(explorer-*)` allows launching any agent whose name starts with `explorer-`. Example: ```markdown --- description: Code reviewer with restricted filesystem and network access tools: - executeCommand(git diff) - executeCommand(grep *) - startBackgroundJob(npm run dev) - readFile(src/**) - readFile(packages/**/*.md) - writeToFile(.pochi/**) - webFetch(domain:docs.example.com) - webFetch(domain:*.getpochi.com) - newTask(_) - newTask(browser) --- ``` ### System Prompt The content of the file after the frontmatter is the system prompt for the agent. This prompt should define the agent's role, capabilities, and how it should behave. ## Using a Custom Agent You can mention the custom agent's name in your prompt, and Pochi may decide to use it based on the context. ## Managing Custom Agents You can manage your custom agents through the Pochi interface or by directly manipulating the agent definition files. The common operations include: * **List**: View all available agents in the `.pochi/agents/` directory or in Pochi settings. * **Create**: Create a new `.md` file in the `.pochi/agents/` directory. * **Delete**: Remove the corresponding agent file. * **Edit**: Modify the agent's definition file. # Edits URL: /edits Send your local changes as additional context to Pochi *** title: Edits description: Send your local changes as additional context to Pochi icon: "PencilLine" ------------------ # Edits Edits account for changes you make locally while iterating on the code. If you fix something yourself, tweak a variable, or partially rewrite a block before asking for help, Pochi captures those recent edits and includes them as part of the review context. Instead of only seeing the final file state, the agent receives the exact diffs you introduced, which helps it reason about what changed, where it changed, and what you were likely trying to adjust. This gives the agent a clearer signal of your current intent and what should be addressed next. ## How to Use Edits ### 1. Make your changes You can open the diff from the last response and make direct changes to the written code. ![Pochi Models](../assets/images/edits-creation-process.png) All local changes you make gets reflected in the chatbox UI. ![Pochi Models](../assets/images/edits-tracking-prompt-ui.png) ### 2. Send Edits as a Batch Once you’re done making changes, submit your next prompt as usual. For example: ```bash Please review the edits ``` or with extra guidance: ```bash Use these edits to understand the new functions we need to add ``` Pochi will include your recent edits together with your message and use them as structured context for the next step. ![Pochi Models](../assets/images/edits-submitted-prompt.png) This lets the agent build directly on top of what you already adjusted, without you needing to re-explain those changes in chat. # Getting Started URL: / Welcome to Pochi - Full-Stack AI Teammate Guide *** title: "Getting Started" description: "Welcome to Pochi - Full-Stack AI Teammate Guide" icon: "Album" ------------- # Getting Started [Pochi](https://getpochi.com) is an open-source AI coding agent built as a VS Code extension, checkout the video below to see it in action.