Frequently Asked Questions
If you don’t mind your issue being public, our preferred place is our GitHub issues board: https://github.com/warpdotdev/warp/issues. This way other Warp users can vote on your issue and we will prioritize it accordingly. It also allows us to easily notify interested users with progress updates and when the issue is closed.
If you need to keep the feedback private, please use this form: https://zachlloyd.typeform.com/to/jaqfsdnz?typeform-source=web-faq
No, Warp does not allow OpenAI to train their models on your data. Regardless of which Warp plan you are on, your data is never used for training, even on the Free plan. Warp uses OpenAI’s API platform and OpenAI does not train on data from their API platform.
We recently achieved a SWE-Bench Verified score of 71% and ranked #1 on Terminal-Bench (52%) above Claude Code, Codex, and Terminus.
- Pricing
Warp is free and includes 150 free AI requests every month. You can upgrade to Pro or Turbo to get more and usage-based billing is available. Visit warp.dev/pricing to learn more.
- Pricing
Warp includes 150 free AI requests per user per month. If you need more, higher AI limits are available on paid plans and pay-as-you-go is available after you use your monthly quota. Visit warp.dev/pricing to learn more.
Instead of OpenAI's default policy of retaining data for 30 days for trust and security reasons, OpenAI will not retain any data for any period of time for users on Warp Enterprise. Your data is never used for training OpenAI's models, even on the Free, Pro, or Turbo plans.
Yes, Warp has obtained a SOC 2 Type 2 attestation from an accredited third party. Visit Warp’s Trust Center to request the report.
We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client codebase. The server portion of Warp will remain closed-source for now. You can see how we’re thinking about open source here: https://github.com/warpdotdev/Warp/discussions/400
As a side note, we are open sourcing our extension points as we go.
The community has already been contributing new themes (https://github.com/warpdotdev/themes). And we’ve just opened a repository for the community to contribute common useful commands. See: https://github.com/warpdotdev/workflows
We understand your discomfort. A terminal contains a lot of sensitive information and you want to make sure we are not leaking it. You also want a guarantee that the app will stay alive in cases where the company disappears.
We are planning to open-source parts and potentially all of the terminal. We want to allow folks to audit our code and tweak Warp.
Your privacy is very important to us. Check out our privacy policy here: https://docs.warp.dev/getting-started/privacy#exhaustive-telemetry-table
Unique user identity supports Warp's collaborative features and makes it easier for the Warp team to provide customer support, should you need to debug an issue. In the future, some features may be gated to logged in users.
Warp's terminal and it's core features are totally free for individuals and professional engineers. Warp's Free plan allows you to get started with collaborative features for teammates, as well.
Warp's business model is based on providing utility and developer productivity benefits for individuals and teams. We believe the value of Warp is strong enough that companies will want to pay for their teams to have access to advanced features.
Our general philosophy is that we would never charge for anything a traditional terminal currently does. So no paywalls around SSH or anything like that. The types of features we plan to charge for are things that have a cost to us, for example enabling real-time terminal collaboration. Even those will likely be free up to some level of usage.
We will never sell your data. We treat privacy very seriously at Warp. Check out www.warp.dev/privacy for more information.
Yes, Warp works offline once you’re logged in. All core terminal features will work as expected. Some cloud-based features, such as block sharing and Warp AI will not work offline. Check out our documentation for a full list of cloud-based features.
Warp is connected to the cloud so we can deliver a richer, more collaborative terminal experience.
For individual developers, connection to the cloud lets you sync your Warp settings across devices, set up Warp quickly on new devices, or access the command line from any device with access to the web.
For teams, connection to the cloud powers collaboration. Imagine being able to not just have real-time collaboration (like Google Docs) but asynchronous collaboration through shared commands, settings, and history. The cloud will allow Warp to build knowledge sharing through wikis and READMEs that run directly in the terminal. This will also make the terminal more secure through integrated password-management and logging. Eventually, the terminal could be part of an extensible, customizable platform.
Warp on Windows is out and you can download it today!
To start, we will begin with live terminal sharing. Every session you work on your desktop can be backed by a secure web permalink. It opens into a browser tab that shows your terminal state and allows readers to scroll and interact with the read-only elements. You might use this for yourself: so you can view and run commands on it while you're away from your machine. Or you might share it with a coworker for debugging.
There are other use cases we have in mind, but we will first start with the above.
Objects, like folders and workflows, saved in the Warp Drive are securely stored in the cloud and encrypted at rest. Learn more about Warp’s approach to privacy and security.
When you’re offline, Warp Drive will continue to work in read only mode. You must have a connection to the internet to create new workflows, update existing workflows, or sync updated workflows from a shared team drive.
Yes! Notebooks can be imported and exported in Markdown format. Workflows can be imported or exported in .yaml.
When our founder was leading engineering on Google Docs, he learned that every productivity application is more powerful when it’s collaborative. This has been shown in many other apps such as Figma, Notion, and Front. It is our team’s bet that the terminal is no exception.
As a side note, “collaboration” does not mean just Google Docs-style real-time collaboration, but also asynchronous collaboration through sharing commands, settings, and history. It means increased knowledge-sharing through wikis and READMEs that run directly in the terminal. It means making the terminal safer and more secure via integrated password-management and audit logging. It means making the terminal a more extensible and customizable platform, with a nice modern ecosystem.
We are built in Rust and do not use Electron - the UI is built on our own rendering layer that leverages lower-level graphics APIs like Metal. An early Warp prototype did use Electron and the team decided it would not be able to provide the level of performance that users should expect from their terminal. Code compiled quickly, but those extra development cycles were spent on profiling and optimization that hasn’t been necessary with Rust.
If you’re interested in learning more about our design decisions, check out: https://www.warp.dev/blog/how-warp-works
We at Warp are huge fans of CLIs: they are easy to build, fast, composable, scriptable, and keyboard-first. GUIs are slower, less flexible, won’t work over SSH, and are not composable, etc.
However, we have observed that more companies are building graphical interfaces to their tools and services; we believe this is, in part, because the limited character-in-character-out protocol of the terminal impairs accessibility and discoverability. Users can’t move their cursors with their mouse. Shells can’t show completion menus to help with discoverability.
We want to keep the best parts of CLIs while modernizing the experience. Warp is still keyboard-first. You can still use the CLI: with Warp you can still write composable commands over SSH. But on top of that, you have access to a code editor for input, and you can discover new and past commands more easily via keyboard-first menus.
We’ve actually written a blog post about the state of CLIs today and why we should build an integrated shell and terminal experience here: https://www.warp.dev/blog/the-terminal-is-on-life-support-is-it-worth-saving.
The first reason is that the terminal is a surprisingly performance intensive application, especially when it comes to rendering full screens of text output on large screens. We want to support 144 fps on 4K monitors. Using the GPU to render helps us achieve the best possible frame rate.
Moreover, on top of text, Warp has GUI elements such as blocks and menus, and they also have to render quickly on large screens.
Picking GPU acceleration has allowed us to be at way over 60fps on a 4K screen, with text and glyphs and rectangles.
While optimizing for performance, we are also cautious about battery consumption for Warp users. We pick the more energy efficient GPUs available and optimize for the number of rendering calls sent to the GPU.
MacOS was our first target. Metal is guaranteed to be the fastest for macOS, and Apple announced in 2018 that they plan to deprecate support for OpenGL across their operating systems.
The Metal debugging tools in Xcode are excellent, allowing us to inspect texture resources and easily measure important metrics like frame rate and GPU memory size.
The tradeoff is that we have to translate the shaders to OpenGL or WebGL as we support more platforms. But thankfully, because we only have to render rectangles and glyphs, our shader code is only a few hundred lines long and easy enough to port. Check out our blog post on how we draw rectangles (all our menus, tabs, and blocks) in Metal: https://www.warp.dev/blog/how-to-draw-styled-rectangles-using-the-gpu-and-metal
For more on the decision, check out: https://www.warp.dev/blog/how-warp-works
We admire his experience with Figma in bringing design to the cloud, as we too hope to turn the traditionally single-user local terminal into a cloud-connected multiplayer terminal.
We chose the name before we settled on using Rust.
It is a Rust-based framework designed to be cross-platform. The framework has two components: it is a layout engine and it handles input from the OS. There are entry points to plug in different types of graphics shaders.
The layout engine creates a scene of rectangles, glyphs and images; we pass these to our graphics renderer, which creates a rendering pipeline for each primitive. You can learn more about this here at: https://www.warp.dev/blog/how-warp-works
The terminal has no concept of what program is running, or really of anything that’s happening within the shell. At a high level, a terminal reads and writes bytes from a pseudoterminal to interact with the shell.
A terminal implements the VT100 spec, which is used to communicate information from the shell to the terminal. For example if the shell wants to tell the terminal to render text red, bold, and underline it would send a specific escape code, which the terminal then parses and renders with the appropriate styles.
Thankfully, most shells provide hooks for before the prompt is rendered (zsh calls this precmd) and before a command is executed (preexec). Using these hooks, we send a custom Device Control String (DCS) from the running session to Warp. OurThis DCS contains an encoded JSON string that includes metadata about the session that we want to render. Within Warp we can parse the DCS, deserialize the JSON, and create a new block within our data model.
We create a separate grid for each command and output based on the precmd/preexec hooks we receive from the shell.
See our changelog by visiting our documentation. We try our best to build in public and prioritize based on community feedback in our GitHub!
