On May 7, 2026, Warp open-sourced its desktop terminal client under AGPL-3.0. The repo hit 37,000 GitHub stars within days. OpenAI signed on as a founding sponsor. The announcement was broadly covered as Warp "going open source."
That framing is accurate but incomplete in a way that matters. What Warp open-sourced is the client. The part of the product where most of the interesting AI happens, the cloud agent orchestration layer called "Oz," remains proprietary. That's not a footnote. It's the thing attorneys, CPAs, and consultants should actually be thinking about when they evaluate any AI tool that touches client work.
Warp is a good product. I've used it. The AI-assisted terminal experience is genuinely better than the alternatives for a lot of workflows. Open-sourcing the client gives the community the ability to audit the local code, contribute to the UI layer, and, in principle, run a self-hosted version of the terminal itself.
But the free plan gives you 75 AI credits per month after the first two months, with BYOK support available starting at $20/month. The AI capabilities that make Warp more than a pretty terminal, the agent that can understand your codebase context, plan and execute multi-step operations, persist memory across sessions, those run through Oz. Oz is not open-sourced.
From The New Stack's coverage of the announcement: "Warp's 'Oz' cloud agent orchestration layer remains proprietary." The company is also introducing an "agent-first contribution model" where community contributors supervise AI agents rather than writing code directly. That's an interesting philosophy, but it also means more of the product's value flows through the proprietary layer, not less.
None of this makes Warp a bad choice for coding work. It makes it a specific architectural choice, one where the parts of the tool you can inspect and control are the rendering layer and the terminal behavior, while the parts that touch your commands, context, and workflow data live in a cloud orchestration system you can read about but not audit.
Open-sourcing the client while keeping the orchestration layer closed is a coherent business model. It builds community, builds trust at the surface level, and protects the part of the product that's actually hard to replicate. Professionals evaluating AI tools should recognize the pattern for what it is, especially when the data passing through the orchestration layer belongs to clients.
Warp isn't alone here. This architectural split is showing up across the category, and it's worth naming explicitly because the line between "open" and "closed" in AI tools is increasingly drawn at exactly this seam.
The local client is the part that handles input, rendering, and file management. It's relatively cheap to build, cheap to maintain, and cheap to give away. Open-sourcing it creates goodwill, reduces security concerns about what the app is doing locally, and drives adoption.
The cloud orchestration layer is where context is aggregated, where agent memory persists, where multi-step reasoning happens across sessions. It's expensive to build, expensive to run, and it's the part that makes the product genuinely useful beyond a basic interface. That's the part companies keep closed.
You see this pattern at different points on the spectrum. VSCode is open-source, but GitHub Copilot's backend is proprietary. Cursor is a proprietary client layered on top of VSCode's open-source base, with proprietary AI orchestration. Warp open-sourced its client, kept its cloud brain. Even Obsidian, which is proprietary software, has a community plugin ecosystem where the local-computation plugins are open and the sync/publish services are paid cloud features.
The pattern isn't evidence of bad faith. It's a natural consequence of where the engineering investment concentrates. The cloud orchestration layer is hard to build. That's where companies defend their differentiation. But for professionals whose work is subject to attorney-client privilege, IRC §7216's restrictions on tax data, or NDA obligations with clients, the fact that the "interesting part" of a tool runs in a cloud you can't audit is not a minor footnote.
The counter-experiment to all of this is what the Obsidian community has built on its own. Obsidian doesn't have a native AI layer. It has an open plugin API. And the community has used that API to build fully local AI setups that route directly to local models via Ollama, with zero API keys and zero cloud dependency.
A documented example of a fully local Obsidian AI assistant shows this working in practice: no API keys, no cloud, no credits, just a local model running on your machine. The Khoj plugin has taken this further with persistent memory, semantic search across your notes, and multi-modal input, all locally hosted.
This community work proves a real point: there is meaningful demand for fully on-device AI, and it's not purely a technical hobbyist niche. Professionals who care about where client data goes have been building workarounds because the mainstream tools don't offer the architecture they need.
The limitation is that this requires assembly. Getting Ollama running, configuring the right plugins, managing local model weights, dealing with the quality gap between frontier models and what you can run locally, that's real friction. Most attorneys and CPAs don't have the time or inclination for it. So they use the tools with cloud brains and accept the tradeoff, often without fully understanding what the tradeoff actually is.
I want to be concrete about what "cloud orchestration layer" means and why it matters for professional work.
When you ask an AI agent to help you analyze a client's litigation exposure, draft a tax position memo, or work through a consulting engagement, the context of that conversation is substantive. It might include your client's name, their financial information, privileged legal strategy, unreleased business plans, or tax return data. That's real client information, subject to specific legal protections.
When that context passes through a cloud orchestration layer, it exists on infrastructure you don't own, subject to the data handling policies of a company whose terms you may not have read as a data processing agreement. For attorneys, ABA Formal Opinion 512 (2024) requires reasonable measures to understand and prevent disclosure of client confidences when using AI. The decision in United States v. Heppner (Judge Rakoff, S.D.N.Y., Feb. 17, 2026) found that routing privileged communications through a third-party AI intermediary can constitute a disclosure sufficient to waive privilege. For CPAs and EAs, IRC §7216 makes unauthorized disclosure of tax return information a criminal matter.
The question I'd encourage professionals to ask isn't "is this tool open source" or "does it have a privacy policy." It's "where does the AI reasoning about my client's matter actually happen, and whose infrastructure is it running on?"
I built Advisor Prep Hero without a cloud agent layer. There isn't one. The AI request goes from your machine to Anthropic, OpenAI, or Google directly, using your API key. There's no Oz equivalent. No proprietary orchestration system sitting between your client's information and the underlying model.
This means some things Advisor Prep Hero can't do. There's no persistent memory that syncs across devices through a cloud service, because there's no cloud service. There's no agent that remembers context from a session last Tuesday unless you've saved that context yourself as a file. The tradeoff is real.
What you get in exchange is a data chain you can actually describe. Every piece of client context you bring into an Advisor Prep Hero session stays in the path between your device and Anthropic or OpenAI. Advisor Prep Hero is not running infrastructure that processes your client work. The Markdown files that contain your output live on your device. The data path is short, auditable, and defensible under ABA Op 512, IRC §7216, and standard NDA confidentiality obligations.
This isn't the right architecture for every use case. If you want an AI tool that learns your codebase deeply, maintains persistent context across weeks of work, and can execute multi-step operations autonomously, you probably want a product with a cloud brain, and you should pick one whose privacy practices you've actually read and evaluated as a data processing agreement.
But for the client-facing work Advisor Prep Hero is designed for, drafting memos, analyzing issues, synthesizing research, preparing deliverables, the local-direct-API architecture handles the job with a data footprint you can stand behind professionally.
Warp's open-source announcement is genuinely good for the community, even with Oz closed. More transparency in the local client is better. The conversation it's prompting about where the actual AI happens is valuable.
The interesting question for professionals isn't "which tool should I use" as if the answer is a single recommendation. The right question is "which parts of my work deserve which architecture."
Coding assistance or general research that doesn't involve client confidences: a cloud-brained product might be the right tradeoff, especially if you're on an enterprise plan with data processing agreements in place. Client matter analysis, privileged legal strategy, tax return work, confidential consulting engagements: you want the AI processing that work to have a shorter data chain, not a longer one.
The fact that the AI tools category is splitting along this seam, local client open, cloud brain proprietary, means the choice is becoming more visible. Professionals who understand it can make deliberate decisions about which work goes where, rather than inheriting someone else's data architecture by default.
See Advisor Prep Hero, local-first AI workspace for confidential professional workJameson Daines builds Advisor Prep Hero for attorneys, CPAs, and independent consultants. Read about the BYOK math for professional users or get Advisor Prep Hero at advisorprephero.com.