Por que eu construí OpenClaude.
Claude Code é par genial — mas mora no terminal. Eu queria a mesma cabeça com janela nativa, fontes boas, scroll humano. Construí pra mim. Hoje compartilho porque dá.
A frustração que virou projeto
Eu já escrevi sobre Claude Code como par de programação. E sobre OpenRouter como gateway honesto. Esse aqui é o terceiro post da trilogia, e é o mais difícil de escrever — porque é sobre uma coisa que eu construí, e eu prefiro escrever sobre coisas que outras pessoas fizeram.
A história começa com uma frustração específica.
Claude Code é incrível dentro do terminal. Eu opero ele 4 a 8 horas por dia. Mas tem um modo de trabalho onde o terminal é o lugar errado: quando eu quero pensar com IA, não programar. Conversas exploratórias longas. Desenho de arquitetura. Escrita de prosa. Análise de documentos. Brainstorm sobre identidade pública do xNeog.
Pra essas coisas, terminal é uma cela. Fonte monoespaçada cansa o olho em prosa. Scroll de terminal é desenhado pra logs, não pra pensamento. Markdown render é parcial. Não tem lugar pra abrir um documento de referência ao lado. E principalmente: não tem o sentimento de janela nativa — aquele tipo de espaço macOS onde o seu pensamento desacelera porque o ambiente não tá te empurrando pra próxima coisa.
Eu queria a mesma cabeça do Claude — a mesma capacidade de raciocínio, o mesmo modo de operar — mas em superfície nativa macOS. Não como editor de código. Como ferramenta de pensamento.
Olhei o que existia. Tem o app oficial da Anthropic, que é bom mas é Electron, é genérico, e não tem as decisões de design que eu queria. Tem clones em Electron de várias formas. Tem extensões de Raycast e Alfred. Nenhum deles era a coisa que eu tinha na cabeça.
Então eu construí.
O que OpenClaude é
OpenClaude é um app SwiftUI nativo macOS (target 14+) que envelopa a CLI openclaude como subprocess via Process + Pipe. Streaming acontece via NDJSON do stdout do subprocess, parser próprio que lê linha a linha. Autenticação é delegada à CLI — o app não implementa OAuth flow, ele assume que você já autenticou a openclaude no shell via OAuth com Claude Max. Pra outros providers, o app aceita API key direto. Tem um log panel pra você ver exatamente o que tá acontecendo entre a UI e o modelo. Markdown render é minimalista — AttributedString(markdown:) built-in do SwiftUI, fonte do sistema, zero customização tipográfica.
· SwiftUI nativo macOS 14+
· Process + Pipe → openclaude CLI (Node.js)
· NDJSON streaming via stdout
· Auth delegada à CLI (Max OAuth no Keychain)
· Storage JSON local · ~/Library/Application Support
· 6 providers · Claude · OpenAI · Gemini · Ollama · Codex · Atomic Chat
Status: MVP v1.0 · 28 files Swift · ~4.300 linhas · uso diário
O que OpenClaude NÃO é
Essa parte importa mais que a parte do que ele é.
OpenClaude não é "Claude Code com UI". Claude Code é ferramenta de código — opera arquivos, faz commits, roda comandos. OpenClaude não toca em arquivos. Não roda comandos. Não tem agentic behavior. É buffer de pensamento puro: você escreve, ele responde, você lê, você responde de volta. Conversa.
OpenClaude não é replacement do terminal. Eu continuo usando Claude Code no terminal pra todo o trabalho de código. OpenClaude vive em outra superfície, pra outro modo de trabalho. Os dois coexistem na minha tela: terminal pra construir, OpenClaude pra pensar.
OpenClaude não é produto pra escala. Não tem onboarding. Não tem free tier. Não tem analytics. Não tem stripe integration. Não tem time de suporte (eu sou o suporte e o suporte não atende). É ferramenta pessoal que eu compartilho porque dá — software pessoal, não SaaS.
OpenClaude não compete com nada. Não tá no mercado. Não tem lançamento. Não tem roadmap público. É infraestrutura privada que virou semi-pública porque alguém pode achar útil.
Essa última distinção é a mais importante e a mais difícil de explicar — então vou dedicar o resto do post a ela.
Software pessoal vs produto
Tem uma categoria de coisas que a gente perdeu o vocabulário pra descrever: software construído por uma pessoa, pra uso próprio, que eventualmente é compartilhado mas nunca vira produto.
No final dos anos 90 e início dos anos 2000, isso era comum. Programadores construíam ferramenta pra resolver coisa específica do trabalho deles, postavam no website pessoal, e quem quisesse baixava. Não tinha ToS, não tinha analytics, não tinha "quero feedback". Era infraestrutura pessoal compartilhada por cortesia.
A web profissionalizou tudo. Hoje, qualquer software que você compartilha publicamente carrega expectativa de virar produto: tem que ter landing page, demo, social proof, roadmap, atenção a feedback. A pressão é constante. Todo experimento parece um pre-launch.
OpenClaude é uma tentativa consciente de reabrir essa categoria. É software pessoal que eu compartilho como compartilharia um script que escrevi pra mim — "olha, isso aqui resolve um problema específico que eu tinha, talvez resolva o seu também". Sem promessa de manutenção contínua. Sem roadmap. Sem ToS além do mínimo. Sem expectativa de virar negócio.
Por que isso importa? Porque a alternativa é pior. A alternativa é eu não compartilhar nada — porque compartilhar profissionalmente exige energia que eu não tenho como solo founder bootstrapped. Ou eu compartilho como produto (com todo o overhead de produto), ou eu não compartilho. A categoria do meio — "toma, é meu, talvez sirva pra você" — está extinta. E ela é justamente a categoria que solo founder com IA precisa ressuscitar.
Decisões honestas da construção
Algumas das escolhas do MVP, com a razão real por trás:
SwiftUI nativo · e não Electron
Porque eu queria o sentimento. Sentimento de janela macOS importa quando o uso é pensamento, não código. Electron é mais portável e tem mais ecossistema, mas o produto final é sempre genericamente "web em janela". SwiftUI me forçou a fazer escolhas nativas — atalhos de teclado certos, scroll inertia certo, font rendering certo. Vale o trade pra solo developer com 4-8h/dia disponíveis.
CLI subprocess · e não API direta
Porque a CLI openclaude existe, é mantida pela comunidade, e implementa coisas que eu não quero implementar: parsing de tool calls, error recovery, retries, OAuth flow. Auth, especificamente, eu delego inteiro pra CLI — ela já sabe falar com Claude Max via OAuth no Keychain do shell. O app só herda essa autenticação. Reaproveitar é mais honesto que reinventar. Custo: o app tem dependência de uma CLI externa que precisa estar instalada e autenticada.
NDJSON · e não SSE
Porque o subprocess do CLI já fala NDJSON pelo stdout. SSE exigiria HTTP server intermediário. NDJSON é direto: o app lê linha por linha do stdout do processo filho, parse cada uma como JSON, renderiza. Menos infra, menos pontos de falha.
Markdown render built-in · AttributedString
Porque editor rico é distração. OpenClaude não é Notion. É buffer de pensamento. Eu uso o AttributedString(markdown:) que vem com o SwiftUI, fontes do sistema (system pra texto, monospaced pra código), zero libs externas, zero customização tipográfica. Quanto menos UI, menos coisa pra olhar, mais espaço pro raciocínio.
O que eu cortei pra MVP funcionar
Sync entre máquinas (não tem — cada máquina tem seu histórico local). Exportação rica de conversas (existe /export slash command, mas formato é cru). Atalhos customizáveis (defaults só). Múltiplas conversas em janelas separadas (uma janela só, navegação por sidebar). Plugins (não existem). Tudo isso poderia ser feito. Nada disso é o MVP.
O que NÃO foi cortado e está rodando agora
Chat com streaming, sidebar com múltiplas conversas persistidas em JSON local, extended thinking blocks (render do raciocínio do Claude), permission UI pra cada tool call (allow/deny inline), cost tracking por sessão (input/output/cache tokens + USD por turn), image attachment (drag-drop, paste do clipboard via Cmd+V global, file picker), slash commands com autocomplete, session resume via --resume da CLI, working directory picker (Cmd+O) pra escolher onde a CLI opera, web preview panel lateral pra renderizar HTML, support pra system/light/dark themes, log panel filterable (Cmd+L), model selector rápido (Cmd+M), e atalhos: Cmd+N nova conversa, Cmd+Return enviar, Esc parar geração, Cmd+P fechar preview. Pra MVP, é bastante.
Custos reais (porque honestidade)
Eu já escrevi sobre custos no post de OpenRouter, mas vale repetir aqui especificamente pra OpenClaude:
OpenClaude usa Claude Max via OAuth (via CLI, como expliquei acima). Se você já paga U$200/mês fixo pelo Max, OpenClaude entra de carona — não tem custo adicional além da assinatura que você já tem. Pra outros providers (OpenAI, Gemini, Ollama local, OpenRouter, DeepSeek, Groq, xAI), o app aceita API key direto — e o custo passa a ser pay-per-use de quem você escolheu. Eu uso Claude porque é meu workflow, mas a stack completa tá lá.
Se você NÃO tem Claude Max: o caminho mais elegante é OpenRouter como provider (uma key, ~100 modelos). Pelo gateway você consegue Sonnet 4.6 (mesmo modelo, ~5% markup), Haiku 4.5, GPT-5 Codex, ou Ollama 100% local zero-custo. Vide meu post sobre quando OpenRouter faz cálculo — o argumento inteiro vale aqui também. Se você não tem Max nem quer pagar API por nenhum provider, ainda tem Ollama local — o caminho zero-custo está implementado.
O model picker do OpenClaudeApp não é uma lista de marketing — é uma lista classificada por dado experimental. Eu rodei o mesmo prompt agentic em 8 modelos top-tier (Opus, Sonnet, Haiku, GPT-5, GPT-5 Codex, Gemini 2.5 Pro, Grok 4, GLM 5.1) e os labels que você vê no app refletem a verdade medida: Haiku 4.5 marcado como "Best Overall & Best Cost" (4/4 quality + 14% do custo do Opus + 2,6× mais rápido), GPT-5 Codex como "Best Speed" (3,6 segundos · 98 tok/s, 4× mais rápido que Opus), Sonnet 4.6 como "Best Quality" (drop-in pro Opus mantendo 1M context). Os rótulos são datados — o benchmark vai envelhecer e eu vou re-rodar quando importar. Mas a metodologia fica: nenhum preset entra no picker como opinião, todos entram como medida.
No meu caso:
- Claude Max: U$200/mês de tabela
- Custo real com cartão internacional brasileiro: ~U$215/mês (IOF 6,38% + spread cartão ~1%)
- Em real: ~R$1.225/mês todo mês, sem flexibilidade
Isso é a infraestrutura. OpenClaude não muda esse custo. Só muda como eu uso a assinatura que eu já tenho — adicionando uma superfície de pensamento à mesma capacidade de execução que o Claude Code já me dá no terminal.
Pra mim faz sentido. Pra outra pessoa pode não fazer. O cálculo é seu.
Status agora · build in private (semi)
Eu construí OpenClaude pra mim. Uso há semanas. Funciona.
Distribuição pública: a landing já existe em xneog.com/openclaudeapp. Modelo: free + open source. Sem checkout, sem waitlist, sem free tier (porque tudo é free). O download e o repo GitHub abrem em seguida — a página descreve o app, lista as features verificadas em código, mostra a stack honesta, e deixa o link de download como placeholder até eu publicar o .dmg. Quando esse post sair (23/abr), eu já vou ter respondido as decisões que faltavam: sob qual licença (MIT), com qual nível de suporte (nenhum — software pessoal compartilhado), hospedando download onde (GitHub Releases), com qual mensagem (a landing tem ela inteira).
A pergunta que esse post forçou foi:
Eu quero que OpenClaude seja uma coisa que outras pessoas usam, ou eu quero que continue sendo só meu?
A resposta veio na forma de uma página pública sem analytics, sem pixel, sem promessa de suporte — software pessoal compartilhado por cortesia, do jeito que eu defendi acima. Não é produto. Não tem changelog, não tem Discord, não tem "feedback survey". Quem quiser usar, usa. Quem quiser modificar, modifica. Quem quiser quebrar, quebra — e aí é problema do quebrador, não meu. Essa é a única forma honesta de compartilhar algo que eu construí pra mim sem virar refém de expectativa que não cabe na minha vida atual.
Por que isso importa pra solo founder com IA
Tem uma tese quieta nesse post inteiro, e ela é a seguinte:
Quando uma pessoa pode construir software inteiro com IA em poucas semanas,
software pessoal volta a fazer sentido como categoria.
Os anos 2010 mataram software pessoal porque o custo de construir era alto demais pra algo que só uma pessoa ia usar. Era racional terceirizar tudo pra SaaS — alguém com escala constrói melhor e cobra centavos. A economia favorecia produto, não ferramenta artesanal.
Em 2026, esse cálculo mudou. Eu construí OpenClaude em poucas semanas, sozinho, com Claude Code como par. O custo marginal de construir uma ferramenta pessoal específica caiu pra perto de zero (em horas, não em assinatura mensal). Isso significa que escolher "produto SaaS genérico" vs "ferramenta artesanal própria" virou de novo uma escolha real, não uma escolha forçada pela economia.
E ferramenta artesanal própria tem propriedades que produto SaaS nunca vai ter: ela cabe exatamente no seu workflow, ela não te força a casos de uso de outras pessoas, ela não desaparece quando o vendor pivota, ela não vaza seus dados pra terceiros, ela responde só a você. Essas propriedades importam — especialmente pra quem trabalha com pensamento e código todo dia.
OpenClaude é uma instância dessa categoria. Não é o futuro da categoria — é só uma coisa dentro dela. Mas é a categoria inteira que eu quero defender com esse post. Software pessoal compartilhado por cortesia. Sem promessa de virar produto. Sem expectativa de virar negócio. Só uma coisa que alguém construiu pra si e que talvez sirva pra você também.
Fechamento
Esse é o último post da trilogia de stack AI. Os três juntos contam a história inteira: Claude Code é o par de programação que eu uso todo dia, OpenRouter é o gateway que eu uso quando faz cálculo, e OpenClaude é o produto pessoal que eu construí pra preencher um buraco específico que nenhuma outra ferramenta preenchia.
Stack honesta. O que eu uso mesmo.
O que custa mesmo. O que eu construí mesmo.
Se chegou até aqui, obrigado pela paciência. Se você tem Claude Max e quer testar OpenClaude quando ele estiver disponível pra download, me manda WhatsApp ou e-mail (links em xneog.com/#contato). Vou avisar quando der.
E se você não quer testar OpenClaude mas leu o post inteiro porque a tese de software pessoal te interessa — então o post cumpriu seu papel principal. A categoria importa mais que a ferramenta.