Pane vs Ghostty

renderização de fontes e desempenho na GPU

O Ghostty usa seu próprio renderizador por GPU, com Metal no macOS e OpenGL no Linux. A renderização de fontes, incluindo ligaduras, emoji e fontes coloridas, é um objetivo central do projeto, e para quem passa horas no terminal, dá para notar.

libghostty incorporável

Mitchell Hashimoto publicou uma visão para o libghostty em setembro de 2025 - uma biblioteca C/Zig incorporável que permite a qualquer app usar a renderização do Ghostty. O cmux (o terminal de agentes para macOS) já é construído sobre o libghostty. Isso posiciona o Ghostty como uma base de renderização, e não como um app pronto, o que é uma aposta forte de ecossistema.

licença MIT, financiado pela comunidade

O Ghostty tem licença MIT, sem restrições comerciais. Ele tem patrocínio fiscal da Hack Club (uma 501(c)(3)), depois que a família de Mitchell doou pessoalmente US$ 150 mil para iniciar o projeto. Não há pressão de investidores de venture capital nem plano pago. O código é totalmente aberto e pode receber forks.

conformidade com padrões e interface nativa em cada plataforma

O Ghostty tem a conformidade com padrões como objetivo prioritário: sequências de escape do xterm, códigos OSC, gráficos sixel. No macOS ele usa SwiftUI; no Linux, GTK. Cada plataforma ganha uma moldura de janela nativa, não uma camada de compatibilidade multiplataforma.

sem notificações que conheçam os agentes

A discussão do Ghostty sobre fluxos de trabalho com agentes + tmux documenta essa lacuna com clareza: não existe um mecanismo para disparar uma notificação de desktop quando um agente específico, em um painel específico do tmux, entra em espera. As alternativas - loops de polling, scripts com tmux send-keys, gatilhos de AppleScript - exigem manter ferramentas próprias que quebram a cada atualização do tmux e do Ghostty.

configuração manual de worktree por agente

Cada agente em paralelo precisa da sua própria branch e da sua própria cópia do sistema de arquivos. Com a stack caseira, isso significa git worktree add antes de cada agente e git worktree remove para limpar depois. Com 4 ou mais agentes rodando todo dia, isso soma dezenas de comandos manuais por semana.

o cansaço de ficar conferindo

Para saber qual agente está esperando uma resposta, ou você passa na mão por todas as janelas do tmux ou escreve um script de polling. Nenhuma das duas opções escala. O custo de trocar de contexto para conferir 4 ou mais agentes espalhados por janelas do tmux anula boa parte do ganho do paralelismo.

sem revisão de diffs unificada

Quando um agente termina, revisar as mudanças dele significa ir para aquela janela do tmux e rodar git diff ou gh pr diff no terminal. Não existe um visualizador de diffs unificado, com destaque de sintaxe, para todos os agentes. Commit e push são mais uma etapa manual por agente.

automação de worktrees

Crie um pane e uma worktree do git é criada para ele em uma branch própria, com seus arquivos .env e as configurações do agente copiados. Arquive o pane e a worktree é removida depois que o Pane confere que nada ficou sem salvar. Nada de ciclo manual de git worktree add e remoção.

orquestração de vários agentes

O Pane dá a cada agente sua própria sessão isolada, com um indicador de status visível. Quando um agente espera uma resposta, uma notificação de desktop aparece na hora - sem polling, sem scripts bash. Você vê todos os agentes em uma única interface.

multiplataforma

O Pane roda no Windows, macOS e Linux com o mesmo fluxo de trabalho, e roda os agentes dentro do WSL para os repositórios que ficam lá. Se a sua equipe tem desenvolvedores no Windows, todo mundo pode usar a mesma configuração.

revisão de diffs e commit pelo teclado

Quando um agente termina, aperte ⌘⇧B (Ctrl+Shift+B no Windows e no Linux) para abrir o painel Changes com os diffs com destaque de sintaxe, depois ⌘⇧K para fazer commit e ⌘⇧U para fazer push, sem tirar as mãos do teclado nem trocar de janela. A stack caseira exige comandos de terminal em cada etapa, para cada agente.