IDEs

Indo direto ao ponto: todas essas IDEs com vendor lock de IA são forks do VSCode (na verdade do Code OSS) com a extensão de IA do vendor. Poderiam simplesmente lançar a extensão de suas IAs no Open VSX Registry (não podem abraçar o Marketplace da Microsoft).

O fato de ter a extensão é justamente adicionar system prompts para economizar o uso, digamos: seu uso com a IA num código específico irá consumir 10k de tokens (que no fundo é o uso de recursos da infra), eu consigo interceptar isso, reduzir este uso para 7k, MAS te cobro os 10k. O objetivo não é reduzir seu uso, mas sim, otimizar infra e direcionar o ecossistema da stack para aumentar as margens (entre a percepção dos gastos de token pelo cliente e o real consumo) e eles possam gerar lucrar num futuro, tento ao máximo criar uma dependência pela stack e bloquear outras chaves, keys e extensões.

Na comunidade Linux temos o termo “Refisefuqui” (algo como drive-by fork, vanity fork, Weekend Backyard/Respin Fork, low-effort Code-OSS forks) e é isso que os vendors de AI estão fazendo para tentar gerar dependência e posteriormente, fechar os caminhos da liberdade, justamente em um momento em que modelos open sources (principalmente chineses) estão alcançando mais rápido e com menos custo os modelos proprietários.

O melhor modelo aberto chinês ainda fica uns 9 pontos atrás dos proprietários ocidentais de topo em benchmark composto, mas os modelos chineses custam de 5 a 30 vezes menos e já empatam ou ganham em tarefas específicas. O GLM-5.1 saiu com licença MIT (754B de parâmetros, MoE) e benchmarks reivindicando superar GPT-5.4 e Claude Opus 4.6 em SWE-Bench Pro, é o modelo de fronteira com licença mais permissiva já lançado. DeepSeek V4 Flash e Qwen 3.6 rodam de 5 a 30 vezes mais barato por milhão de tokens que os flagships da Anthropic ou OpenAI. O Kimi K2.6 foi o primeiro modelo open-weight a bater o GPT-5.4 em SWE-Bench Pro.

Para que diversos CLIs de LLMs? Se posso utilizar o OpenCode (teve um racha: o OpenCode original foi renomeado pela Charm para Crush; o OpenCode atual é o rewrite em TS da SST que ficou com o nome) e conectar com a API Key de cada um deles. Para que utilizar os forks de AWS, Google, etc… se basta utilizar o padrão e instalar a extensão? O tiro no pé é dar sucesso para estes apps e eles virarem obrigatórios para o uso. Um dos passos é deixar obscuro o formato de ‘gasto’ dos créditos, antes em token, agora… bem… um malabarismo para criar margem de lucro entre o uso que você acha VS o real consumo da infra. E não temos apenas o OpenCode, há o Cline, Kilo, Aider, etc… Não há apenas o Code OSS (uso o Zed), mas está ficando difícil caso queira fugir o vscode like.

A saída não é outro fork, é desacoplar o editor do agente

O erro de premissa do lock-in é tratar editor e agente como a mesma coisa. O Zed resolveu isso com o Agent Client Protocol (ACP), um padrão aberto que desacopla a comunicação IDE-agente, como exatamente o LSP fez para language servers. Se o LSP matou a necessidade de cada editor reimplementar suporte a cada linguagem, o ACP mata a desculpa de forkar o editor inteiro só pra embarcar um agente.

E o Zed não é refisefuqui de ninguém: não é fork do VS Code nem app Electron, foi escrito do zero em Rust pela ex-equipe do Atom. A 1.0 saiu em 29 de abril de 2026, com cold start na casa de 0,6s e ~222MB de RAM. O que importa para o argumento: a lista de agentes externos via ACP já inclui Claude Agent, Codex CLI, OpenCode, Gemini CLI e até o próprio Cursor, com Opus 4.7 disponível em modo BYOK. Você traz a chave, o agente que quiser, e o editor é só o front. Inverte a lógica do vendor: em vez de o editor prender o agente, o agente é plugável e descartável.

Investir em prender o usuário numa IDE forkada enquanto o diferencial dos modelos converge e a inferência fica self-hostável é construir pedágio numa estrada que está virando de graça. O lock-in só sobrevive se você aceitar a jaula. Code-OSS limpo, ou Zed, mais ACP, mais BYOK apontando para o modelo que você quiser (inclusive um GLM-5.1 rodando local) é a estrada paralela. Sem pedágio, sem proxy lendo teu código, sem malabarismo de crédito.

Sobre System Prompts:

As IDEs com IA abstraem a necessidade de prompts pois injetam os seus próprios, focando em otimizar o uso de tokens e economizar na LLM, obtendo assim a margem deles. Nos repositórios abaixo há os prompts usados nas IDEs e outros apps que embarcam IA:

https://github.com/jujumilk3/leaked-system-prompts/tree/main https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools/tree/main

O repositório leaked-system-prompts reúne system prompts internos de diversos modelos de IA, como ChatGPT, Claude, Gemini, entre outros. Já o repositório system-prompts-and-models-of-ai-tools vai além da simples coleta de prompts, detalha as configurações dos modelos, parâmetros utilizados e exemplos.

Sobre benchmarks de LLMs:

https://arcprize.org/leaderboard - Mais acadêmico, compara o score alcançado versus o custo.

https://www.swebench.com/ - Prático e técnico: colocam os modelos para resolver problemas (issues/bugs) reais no github

https://codeclash.ai/ - semelhante ao swebench, mas neste caso, as LLMs fazem ‘Hackathons’: colocadas para criar (do zero) jogos orientados a programação, seguindo todos os passos do desenvolvimento de software.

Tanto para resolver issues e bugs, quanto para desenvolver aplicações e jogos, no top do ranking está o Claude da Anthropic (exceto no ARC), mas atualmente com margens apertadas e há uma constante alteração com novos releases.

Sobre economizar tokens:

Estou utilizando o RTK: promete e realmente economiza uma boa quantidade de tokens. www.rtk-ai.app | https://github.com/rtk-ai/rtk

O RTK é literalmente a versão honesta do que os vendors fazem. Ele intercepta e comprime a saída dos comandos antes de chegar ao contexto da LLM, cortando 60-90% dos tokens. A diferença é a de sempre: lá no proxy da IDE forkada eles reduzem para 7k e te cobram 10k; o RTK reduz e você fica com a economia, porque roda na tua key. Em resumo: interceptar para economizar é ótimo quando é você quem embolsa a diferença e é golpe quando é o vendor (querendo recuperar o dinheiro gasto e juntamente te travar dentro da solução deles).

Havia testado e não gostei do Caveman https://getcaveman.dev/ (mas por gosto mesmo, sem algo específico e técnico contra ele).

Minha Stack AI

Finalizando, minha stack atual é: Anthropic Claude Pro + Abacus.AI* + Zed + Code-OSS + OpenCode + RTK

No Abacus.AI via OpenCode usando o Qwen Coder. E o app do Abacus em modo RouteLLM, incluindo também o uso dele no smartphone (utilizo Android que empurra o Gemini e associa ao meu e-mail default - algo que me causa desconforto). Além disto, acabo por utilizar em alguns momentos o Lumo (Proton) e outros anonimizados (Leo AI no Brave Browser; Duck do DuckDuckGo).