Frequently Asked Questions
- Pricing
Warp Drive is free for up to three (3) team members. There are no hard limits on storage size. There are some limits to the number of objects you have in a shared Team drive. Visit warp.dev/pricing to learn more.
- Pricing
Warp AI is free to use up to 100 requests per user per month. Higher AI limits are available on Warp's Pro and Team pans. Visit warp.dev/pricing to learn more.
Yes! Notebooks can be imported and exported in Markdown format. Workflows can be imported or exported in .yaml.
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.
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.
They’re similar! You can think of workflows in Warp as parameterized aliases you can share. Compared to aliases, it’s also easier to document and search for workflows.
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.
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 and Team 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
The primary reason is that login allows us to build cloud-oriented features that make the terminal have a concept of “your stuff” and “your team’s stuff” – for example Block Sharing. This is the same reason other collaborative apps like Figma and Github require login – identity is the basis of building cloud-native apps.
That said, we understand the desire to try Warp before logging in, and are exploring product experiences that will allow users to preview Warp before signup.
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.
We plan on adding support for Web (WASM) and Windows in 2024. You can join the waitlist for Windows to be notified when this is available.
Rust has pretty extensive platform support—allowing us to write in a single language and then build for Mac, Linux, Windows, and the web, but we have to implement the shaders and bindings for each platform ourselves.
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.
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 have yet to test our latency against other terminals, but we did an initial benchmark of scrolling back in July against Terminal, iTerm, Hyper, Kitty, and Alacritty, if you’re interested: https://www.warp.dev/blog/how-warp-works
Performance is key to us and we have been tracking the following bootup times in our app:
- App Startup to first frame time
- Shell bootstrap time
- Baseline command execution
We monitor them each week for regressions.
Building a terminal is hard. We have to build feature parity, maintain a stable terminal-shell interface, on top of modernizing the product experience.
The money allows us to hire engineers to work on this project full-time and create a great product experience.
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.
First of all, we love Alacritty: our terminal model code is based on Alacritty’s model code. We’re grateful that a few of the collaborators reviewed our early design docs.
We think the two products are meant for two different audiences.
Alacritty has a very minimalist philosophy that suits some terminal power users very well. It’s geared towards folks who are familiar with more advanced tools like tmux, and who are comfortable doing advanced configuration in the shell. For instance, Alacritty has no tabs: users are expected to use tmux.
With Warp, you get similar performance to Alacritty (we are both Rust-based, GPU-accelerated native apps, and Warp leverages some of Alacritty’s model code) But you also get many more built-in features that we think make all developers more productive, like:
- Blocks (grouping commands and outputs together)
- A modern text editor for your input
- Features like Workflows and AI command search that help you perform tasks faster
- Tabs, native split panes, and menus
Like Kitty, Warp is also fast and GPU-accelerated. Kitty is built in Python and C, while Warp is built in Rust.
Both Kitty and Warp are extending the legacy terminal protocol. Kitty is doing so to enable advanced features like colored and styled underlines, graphics protocols, and file transfer. With Warp, we use shell hooks to enable blocks: which group commands and outputs together so you can navigate through your terminal more easily, and copy/share output with a click.
With Warp, you also get other user-friendly out-of-the box features like:
- A code editor for your input
- Features like Workflows and AI command search that help you form commands faster
- Menus for tab completion (with inline documentation) and history
The architecture of Warp is set up so we can support Kitty-like features. We’ve already implemented desktop notifications. And we are planning to support Broadcast Command to All Panes, and its famous terminal graphics protocol (https://github.com/warpdotdev/Warp/issues/26)
Kitty has a comprehensive set of extensions called kittens. Warp’s extensions are not as mature yet. For now, users may add themes and workflows, but we soon want to build more comprehensive extension points into Warp just like kitty has done.
Right now tmux works just the way it does in other terminals, but you lose warp features like blocks and the editor.
We are a work in progress in terms of making tmux a great experience for heavy tmux users. We are looking into allowing you to access features like Blocks in a tmux integration, and are also thinking hard about what a deeper Tmux integration means.
If you have ideas, please join the discussion here: https://github.com/warpdotdev/Warp/discussions/501
See our changelog by visiting our documentation. We try our best to build in public and prioritize based on community feedback in our GitHub!
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
