# OMP (Oh My Pi): AI Coding Agent with LSP, DAP Debugger, and Hashline Edits
[OMP (Oh My Pi)](https://github.com/ohmypi/omp) is an **open-source AI agent harness built on the `pi` framework**. It differs from most terminal-based coding agents in four architectural areas: native LSP integration for code comprehension, real debugger support via DAP, model-agnostic role-based routing, and a token-efficient edit format called Hashline Edits.
## LSP integration
Most terminal AI agents apply refactoring through text search and replace. When asked to rename a module, they scan for the string and substitute it, which can miss aliased imports, fail to update barrel files, or produce syntax errors.
OMP hooks directly into the project's language server (TypeScript, Go, Python, and other supported languages) and issues workspace-level refactoring commands. The language server understands the semantic structure of the code, so renames propagate correctly through all references, barrel files, and re-exports before anything is saved to disk.
The practical difference is that refactors OMP performs are structurally correct by construction, not probabilistically correct based on string matching.
## Real debugger support (DAP)
Most agents debug by inserting `print()` or `console.log()` statements and re-running the program. This fails for concurrency bugs, race conditions, segfaults, and other runtime issues that require observing the live program state.
OMP supports the Debug Adapter Protocol (DAP) and can attach real debuggers to running processes. Supported debuggers include `dlv` for Go, `debugpy` for Python, and `lldb-dap` for C/C++. Once attached, OMP can set breakpoints, step through execution, inspect stack frames, and evaluate live variable state.
This allows OMP to diagnose runtime bugs by observation rather than inference from source code alone.
## Model-agnostic role-based routing
OMP connects to Anthropic, OpenAI, Grok, and other providers. Rather than selecting one model for all tasks, it supports role-based assignment: different model configurations for different task types.
An example configuration:
- **PLAN / ARCHITECT:** high-reasoning model (e.g., `claude-3-opus-20240229`) for architectural planning
- **TASK / SUBTASK:** faster, cheaper model (e.g., `claude-3-haiku-20240307`) for routine implementation
- **VISION:** vision-capable model (e.g., `gpt-4-vision-preview`) for image analysis
- **COMMIT:** model tuned for commit message generation
This keeps expensive model calls for tasks that warrant them and routes routine work to more cost-effective options. Logging in with an existing Claude Code account automatically imports settings and plugins.
## Hashline Edits
Standard file editing by AI agents sends the full original file and the full proposed replacement. For large files this consumes substantial tokens and introduces errors when line numbers shift.
OMP uses content-hash anchors: a short unique identifier derived from the content of a specific line. Edit operations reference these anchors rather than line numbers or the full file text. This reduces token usage significantly (on Grok 4 Fast, output token usage drops by roughly 61%; on Claude Opus, savings are around half that) and is stable against file changes that would shift line numbers or introduce whitespace differences.
## Practical example: building a Rust desktop widget
The following demonstrates OMP building a floating macOS widget from a single prompt.
**Prompt:** "I want to create a Rust based floating Mac widget that scrapes trending stock symbols from https://stocktwits.com/news-articles every 20 seconds and shows the list with its values. It should also include a shortlist of trending articles from this page."
OMP first plans the implementation:
1. Inspect the target page structure using a headless Chrome instance (to handle JavaScript-rendered content that `curl` would miss)
2. Design the Rust application architecture
3. Build and verify
Technology selection with reasoning: `reqwest` for HTTP, `scraper` for HTML parsing, `egui` with `eframe` for the GUI ("supports always-on-top windows and is lightweight").
Implementation steps:
- `cargo init --name stock_widget` to scaffold the project
- Populate `Cargo.toml` with identified dependencies
- Write `src/main.rs` with data models, scraping logic, GUI layout, and a 20-second refresh loop
- Build and verify
The plan concludes with a verification step, forming a closed plan-implement-verify loop.
## Ecosystem and additional capabilities
OMP supports the `pi` package catalog. Plugin installation uses `omp plugin install `. Packages can add new commands, skills, prompt templates, and tools.
Other notable capabilities:
**Code review.** The `review` command analyzes pull requests, provides a merge verdict, and prioritizes issues by severity. It can sweep multiple branches and review uncommitted work in parallel.
**Subagents.** Complex tasks can be split across parallel subagents working in isolated environments. Results are merged when complete.
**GitHub as a filesystem.** OMP reads GitHub issues, pull requests, and diffs using the same file access tools used for local files.
**Hindsight memory.** OMP compresses each session into a persistent mental model of the project, giving it long-term context across sessions.
## Final thoughts
OMP's most distinctive technical contribution is the combination of LSP and DAP integration. Most AI coding agents treat the codebase as a collection of text files. **OMP treats it as a running program with semantic structure. The difference is most visible in two scenarios**: refactoring (where semantic correctness matters more than string matching) and debugging (where runtime state provides information that source code alone cannot).
The Hashline Edit format addresses a practical cost concern: token usage for large file edits is one of the more significant ongoing expenses when using capable models for code work.
The model routing system is useful for teams that want to balance cost and capability across different task types without maintaining separate tooling for each.
Source code and documentation are at [github.com/ohmypi/omp](https://github.com/ohmypi/omp).