Frequently Asked Questions

How much does Warp Drive cost?

Warp Drive is free for up to five team members. Warp Drive for teams is in a free preview, after which teams will be billed $12 per member per month. There are no hard limits on storage size or the number of objects you can store.

Pricing

How much does Warp AI cost?

Warp AI is currently in a free preview. When the preview ends, Warp AI will be free up to 20 requests per day. Power users of Warp AI will have the option to upgrade to a Team plan with a higher limit of 100 requests per day. Please enjoy Warp AI while it's free to try!

Can I import or export workflows from Warp Drive?

Every workflow is saved in a standardized data file format. In the future, you’ll be able to import and export workflows as .yaml files. Learn more about file formats for workflows.

Does Warp Drive work locally?

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.

‍

Where are Warp Drive contents stored?

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.

‍

What is the difference between a workflow and an alias?

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.

‍

Does OpenAI use my data to train their models?

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.

What does Warp AI's Zero Data Retention policy mean on the Enterprise plan?

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.

When will you open-source Warp?

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

I’m uncomfortable that your terminal is closed-source now.

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)

Why is login required for a terminal app?

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.

What is your business model and pricing model?

The terminal is totally free for individuals. Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.

The general philosophy is that we would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that. The types of features we could eventually 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 and only charged in a company context.

We will never sell your data. We treat privacy very seriously at Warp: check out www.warp.dev/privacy/overview for more information.

Does Warp work offline? Why is the terminal connected to the cloud?

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.

Is there a timeline for Windows support?

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.

What does "targeting web" for a terminal mean to you?

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.

Why bring collaboration to the terminal?

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.

Is Warp built in Electron?

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

Why build GUIs into the terminal? I love the terminal because it is not a GUI.

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.

Why did you build Warp to be GPU-accelerated?

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.

Why did you pick Metal over OpenGL for graphics?

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

There is no mention of latency? Have you benchmarked this?

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.

Why did you raise money to build a terminal?

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.

Why did you raise your Series A from Dylan Field?

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.

Why did you use the same name as the warp web server framework?

We chose the name before we settled on using Rust.

What does your UI framework do?

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

How did you implement blocks?

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.

How is Warp different from Alacritty?

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

How is Warp different from Kitty?

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.

How would you convince a Tmux user to use Warp?

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

What’s on your roadmap?

See our changelog by visiting our documentation. We try our best to build in public and prioritize based on community feedback in our GitHub!

How do I send feedback?

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

Experience the power of Warp

Write with an IDE-style editor
Easily navigate through output
Save commands to reuse later

Ask Warp AI to explain or debug
Customize keybindings and launch configs
Pick from preloaded themes or design your own

Success! You will receive an email from Warp with the download link.

Oops! Something went wrong while submitting the form.