Warp
The open-source ADE
4.8•72 reviews•3K followers
The open-source ADE
4.8•72 reviews•3K followers
The open-source agentic development environment, born out of the terminal. Build with agents, locally and in the cloud with Oz.
This is the 6th launch from Warp. View more
Warp Open-Source
Launched this week
The best, longest-lasting software is built with the people who use it, so we've opened up Warp to the community. To make this possible, Oz-managed agents do the heavy lifting (coding, planning, testing), letting community members focus on ideas, direction, and verification. 25K+ stars added and 500+ contributors in week one.
Free
Launch Team / Built With
Warp
👋 Hey Product Hunt community,
Zach here, founder of Warp. Two weeks ago we open-sourced Warp — and honestly, the response blew us away. We’re bringing it to Product Hunt today because this community is exactly the kind of community we want to build with.
The short version: Warp is now open-source, and the community can participate in building it using an agent-first workflow managed by Oz, our cloud agent orchestration platform. Community members shape direction and verify behavior. Oz-managed agents do a lot of the implementation heavy lifting. The Warp team reviews and ships.
We're doing this because we think we can ship a better Warp, more quickly, by working with our community to supervise a fleet of agents. The biggest bottleneck to development is no longer writing code — it's the human-in-the-loop activities around it: deciding what to build, speccing it clearly, and making sure it's right. Opening up lets us be more responsive to users and work with them on the long tail of our backlog.
The response so far has been pretty wild:
25K+ new GitHub stars in week one — we more than doubled, to around 56K
500+ unique contributors opened hundreds of PRs
Great conversations with the community about what people want to see in Warp next
We still have a lot to figure out to build the right workbench for agentic development. For example, we’re actively discussing how to support local and arbitrary models in a way that matches what users actually want, not just what is easiest for us.
Would love to hear: what would you want to build or fix in Warp? And what are you skeptical about?
Check out the repo: https://github.com/warpdotdev/warp
Watch what the agents are up to: https://build.warp.dev
Thanks for checking it out — excited to build this together.
— Zach
@zach_lloyd the prompt already takes longer to write than the diff takes to read on solo agent work, and that's with the codebase in my head. spec-and-verify is what i'd watch when community contributors without that context start handing specs to Oz. specs go bad upstream and Oz can't catch what wasn't asked for.
Warp
@webappski Yeah, this is the part I’d keep a close eye on too. Specs are where things can really drift, especially when someone doesn’t know the codebase well. That’s why we keep humans in the loop on specs: the team reviews and adjusts contributor-written specs before any implementation happens, so we can catch misaligned goals or missing constraints early.
Raycast
Super bold move, but also savvy.
Proprietary software is no longer a moat like it once was; even more important is to consider that if you're not fixing your customer's edge cases and bugs at agentic speed, they're going to go elsewhere or just roll their own solution.
Warp going open source means that the community can take more agency over their experience and fix the paper cuts that the Warp Corp team just doesn't have enough time or attention cycles to prioritize.
I am curious about how fast PRs will be approved though, and what kind of scaffolding Warp will need to add to manage the community!
Here's a high level look at the contribution flow. Steps owned by the contributor are shown in yellow; steps owned by the Warp team or Oz are shown in blue:
Warp
Thank you @chrismessina! 🙌
Totally agree, and it's been super exciting to see what the community has been building and adding to Warp. Over the past 2 weeks, we've continuously been making changes to our internal processes so we can be on top of the repo. It's definitely something that we expect to evolve so we can get those PRs merged in fast and give a great experience to our contributors.
Opening the source while keeping Oz as the heavy-lift layer is an interesting bet. Most OSS terminals stall because reviewers can't keep up with PRs, so routing implementation through managed agents and keeping humans on specs and verification might actually scale. I'm watching the local model question closely. For me, the dealbreaker is whether I can point Warp at a local Ollama endpoint without losing the agent orchestration UX. If Oz only orchestrates cloud models, that's a non-starter for anyone with NDA codebases. Any rough timeline on a BYO-endpoint config?
Warp
@brainystudy totally agree, it's been very important to us that our process scales, and the Oz agent managed workflows have been working out very well.
Re: BYO-endpoint, we're currently working on adding support and is a high-prio item on our immediate roadmap. Expecting it to land in the next 1-2 weeks. You can also check out this discussion for more details: https://github.com/warpdotdev/warp/discussions/9619#discussioncomment-16831279
Kilo Code
oss ftw!
Warp
@fmerian absolutely 🙌
Going open source is a bold move for Warp. The terminal space is one of those areas where developer trust matters more than features — and open source is the fastest way to earn it.
As someone who spends most of my day in the terminal building and deploying, the "agentic" part is what interests me most. How does it handle context? The biggest limitation I've seen with AI-in-terminal tools is they lose context between commands. If Warp can maintain a running understanding of what I'm working on across a whole session, that's genuinely different from just having an inline copilot.
Warp
@ytubviral So, the interesting thing about Warp is that it started out as a terminal and evolved the agentic features on top. We've got a dedicated terminal subagent that's really good at working with commands that are launched by the agent and processing their outputs. Warp also treats each command execution as a "block" that you can capture as explicit context into an agent request. I use this all the time to pipe build errors or logs in to the agent to analyze. If you're curious to see all this in action, I'd definitely recommend trying Warp out yourself and seeing how it plugs into your terminal workflows.
Love the move to open-source. For the agentic features, how are you balancing the 'magic' of automation with the developer's need for granular control? It's a tough line to walk.
Warp
@rivra_dev Great question! Developer control is important and keeping humans-in-the-loop is what makes this system more valuable. Human discretion comes in at a couple of places:
1. Maintainers get to decide whether issues are complex enough to require specs or straight-forward enough to go straight to code. This keeps the decision about complexity and goals in the hands of human operators.
2. All the agents are flexible and rely on repo-specific skills that outline how they should triage, write specs, and review PRs. This let's each repo dictate its priorities and goals in skill files that the agent respects.
3. Oz can respond to maintainer requests on any PR, allowing operators to quickly jump in and steer PRs from any contributor with Oz based on their priorities. Our team uses this to carry PRs to the last mile with fine-tuned adjustments all the time.
It's good to see Warp going open-source, but I'm curious how the community plans to handle plugin contributions. Are there frameworks in place to ensure security and compatibility, especially with potential third-party integrations?
Warp
@andrewbuilds Great question. Right now we do not have a separate plugin system. Community contributions go directly into the app itself, which means they go through the same review, testing, and QA steps as any other change our team ships. That is how we keep security and compatibility tight while still moving quickly.
Longer term, it'd be interesting to add a clearer interface and extension surface for third-party integrations, but we want to be thoughtful about the boundaries and guarantees there first. For now, the focus is on keeping the core experience solid, and using our review process to make sure anything that lands in Warp meets the same bar.