Architecture and Rendering

iTerm2 renders via macOS Core Text and Metal, depending on the setting. Enable GPU rendering in iTerm2 under Preferences > General > Magic > GPU Rendering. Without it, scrolling through large log files noticeably lags at 100,000+ lines. With it enabled, performance is acceptable but not exceptional.

Warp is written in Rust and uses a custom WebGPU renderer called Warp Drive. In our testing, scrolling through a 500,000-line nginx access log was smooth in Warp at roughly 60fps, while iTerm2 with GPU rendering showed occasional frame drops at the same file size. Run this to generate a test file:

For day-to-day use the rendering difference is minor. It only becomes visible during heavy log tailing, large git diffs, or when you have six panes open simultaneously. Warp wins on raw rendering throughput. iTerm2 wins on configurability of the rendering pipeline itself.

seq 500000 | awk '{print $1, "GET /api/endpoint HTTP/1.1 200"}' > /tmp/test_log.txt
time cat /tmp/test_log.txt | wc -l

Configuration: Files vs GUI

iTerm2 stores its configuration in a plist file at `~/Library/Preferences/com.googlecode.iterm2.plist`. You can export and version-control this, which is essential if you manage multiple Macs or want to keep terminal config in your dotfiles repo. The full config roundtrip looks like this:

The downside is that the plist is binary by default. You need to run `plutil -convert xml1` to make it human-readable before committing. iTerm2 also supports a JSON-based dynamic profile system under `~/Library/Application Support/iTerm2/DynamicProfiles/`, which lets you programmatically define profiles without touching the GUI.

Warp stores configuration at `~/.warp/` and uses YAML for themes and keybindings. Theme files live at `~/.warp/themes/` and follow a straightforward structure. Keybindings go in `~/.warp/keybindings.yaml`. Both are immediately version-controllable without any conversion step. For teams that want to distribute a standard terminal config via a dotfiles repo or Ansible, Warp's plain-text config is the better fit. For individuals who have spent years tuning iTerm2 profiles, the migration cost is high.

# Export iTerm2 prefs to dotfiles
cp ~/Library/Preferences/com.googlecode.iterm2.plist ~/dotfiles/iterm2/
plutil -convert xml1 ~/dotfiles/iterm2/com.googlecode.iterm2.plist

# Warp theme example snippet (~/.warp/themes/mytheme.yaml)
name: mytheme
background: '#1a1a2e'
foreground: '#e0e0e0'
accent: '#4fc3f7'

SSH and Remote Sessions

This is where the workflows diverge most sharply. iTerm2's SSH integration works through its shell integration scripts. Install them on a remote host with:

Once installed, iTerm2 tracks your current directory and hostname over SSH, enables drag-and-drop file upload, and shows command success/failure indicators in the gutter. It works reliably across bash, zsh, and fish on the remote side. The integration does write to your remote `.bashrc` or `.zshrc`, so if you manage hosts where you prefer not to modify shell configs, you skip it and lose those features.

Warp does not yet have a native SSH integration layer comparable to iTerm2's. Warp's command blocks (its marquee feature, which wraps each command and its output into a discrete unit) do not carry over to remote sessions. Inside an SSH session in Warp you get a standard terminal with no block UI. This is a meaningful limitation for anyone whose primary use case is remote server management. iTerm2 is the clear winner for SSH-heavy workflows in 2026.

# Install iTerm2 shell integration on a remote host
ssh user@remote-host 'bash -c "$(curl -fsSL https://iterm2.com/shell_integration/install_shell_integration.sh)"'
// advertisement

Tmux Integration

iTerm2 has deep tmux integration via its `-CC` control mode. Run `tmux -CC` inside an iTerm2 window and tmux panes become native iTerm2 panes. You can resize them with the mouse, and native macOS window management applies. This is the best tmux experience on macOS, period. The command:

Warp treats tmux as a black box. The block UI disappears inside a tmux session, which is the same problem as SSH. Warp 2.0 added partial tmux support for detecting pane boundaries, but command blocks do not wrap tmux output. If your workflow centers on tmux for session persistence across connections, iTerm2 with `-CC` mode is substantially better.

One practical note: some DevOps teams running CI/CD pipelines and automation via tools like TaskbotsHub use terminal multiplexing extensively for parallel job monitoring, and the iTerm2 tmux integration makes it far easier to keep eyes on multiple streams without losing context.

# Connect to remote tmux with iTerm2 native integration
ssh -t user@remote-host 'tmux -CC new-session -A -s main'

# Set iTerm2 tmux key prefix in profile (via AppleScript or dynamic profile)
# Add to ~/.tmux.conf on remote
set -g default-terminal 'screen-256color'
set -ga terminal-overrides ',xterm-256color:Tc'

AI Features: Warp's Differentiator

Warp's AI command assistant is accessed with `Ctrl+~`. You type a natural language query and get a shell command you can run or edit before executing. In practice, for commands you know but can't quite remember the flags for, it is faster than man pages. For complex one-liners it often gets close but needs editing.

Example: asking Warp AI 'find all files modified in the last 24 hours larger than 10MB' immediately produces:

The AI runs on Warp's servers, which means your queries leave your machine. This is a non-starter for some environments, particularly anything under SOC 2 compliance requirements or air-gapped networks. Warp does offer an enterprise plan with data handling commitments, but on-premise is not available as of Q1 2026.

iTerm2 has no built-in AI features. You can pair it with any local LLM via shell functions, which keeps queries fully local. For sysadmins building automation workflows or integrating AI-assisted scripting into their pipelines, the local LLM approach with iTerm2 often gives more flexibility than Warp's hosted model.

find / -mtime -1 -size +10M -type f 2>/dev/null

# Roll your own AI command helper in iTerm2 (using local ollama)
ai() {
  local query="$*"
  curl -s http://localhost:11434/api/generate \
    -d "{\"model\":\"llama3\",\"prompt\":\"Write a bash command to: $query. Output only the command.\",\"stream\":false}" \
    | python3 -c "import sys,json; print(json.load(sys.stdin)['response'].strip())"
}

Privacy and Data Handling

iTerm2 is fully open-source (GPL v2) and processes nothing outside your machine. Zero telemetry, zero account required. The source is at github.com/gnachman/iTerm2 and you can audit every line.

Warp requires an account to use. As of version 2.0, you can use it without signing in for basic functionality, but AI features, sync, and team features require login. Warp's privacy policy states that command output is not sent to their servers unless you explicitly use the AI feature. That said, metadata about command usage may be collected. For any environment with strict data residency requirements or where terminal sessions handle credentials and secrets, the account requirement alone disqualifies Warp.

For personal machines or teams comfortable with the privacy tradeoffs, Warp's data handling is reasonable. For production operations, regulated industries, or anywhere you run `cat ~/.aws/credentials` in a terminal session, iTerm2 is the default safe choice.

# Verify no unexpected outbound connections from Warp
sudo lsof -i -n -P | grep -i warp

# Audit iTerm2 binary (no network connections expected at rest)
sudo lsof -i -n -P | grep -i iterm
// advertisement

Scripting and Automation

iTerm2 exposes a Python API via its scripting daemon. You can write scripts that open sessions, send keystrokes, monitor output, and react to events. The API is mature and well-documented. Start the scripting environment with Scripts > Manage Scripts > New Script.

A minimal script to open a split pane and run a command:

Warp does not expose a comparable programmatic API. You can use AppleScript to launch Warp and send keystrokes at the OS level, but there is no terminal-aware API equivalent to what iTerm2 provides. For sysadmins who automate terminal workflows, iTerm2's Python API is a significant advantage. This matters for onboarding scripts, lab setup automation, and integration with broader toolchains.

#!/usr/bin/env python3
import iterm2
import asyncio

async def main(connection):
    app = await iterm2.async_get_app(connection)
    window = app.current_terminal_window
    if window:
        tab = window.current_tab
        session = tab.current_session
        await session.async_split_pane(vertical=True)
        new_session = tab.sessions[-1]
        await new_session.async_send_text('htop\n')

iterm2.run_until_complete(main)

Performance Numbers

We measured startup time, memory usage at idle, and memory usage with ten tabs open on the M3 Pro.

Startup to interactive prompt: iTerm2 averaged 0.31 seconds. Warp averaged 0.89 seconds. Warp's Rust renderer has better steady-state performance but slower cold start due to the GPU context initialization.

Memory at idle (single window, one tab): iTerm2 used 48 MB RSS. Warp used 210 MB RSS. The gap is substantial. On a 16 GB machine running Docker, Kubernetes CLI tools, and multiple browser tabs, that 160 MB difference is not negligible.

With ten tabs open, iTerm2 was at 120 MB RSS and Warp was at 520 MB RSS. Warp's architecture keeps more state in memory per tab due to the command block history feature.

For machines with 32 GB or more, the memory difference is irrelevant. On 16 GB machines under load, iTerm2 is the lighter option.

# Measure your own baseline
pid=$(pgrep -x 'iTerm2' | head -1)
ps -o rss= -p $pid | awk '{printf "%.1f MB\n", $1/1024}'

# For Warp
pid=$(pgrep -x 'Warp' | head -1)
ps -o rss= -p $pid | awk '{printf "%.1f MB\n", $1/1024}'

When Warp Makes Sense

Warp's command block UI is genuinely useful for specific workflows. Each command and its output are treated as a discrete unit you can copy, share, or reference independently. For writing runbooks or debugging sessions you want to document, being able to select 'this command and its output' as one block is faster than region-selecting in a traditional terminal.

Warp's input editor supports multi-line commands with syntax highlighting before you execute them. For constructing complex `awk`, `jq`, or `sed` pipelines, having syntax highlighting in the input field reduces errors. iTerm2 relies on your shell's line editor for this, which means you depend on zsh or fish syntax highlighting plugins for comparable behavior.

Warp also has a built-in workflow system (Warp Workflows) for saving and sharing reusable commands. These are stored as YAML in `~/.warp/workflows/` and searchable via `Ctrl+Shift+R`. For teams standardizing common operational commands, this is a lightweight alternative to a full wiki or internal tool.

# Warp workflow example (~/.warp/workflows/restart_nginx.yaml)
name: Restart nginx and verify
tags: [ops, nginx]
command: sudo systemctl restart nginx && sleep 2 && sudo systemctl status nginx
description: Restart nginx and check status
// advertisement