AxiOwl Provider Docs
Each provider page describes one provider surface. The status source of truth is Provider Support Matrix.
Why Provider Pages Are Surface-Specific
Provider support is not just brand support. A brand can expose an editor integration, an agent window, a CLI, and a VSIX-backed chat surface. Those surfaces can require different installs, patches, metadata, delivery proof, and failure handling.
Plain English version: codex:agents and codex:cli are not the same thing. cursor:agents and a hypothetical Cursor CLI are not the same thing. Treating them as the same creates bad tests and bad installs.
Provider Pages
| Provider surface | Page | Current status |
|---|---|---|
| Codex agents | Codex Agents | supported |
| Codex CLI | Codex CLI | supported |
| VS Code Copilot | VS Code Copilot | supported |
| VS Code native | VS Code Native | supported |
| Cursor agents | Cursor Agents | supported |
| Antigravity agents | Antigravity Agents | supported |
| Antigravity CLI | Antigravity CLI | target |
| Claude Code CLI | Claude Code CLI | target |
| OpenCode CLI | OpenCode CLI | target |
| Copilot CLI | Copilot CLI | target |
| Remote | Remote | unsupported for local-provider remediation |
Provider Page Contract
Every provider page should answer:
- Is this surface supported, target, experimental, unsupported, or removed?
- How does AxiOwl deliver a message?
- What does the installer do?
- What patch, extension, MCP config, or CLI config is required?
- What test proof exists?
- What risks are known?
- Why is this architecture the right current choice?