Map

openwarp

Toolbox toolboxrustterminalai-agentsbyopforkwatchlistRustAGPL-3.0 / MIT (dualmirroring upstream) ↳ show in map Markdown
title
openwarp
type
toolbox
summary
Warp terminal fork with bring-your-own-provider AI over six native model protocols
tags
rust, terminal, ai-agents, byop, fork, watchlist
repo
https://github.com/zerx-lab/warp
homepage
https://openwarp.zerx.dev
language
Rust
license
AGPL-3.0 / MIT (dual, mirroring upstream)
created
2026-05-02
updated
2026-05-02

Community fork of Warp that puts the AI layer behind a Bring-Your-Own-Provider (BYOP) interface — paste a Base URL and API key in settings, pick the wire protocol, and Warp now talks to that endpoint instead of Warp Inc's hosted models. Everything else stays Warp: blocks, AI commands, workflows, keymaps, themes. Upstream changes get continuously merged.

The marketing line is "Bring any AI model into your terminal"; the technical line is "the AI layer is opened up, the rest of Warp isn't reimplemented." Tracked here as the GPU-terminal-with-baked-in-AI category's first credible community fork.

Why this exists

Warp ships a great terminal but locks you into its hosted AI subscription, with a Cloud Agent / Computer Use surface that uploads context. OpenWarp keeps the upstream codebase verbatim and patches the AI client so:

  1. Custom providers are configurable from Settings.
  2. Cloud Agent / Computer Use is disabled by default.
  3. Credentials live only in ~/.config/openwarp.toml — no relay, requests go straight to the configured Base URL.
  4. UI strings get a real i18n layer (Chinese + English shipping, with Japanese / Spanish previewed).

It's the same pattern as VSCodium-vs-VS Code or Cursor-vs-Continue: take an opinionated commercial product, strip the lock-in surface, keep the upstream merges flowing.

How the provider layer works

Built on the genai Rust crate as a multi-protocol client. 6 native API protocols, not just an OpenAI-compat shim:

  • OpenAI
  • OpenAI Responses
  • Anthropic
  • Gemini
  • Ollama
  • DeepSeek

Why the distinction matters: an OpenAI-compat shim flattens reasoning models down to plain chat completions and drops provider-specific fields. OpenWarp's native protocols pass through:

  • DeepSeek reasoning_content
  • Claude thinking
  • Gemini reasoning blocks

…across multi-turn conversations, so the agent loop sees the full chain-of-thought a reasoning model produces. OpenAI-compatible endpoints (Qwen, Groq, Together, OpenRouter, SiliconFlow, LM Studio, etc.) plug in by selecting the OpenAI protocol and pointing Base URL at them.

Provider config is explicit — protocol is named, no model-name guessing:

# ~/.config/openwarp.toml
name        = "DeepSeek (Personal)"
api_protocol = "OpenAI"          # or "Anthropic", "Gemini", "Ollama", "DeepSeek", ...
base_url    = "https://api.deepseek.com"
api_key     = "sk-……"
model       = "deepseek-reasoner"

minijinja system prompts

System prompts are templates rendered per call from the current cwd, locale, and role. The engine is minijinja (Mitsuhiko's Rust port of Jinja2):

{% if user.role %}
You are an expert {{ user.role }}.
{% endif %}
Reply in {{ locale }}.

Same context-engineering instinct as a Claude Code skill or a Cursor rules file, but baked into the terminal so every shell session gets a context-aware system prompt without project-level config.

Install

No public release yet — has to be built from source:

git clone -b openWarp https://github.com/zerx-lab/warp
cd warp
cargo build --release
./target/release/openwarp
# then add a custom provider in Settings

The fork lives on the openWarp branch (capital W). Upstream main is reserved for sync from warpdotdev/warp.

Status

3 days old (created 2026-04-29) and already at 422 stars / 23 forks. The site banner says "Early development — no public release yet" and the README points at cargo build --release as the only install path. Repo size is ~155 MB because it carries the full upstream Warp source tree.

License is AGPL-3.0 in the GitHub field; site says AGPL-3.0 / MIT dual, mirroring upstream Warp.

Distinct from the unrelated runs-on/warp (CI/Docker tool) — same name collision the GitHub redirect briefly serves the wrong page for.

Limitations to think about before adopting

  • No release binaries. Cargo build of a Tauri-shaped Rust desktop app on macOS is a 10-minute affair plus toolchain setup.
  • Upstream merge cadence is unproven. Warp ships fast; a fork that promises "continuously merging upstream" needs to actually keep up, otherwise the value proposition collapses.
  • Single-vendor fork. zerx-lab is a 2024-vintage GitHub user with no other notable projects — the bus factor is exactly one.
  • AGPL-3.0 means any modifications you serve to others (e.g., behind a proxy) must be open-sourced.
  • Cloud Agent / Computer Use are disabled, not removed. Upstream merges will keep dragging that surface back in.
  • Branch naming (openWarp vs OpenWarp vs openwarp) is inconsistent across the site, README, and repo — small but annoying friction.

Filed on watchlist — re-check 2026-08-02. The interesting question is whether a binary release lands and whether anyone other than the original author starts merging upstream.

  • gpu-accelerated-terminal — Warp is the canonical example; battery cost discussion in terminal-gpu-battery-cost applies.
  • gomodel — Go AI gateway with the same OpenAI-compatible-unified-API instinct, different layer of the stack (process-level proxy vs. client-side library).
  • mcp-vs-skills — minijinja templates here are the Skills-style "load knowledge into context" model, baked into the terminal config.
  • deepseek — reasoning_content passthrough is one of the most concrete OpenWarp benefits over a plain chat-completions client.
  • BYOP (Bring Your Own Provider) — same pattern as ctx, pi-coding-agent, claude-defuddle; OpenWarp generalises it to the whole terminal.

Repo

github.com/zerx-lab/warp · 422★ · AGPL-3.0 / MIT · Rust · openWarp branch

Sources: openwarp-landing, GitHub repo.

Linked from