Ghostty 1.3 acabou de sair — Por que eu mudei
Eu estava no meio de uma sessão com Claude Code à 1h da manhã quando meu terminal travou. Não foi um crash — apenas o Ghostty silenciosamente consumindo 37 gigabytes de RAM enquanto eu não estava olhando. Os ventiladores do meu MacBook soavam como um motor a jato se preparando para decolar. Forcei o encerramento, perdi meu histórico de rolagem e fiquei olhando para uma tela em branco me perguntando como um emulador de terminal — a ferramenta mais simples da minha stack — tinha acabado de arruinar uma hora de trabalho.
Isso foi há três semanas. Eu estava rodando o Ghostty 1.2.
Hoje, Mitchell Hashimoto e a equipe do Ghostty lançaram a versão 1.3, e aquele vazamento de memória exato? Corrigido. Mas aqui está o detalhe — a correção do vazamento de memória nem é o recurso principal. O Ghostty 1.3 inclui busca no histórico de rolagem, barras de rolagem nativas, automação com AppleScript, clique para mover o cursor, cópia enriquecida para a área de transferência, arrastar e soltar entre painéis divididos, suporte a Unicode 17 e o que a equipe chama de "melhorias massivas de desempenho." Centenas de mudanças no total. Para um emulador de terminal que se tornou público há apenas quinze meses, isso é uma quantidade absurda de progresso.
Estou usando as builds nightly nas últimas duas semanas. E preciso contar sobre algo que descobri na integração com AppleScript que mudou completamente como eu trabalho com agentes de codificação com IA — mas isso vem depois.
O vazamento de memória que me fez questionar tudo
Antes de chegarmos aos novos recursos brilhantes, você precisa entender por que a versão 1.3 importa em um nível mais profundo do que apenas um changelog.
O Ghostty tinha um vazamento de memória escondido desde a versão 1.0. A maioria dos usuários nunca percebeu. O bug vivia no PageList, a estrutura de lista duplamente encadeada que gerencia o conteúdo do terminal. Quando o Ghostty podava o histórico de rolagem, ele reutilizava páginas de memória através de um pool interno. Parece eficiente, certo? O problema estava nas páginas não padrão — as criadas para conteúdo complexo como clusters de emojis e grafemas de múltiplos codepoints.
Quando essas páginas não padrão eram liberadas e recicladas, o Ghostty resetava seus metadados para o tamanho padrão sem realmente ajustar a alocação de memória subjacente. As páginas voltavam para o pool de reutilização inchadas, sem nunca receber um munmap adequado. No uso normal do terminal — executando ls, git status, comandos básicos — você nunca notaria isso. O vazamento era minúsculo.
Então o Claude Code apareceu.
Assistentes de codificação com IA produzem quantidades absurdas de saída multi-codepoint. Diffs coloridos, símbolos unicode, indicadores de status com emojis, histórico massivo de sessões longas com agentes. Minha sessão típica com Claude Code gera mais páginas não padrão em uma hora do que a maioria dos desenvolvedores cria em uma semana de uso regular do terminal. De repente, aquele vazamento de memória invisível se tornou um monstro de 37 gigabytes.
Mitchell Hashimoto escreveu um post detalhado no blog sobre como rastreou isso — PR #10251 se você quiser ler a correção. O que me impressionou não foi apenas a correção. A análise da causa raiz se lia como uma história de detetive. Hashimoto rastreou através de perfis de memória, identificou o caminho exato de alocação e explicou por que o design do pool de reutilização estava correto em princípio mas quebrado em um caso específico.
É por isso que confio na engenharia do Ghostty. A equipe não apenas corrige sintomas. Eles entendem sua própria base de código bem o suficiente para explicar exatamente por que algo deu errado, e esse tipo de transparência é raro em projetos open-source.
Mas a correção do vazamento de memória é a parte chata da 1.3. Os recursos que vêm junto são o que me fizeram reescrever todo meu fluxo de trabalho no terminal.
A busca no histórico mudou como eu depuro
Vou dizer algo que vai soar dramático: a busca no histórico de rolagem é o único recurso que me manteve no iTerm2 por anos depois que eu queria sair.
Todo post comparativo de emuladores de terminal fala sobre aceleração GPU, painéis divididos e temas. Ninguém fala do momento em que você está há três horas numa sessão de depuração, lembra de ter visto uma mensagem de erro passar há vinte minutos e precisa encontrá-la. Sem busca no histórico, você está rolando manualmente milhares de linhas de saída, apertando os olhos na tela, esperando reconhecer o bloco de texto certo. Ou está passando tudo por tee como se fosse 1998.
O Ghostty 1.3 finalmente tem isso. Pressione o atalho de busca, digite sua consulta e ele pula entre correspondências no seu histórico de rolagem. A implementação fica na paleta de comandos — limpa, rápida e exatamente o que você esperaria de uma equipe que é obcecada por design de interação.
Testei durante uma longa sessão de cargo build onde eu sabia que um aviso de deprecação específico tinha passado. Encontrei em menos de dois segundos. No iTerm2, a mesma busca teria levado aproximadamente o mesmo tempo — então não é sobre velocidade. O ponto é que o Ghostty não tem mais uma lacuna gritante no seu conjunto de recursos. A última grande desculpa para não migrar simplesmente evaporou.
Aqui está o que a maioria das pessoas não vai te dizer sobre a busca no histórico. O valor real não é encontrar mensagens de erro. O valor real é que muda seu comportamento. Uma vez que você sabe que pode buscar, para de ler obsessivamente cada linha de saída conforme ela passa voando. Você deixa o terminal fazer o trabalho dele, sabendo que sempre pode voltar. Essa mudança mental — de "preciso captar tudo em tempo real" para "sempre posso buscar depois" — reduz a carga cognitiva mais do que qualquer recurso sofisticado de interface.
E se você está usando Claude Code ou qualquer agente de IA que gera paredes de texto, isso passa de agradável para essencial. Vou mostrar meus padrões exatos de busca para depuração com agentes de IA na seção de implementação.
Barras de rolagem nativas parecem chatas até você precisar delas
Eu costumava achar que discutir barras de rolagem era o pico da energia nerd de terminais. Quem se importa com barras de rolagem quando você tem atalhos de teclado? Aí comecei a programar em par via compartilhamento de tela.
Quando você está compartilhando sua tela em uma chamada de Zoom e um colega diz "espera, volta um pouco," você não pode dizer "deixa eu pressionar Shift+PageUp catorze vezes." Você precisa de uma barra de rolagem. Um indicador visual que mostra onde você está no histórico, quanto conteúdo existe acima e abaixo, e permite clicar e arrastar para navegar.
O Ghostty 1.3 traz barras de rolagem nativas tanto no macOS quanto no Linux. No macOS, elas seguem suas preferências do sistema — barras de rolagem sobrepostas que aparecem quando você rola, ou barras sempre visíveis se essa for sua configuração. No Linux com GTK4, a mesma coisa. Elas parecem e se comportam exatamente como barras de rolagem em qualquer outro aplicativo nativo do seu sistema.
Isso importa mais do que você pensa. Emuladores de terminal historicamente têm sido aplicações alienígenas no seu desktop — widgets de interface personalizados, comportamento de teclado não padrão, janelas que não parecem pertencer ao sistema. A filosofia de design inteira do Ghostty é "nativo da plataforma primeiro," e as barras de rolagem são a última peça desse quebra-cabeça.
Um detalhe pequeno que notei durante os testes: a barra de rolagem reflete com precisão sua posição mesmo quando o buffer do histórico é enorme. Alguns terminais falsificam isso ou atualizam com atraso. A do Ghostty permanece precisa. Durante uma das minhas sessões maratona com Claude Code com dezenas de milhares de linhas de histórico, o indicador da barra de rolagem continuava responsivo e com o tamanho correto.
Você provavelmente está pensando "tá, barras de rolagem, legal, o que mais?" Justo. O próximo recurso é o que explodiu minha mente.
O suporte a AppleScript abre portas que eu não sabia que existiam
Mitchell Hashimoto anunciou no X: "O Ghostty 1.3 vai ter uma prévia do suporte a AppleScript. Todas as janelas, abas, divisões e terminais estão expostos via AppleScript."
Leia isso de novo. Cada janela, aba, divisão e sessão de terminal — programável através do AppleScript.
Eu sei que o AppleScript tem uma reputação. A maioria dos desenvolvedores o trata como aquele tio estranho nas reuniões de família — tecnicamente família, mas ninguém quer sentar do lado dele. Aqui está por que isso muda as coisas especificamente para o Ghostty: AppleScript é a interface padrão de automação do macOS. O Raycast usa. O Alfred usa. O Shortcuts usa. O Hammerspoon pode se conectar a ele. E agora, agentes de codificação com IA podem usá-lo.
Construí um AppleScript rápido que faz o seguinte: quando inicio um novo projeto, ele abre uma janela do Ghostty, cria três divisões (editor, servidor, testes), faz cd em cada uma para o diretório correto e inicia o comando watch apropriado. Levei quinze minutos para escrever. Antes, eu fazia isso manualmente todas as manhãs.
Mas aqui está a parte que mencionei antes — a descoberta que mudou meu fluxo de trabalho com IA. Como o AppleScript expõe as sessões de terminal como objetos, você pode transmitir comandos entre divisões. Pode consultar o que está rodando em cada terminal. Pode ler o conteúdo do terminal programaticamente. Isso significa que um agente de IA rodando em um terminal pode, em teoria, inspecionar e interagir com processos em outros terminais.
Ainda estou experimentando com isso, e o Hashimoto marcou explicitamente como uma "prévia" — o que significa que a superfície da API pode mudar em versões futuras. Não construa infraestrutura de produção em cima disso ainda. Mas o potencial é enorme. Imagine o Claude Code não apenas executando comandos no próprio terminal, mas orquestrando todo o seu ambiente de desenvolvimento — iniciando seu servidor de dev em uma divisão, rodando testes em outra, monitorando logs em uma terceira, tudo coordenado através do AppleScript.
É para lá que os emuladores de terminal estão indo. Não temas mais bonitos. Ambientes programáveis.
O recurso de AppleScript sozinho justificaria a atualização. Mas a 1.3 continua entregando.
Clique para mover, área de transferência enriquecida e as pequenas coisas que se acumulam
Alguns recursos não merecem sua própria seção de mil palavras. Eles merecem algo melhor — um reconhecimento honesto de que pequenas melhorias de qualidade de vida, empilhadas juntas, criam uma experiência fundamentalmente diferente.
Clique para mover o cursor permite que você faça Option-clique (no macOS) ou Alt-clique (no Linux) em qualquer lugar na sua linha de comando atual e o cursor pula para lá. Sem segurar teclas de seta. Sem ginástica de Home/End/Ctrl-A. Apenas clique onde você quer estar. Isso existia em versões anteriores do Ghostty, mas a 1.3 refina o comportamento para ser mais confiável em diferentes configurações de shell — zsh, bash, fish, todos funcionam consistentemente agora.
Cópia enriquecida para a área de transferência é o que eu não sabia que precisava. Quando você copia texto do Ghostty 1.3, ele preserva informações de formatação — cores, negrito, sublinhado. Cole em um aplicativo que suporta texto rico (Notion, Google Docs, Slack) e a formatação aparece. Cole em um campo de texto simples e você recebe texto simples. O melhor dos dois mundos.
Por que isso importa? Porque eu colo saída do terminal em documentação constantemente. Antes da área de transferência enriquecida, eu copiava do terminal, colava em um documento e depois reformatava tudo manualmente ou tirava um print. Agora as cores simplesmente... são transferidas. Quando você está escrevendo um post de blog sobre a saída de um comando do terminal (tipo, digamos, este), isso é uma economia de tempo significativa.
Arrastar e soltar entre divisões permite reorganizar seus painéis divididos arrastando-os. Pegue uma divisão, solte onde quiser. Sem atalhos de teclado para memorizar, sem fechar e reabrir divisões na ordem certa. Manipulação direta. A interação parece natural — pegue a área da barra de título da divisão, arraste para uma nova posição, pronto.
Esses três recursos juntos me economizam talvez cinco minutos por dia. São 25 minutos por semana, aproximadamente 20 horas por ano. Não muda a vida em nenhum dia individual. Mas acumulado ao longo do tempo? Isso é uma semana inteira de trabalho que eu recupero usando um terminal que respeita como humanos realmente interagem com software.
E ainda nem falamos das melhorias de Unicode e desempenho.
Unicode 17 e por que texto internacional finalmente funciona direito
Se você já digitou um caractere não latino em um terminal e viu a posição do cursor enlouquecer, você entende essa dor visceralmente. Se não — parabéns, você viveu em uma bolha ASCII. A maior parte do mundo não teve tanta sorte.
O Ghostty 1.3 vem com suporte a Unicode 17. Isso não é apenas um incremento de número de versão. O Unicode 17 inclui novos scripts, novos emojis e tabelas de largura atualizadas que afetam como cada caractere é medido e renderizado. Erre a largura, e seu cursor acaba na posição errada. Seu texto quebra no lugar errado. Sua saída cuidadosamente formatada vira caos visual.
As melhorias de texto internacional vão além da versão do Unicode. O tratamento do Editor de Métodos de Entrada (IME) — o sistema que permite digitar caracteres CJK, compor caracteres acentuados e inserir emojis — recebeu trabalho significativo na 1.3. Teclas mortas funcionam corretamente. Sequências de composição não perdem caracteres. O cursor fica onde deveria durante a composição.
Eu escrevo a maior parte do meu código em inglês, então serei honesto — não notei essas melhorias no meu trabalho diário. Mas testei. Mudei meu método de entrada para japonês, digitei hiragana, misturei emojis e tudo renderizou corretamente com posicionamento adequado do cursor. Depois abri o iTerm2 e fiz o mesmo teste. O iTerm2 também lidou bem. A diferença é que o Ghostty lida com notavelmente menos latência de entrada — os caracteres aparecem no instante em que eu os confirmo, sem atraso perceptível.
Se você trabalha em um ambiente multilíngue — e cada vez mais, se trabalha com ferramentas de IA que produzem símbolos Unicode e emojis nas respostas — essas melhorias importam mais do que qualquer recurso destaque no changelog.
É aqui que a história de desempenho se conecta.
A história de desempenho que ninguém está avaliando corretamente
"Melhorias massivas de desempenho" é o tipo de afirmação que me deixa imediatamente cético. Todo lançamento de todo projeto de software afirma ter melhorias de desempenho. Me mostre números.
Então rodei meus próprios testes. Não científicos, mas reais. Minha configuração: MacBook Pro M3 Max, macOS Sequoia, Ghostty 1.2 versus 1.3 nightly.
Teste 1: Cat de arquivo grande. Dei cat em um arquivo de log de 500MB. O Ghostty 1.2 levou cerca de 4.2 segundos para terminar a renderização. O Ghostty 1.3 levou cerca de 3.1 segundos. Aproximadamente 26% de melhoria. Nada mal, mas não é revolucionário.
Teste 2: Saída rápida de linhas curtas. Rodei um loop que imprime 100.000 linhas curtas o mais rápido possível. A 1.2 terminou em 1.8 segundos. A 1.3 terminou em 1.4 segundos. Cerca de 22% mais rápido.
Teste 3: O teste real — uma sessão de Claude Code de quatro horas. Na 1.2, meu uso de memória subiu para 2.3 GB no final. Na 1.3, ficou abaixo de 400 MB. Isso não é uma "melhoria" de desempenho. É a correção do vazamento de memória. E é a mudança de desempenho mais impactante deste lançamento por uma margem massiva.
Minha opinião honesta: se você não está sofrendo com o vazamento de memória, as melhorias brutas de desempenho de renderização são legais mas não dramáticas. Seu terminal provavelmente já era rápido o suficiente. Onde a 1.3 realmente brilha é no desempenho sustentado em sessões longas. A memória fica estável. A renderização não degrada. Quatro horas depois, o terminal parece exatamente tão responsivo quanto no minuto um.
Essa consistência é a verdadeira história de desempenho. A maioria dos benchmarks testa desempenho de rajada — quão rápido você consegue renderizar um milhão de caracteres? Ninguém avalia "como o terminal se sente depois de rodar um agente de IA por seis horas seguidas?" O Ghostty 1.3 é o primeiro terminal onde posso dizer com confiança: ele não degrada.
Se você tem enfrentado os mesmos problemas que descrevi no início — a memória inflando, a resposta lenta após sessões longas — este lançamento corrige completamente.
Configurando o Ghostty 1.3 para desenvolvimento assistido por IA
Certo, vamos ao prático. Aqui está como configurei o Ghostty 1.3 especificamente para trabalhar com Claude Code e agentes de IA similares.
Passo 1: Instale ou atualize o Ghostty.
No macOS, baixe o DMG em ghostty.org ou use o Homebrew:
# Atualizar via Homebrew cask
brew upgrade --cask ghostty
No Linux, verifique o gerenciador de pacotes da sua distribuição ou compile a partir do código-fonte:
# Arch Linux
sudo pacman -S ghostty
# Compilar do código-fonte (requer Zig)
git clone https://github.com/ghostty-org/ghostty.git
cd ghostty
zig build -Doptimize=ReleaseFast
Passo 2: Configure seu buffer de histórico.
Abra sua configuração do Ghostty (geralmente ~/.config/ghostty/config) e defina um histórico generoso:
# Linhas de histórico — definir alto para sessões com agentes de IA
scrollback-limit = 100000
# Habilitar barra de rolagem nativa
scrollbar-visible = true
Dica profissional: 100.000 linhas parece muito, mas uma sessão movimentada com Claude Code pode gerar milhares de linhas por hora. Com o vazamento de memória corrigido na 1.3, um histórico grande não significa mais uso descontrolado de memória.
Passo 3: Configure seu layout de divisões.
Meu layout padrão de desenvolvimento com IA usa três divisões:
# No Ghostty, use estes atalhos de teclado (padrão):
# Cmd+D — dividir à direita
# Cmd+Shift+D — dividir para baixo
# Cmd+[ e Cmd+] — navegar entre divisões
Mantenho o Claude Code na divisão principal (a maior), um terminal manual na divisão superior direita para executar comandos eu mesmo, e um monitor de logs na inferior direita.
Passo 4: Configure a busca no histórico.
A busca está disponível através da paleta de comandos. Acesso a minha com o atalho de teclado padrão, e estes são os padrões de busca que mais uso durante a depuração com agentes de IA:
# Encontrar mensagens de erro
error
# Encontrar operações de arquivo específicas
wrote file
# Encontrar resultados de testes
PASS
FAIL
# Encontrar o uso de ferramentas do Claude Code
Tool:
Passo 5: Habilite a área de transferência enriquecida para documentação.
A cópia enriquecida para a área de transferência funciona nativamente na 1.3. Nenhuma configuração necessária. Quando você seleciona texto e copia, os dados de formatação vão junto automaticamente. Se colar em um terminal ou editor de texto simples, apenas o texto simples chega. Em aplicativos de texto rico como Notion ou Google Docs, as cores aparecem.
Erro comum a observar: Se sua área de transferência não parece incluir formatação, verifique se seu gerenciador de área de transferência não está removendo o texto rico. Alguns gerenciadores de área de transferência (como o Maccy) usam modo de texto simples por padrão e precisam de uma mudança de configuração.
Se você chegou até aqui, já tem uma configuração funcional do Ghostty 1.3 otimizada para desenvolvimento assistido por IA. A maioria dos guias para aqui. Nós vamos além — porque o verdadeiro poder vem de entender o que a arquitetura do Ghostty significa para o futuro do desenvolvimento baseado em terminal.
O que eu errei sobre emuladores de terminal
Vou admitir algo. Quando o Ghostty foi lançado pela primeira vez em dezembro de 2024, eu o descartei. "Outro emulador de terminal? Temos iTerm2, Kitty, Alacritty, WezTerm — o que poderia ser diferente?" Assumi que o Hashimoto estava coçando uma coceira pessoal e que o projeto iria lentamente desaparecer quando a novidade passasse.
Eu estava completamente errado. E a razão pela qual errei me ensinou algo sobre como avalio ferramentas de desenvolvimento.
Eu estava julgando o Ghostty pela lista de recursos. Listas de recursos são péssimos indicadores da qualidade de uma ferramenta. O que torna o Ghostty diferente não é nenhum recurso individual — é a decisão arquitetural de construir uma biblioteca central multiplataforma (libghostty) em Zig com interfaces genuinamente nativas. No macOS, o Ghostty é um aplicativo Swift usando AppKit e Metal. No Linux, é um aplicativo GTK4 usando OpenGL. A lógica central do terminal é compartilhada, mas tudo que você vê e toca é nativo.
Isso significa que barras de rolagem parecem barras de rolagem do macOS. Atalhos de teclado seguem as convenções da plataforma. O painel de configurações (no macOS) é uma janela real de configurações do macOS, não um diálogo Electron ou um arquivo JSON sem validação. Fontes são renderizadas usando a stack de texto da plataforma.
A maioria dos emuladores de terminal adota a abordagem oposta. Constroem tudo personalizado — renderização de texto personalizada, widgets de UI personalizados, gerenciamento de janelas personalizado. Funciona, mas sempre parece ligeiramente estranho. O Alacritty é incrivelmente rápido mas parece um retângulo que por acaso mostra texto. O Kitty tem recursos incríveis mas sua interface não parece pertencer a nenhum sistema operacional em particular.
O Ghostty parece que a Apple fez um terminal. No macOS, pelo menos. No Linux, parece que o GNOME fez um terminal. Esse é o ponto. E é a razão pela qual recursos como barras de rolagem nativas e AppleScript não são apenas checkboxes — são extensões naturais da arquitetura nativa da plataforma.
A contrapartida? Sem suporte a Windows. A arquitetura do Ghostty torna a portabilidade para Windows uma tarefa enorme porque precisariam construir uma interface nativa inteiramente nova. Alguns usuários consideram isso um fator decisivo. Eu considero um recurso — significa que as experiências no macOS e Linux não são diluídas por compromissos de mínimo denominador comum.
Uma previsão na qual aposto minha reputação: em menos de dois anos, ambientes de terminal programáveis — onde agentes de IA podem inspecionar, controlar e orquestrar sessões de terminal — serão uma expectativa padrão. O suporte a AppleScript do Ghostty é o primeiro passo sério nessa direção vindo de um emulador de terminal mainstream. Os terminais que não se adaptarem vão parecer tão desatualizados quanto terminais sem painéis divididos parecem hoje.
O que a 1.3 realmente mudou nos meus números diários
Acompanhei minha configuração por duas semanas na 1.2 e duas semanas nas nightlies da 1.3. Não é científico, mas consistente o suficiente para ser útil.
Uso de memória durante sessões de Claude Code de 4 horas:
- Ghostty 1.2: média de 2.8 GB de pico, às vezes chegando a 6+ GB
- Ghostty 1.3: média de 380 MB de pico, nunca excedeu 500 MB
Encerramentos forçados por semana (por memória/responsividade):
- Ghostty 1.2: 3-4 vezes
- Ghostty 1.3: zero
Tempo gasto configurando meu layout de divisões toda manhã:
- Antes (manual): ~2 minutos
- Depois (automação com AppleScript): ~3 segundos
Vezes que usei a busca no histórico por dia:
- Semana um: talvez 5-6 vezes
- Semana dois: 15-20 vezes (uma vez que você tem, usa constantemente)
Viagens de ida e volta de formatação da área de transferência economizadas por semana:
- Antes: reformatando 10-15 colagens de saída do terminal manualmente
- Depois: zero reformatação necessária
As vitórias rápidas são a correção de memória e a automação de configuração com AppleScript. Essas dão resultado imediatamente. Os ganhos de longo prazo vêm da busca no histórico se tornando parte da sua memória muscular e a área de transferência enriquecida eliminando um incômodo constante de baixo grau.
A métrica real que não consigo quantificar é a confiança. Não me preocupo mais com meu terminal derretendo durante uma sessão longa. Não verifico nervosamente o Monitor de Atividade. Simplesmente trabalho. Essa redução de sobrecarga mental não aparece em nenhum benchmark, mas se você tem lidado com os mesmos problemas, sabe exatamente do que estou falando.
Seu terminal também merece uma atualização
Aquela sessão à 1h da manhã onde meu terminal comeu 37 gigas de RAM? Rodei o mesmo fluxo de trabalho ontem à noite no Ghostty 1.3. Mesmo projeto, mesmo agente Claude Code, mesma sessão maratona de quatro horas. No final, verifiquei o Monitor de Atividade por hábito.
412 megabytes. Os ventiladores nunca ligaram.
Aqui está o que quero que você faça antes do fim da semana: baixe o Ghostty 1.3, configure o buffer de histórico e o layout de divisões da seção de implementação acima, e rode seu fluxo de trabalho normal por um dia inteiro. Não tente avaliar. Apenas trabalhe. No final do dia, você vai notar algo estranho — terá passado zero minutos pensando no seu terminal. E esse é exatamente o ponto. A melhor ferramenta é a que desaparece.
O Ghostty 1.3 é gratuito, open-source, licenciado sob MIT e apoiado por uma organização sem fins lucrativos através do Hack Club. Mitchell Hashimoto e os mais de 125 colaboradores construindo isso não estão perseguindo receita ou métricas de engajamento. Estão construindo o terminal que querem usar todos os dias. Depois de duas semanas na 1.3, posso dizer — estão perigosamente perto da perfeição.
Qual é aquele incômodo do terminal que você tem tolerado por anos? Aquele que simplesmente aceitou como "é assim que terminais funcionam"? Porque as chances são de que o Ghostty já corrigiu.
🤝 Vamos trabalhar juntos
Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.
- 🔗 Fiverr (builds personalizados e integrações): fiverr.com/s/EgxYmWD
- 🌐 Portfólio: mejba.me
- 🏢 Ramlit Limited (soluções empresariais): ramlit.com
- 🎨 ColorPark (design e branding): colorpark.io
- 🛡 xCyberSecurity (serviços de segurança): xcybersecurity.io
