Junior Martins

Aí eu discordo um pouco. Com DeepSeek eu pagava em média uns 5 dólares por ano só para gerar commits. É pouco, concordo. Mas agora meu custo marginal é zero, porque o hardware eu já tenho e o PC já fica ligado para outras tarefas. Do ponto de vista de C/B geral, para muita gente talvez API ainda faça mais sentido mesmo, não precisa manter máquina, não precisa VRAM, não tem setup, e você ainda aproveita o subsídio desses modelos grandes enquanto eles existirem. Mas no meu caso específico, para essa tarefa, o local fecha melhor. Não estou tentando competir com GPT ou Claude em inteligência geral. Eles são muito mais capazes. O ponto é que um modelo 7B especializado em uma única coisa, diff -> commit no meu padrão, pode ganhar em custo, latência e previsibilidade para esse fluxo. Então, para uso amplo, eu concordo que API costuma ser imbatível, mas para esse caso estreito e repetitivo, rodar local ficou melhor para mim.

Sim, tende a ser mais rápido, principalmente por eliminar latência de rede, fila/concorrência de infra e custo de tokens. Mas o ganho real depende da máquina, do cold start do modelo, do tamanho do diff e da VRAM disponível. Mesmo rodando em outra máquina, o resultado ainda ficou melhor para esse caso porque o modelo é bem especializado, já que ele só precisa transformar diff em mensagem de commit no meu padrão. Não é um modelo geral tentando resolver tudo. Sobre o effort, eu comparei contra usos mais básicos/default de GPT 5.3 e Claude Sonnet 4.5, não em modo de raciocínio pesado/high effort. Aqui a comparação principal não é "inteligência geral", é custo, latência e aderência a uma tarefa muito específica. No meu fluxo isso fez bastante diferença porque eu costumo fazer commits separados por arquivo, e o Seshat ainda roda um Code Review antes de commitar. Então, o que antes consumia minutos e tokens em providers externos agora roda local, com mais previsibilidade e custo praticamente zero por execução. Depois quero trazer os números de latência certinhos aqui.

Opa, Marcelo, claro! O que eu fiz foi um um fine-tuning local para uma tarefa bem específica, que é: receber um git diff e devolver uma mensagem no padrão Conventional Commits, em PT-BR. O dataset saiu do meu próprio histórico de commits. Como eu já usava o Seshat (https://github.com/juniormartinxo/seshat) para fazer meus commits usando IA (Deepseek, Codex, Claude etc), eu extraí os commits dos repositórios que eu trabalho, normalizei para formato chat, removendo WIP, revert, commits genéricos, bots, diffs só de whitespace, mensagens fora de Conventional Commits e duplicatas. No fim, ficaram 4.869 amostras de treino + 256 de avaliação, a partir de 13.525 commits brutos. O modelo base foi o Qwen 2.5 Coder 7B Instruct em 4-bit. Fiz QLoRA com Unsloth/TRL, LoRA r=16, alpha=16, focando só em ensinar o padrão de saída e o meu estilo de commit, não em transformar o modelo num chat geral. Tanto que, se você perguntar algo diferente de "gerar commit", é capaz de ele responder algo absurdo. O que ele sabe fazer, e faz bem, é texto para commit. O treino rodou localmente numa RTX 5070 Ti 16 GB e fechou com loss final de 0.2768. Depois exportei para GGUF, quantizei em Q4_K_M e publiquei para uso via Ollama. A ideia é rodar 100% local: ``` git diff --cached | ollama run juniormartinxo/seshat-commit ``` Ou direto pelo Seshat com `seshat commit --yes`.

Muito bom, ficou fino! Tenho o mesmo problema aqui, pois gerencio mais de uma carteira também, top demais!!!

Deixa eu contar a história. O Seshat é uma CLI em Rust que faço há um tempo com o propósito único: gerar commits com IA seguindo Conventional Commits, em PT-BR. Começou como dor pessoal e acbou virando bancada de estudo. Depois de acumular bastante histórico, decidi treinar um modelo próprio usando QLoRA sobre Qwen 2.5 Coder 7B, dataset feito dos meus próprios commits, desta forma nasceu o Seshat Commit. O primeiro fine-tuning a gente nunca esquece. 🎉 Depois montei um benchmark comparando três agentes (Codex, Claude, Ollama) em fixtures Rust/Python/TS. Resultado: • Seshat Commit (7B local): 371ms média | 100% Conventional Commits válidos | venceu todas as 3 fixtures • Claude Sonnet 4.6: 5.099ms média | 100% válidos | 0 fixtures vencidas • GPT-5.3-Codex: 12.984ms média | 100% válidos | 0 fixtures vencidas Mesma qualidade. ~14x mais rápido que Claude. ~35x mais rápido que Codex. Zero custo de API. Roda no notebook. A lição que fica: para tarefas estreitas e bem definidas, modelo pequeno especializado não só compete, ele vence. O hype é todo nos modelos gigantes, mas tem espaço e demanda para modelos pequenos focados. 🔗 Modelo: https://ollama.com/juniormartinxo/seshat-commit 🔗 Seshat + Bench: https://seshat.juniormartins.dev/ 🔗 Seshat no Github: https://github.com/juniormartinxo/seshat

Bacana! Eu não conhecia o Jail, inclusive vou dar uma olhada, pois acredito que me vai me ajudar na implementação de uma "sandbox mais parruda" para um outro projeto meu (https://github.com/juniormartinxo/council). Vi aqui que o Jail utiliza o bubblewrap que já é usado pelo Claude e o Codex, também! Obrigado pela contribuição.

CLIs de IA têm um problema chato: identidade global. Atire a primeira pedra quem nunca abriu o terminal para mexer em um projeto pessoal e perceber que a CLI de IA estava logada na conta da empresa. Ou pior, estar no projeto da empresa e rodar tudo com a conta pessoal. Você entra num projeto pessoal e está usando a conta da empresa, vai para o projeto da empresa e está com a conta pessoal, troca login, desloga, reloga, muda variável, ajusta diretório... um saco. O problema das CLIs de IA é que elas, normalmente, assumem uma identidade global. Uma conta, uma configuração, uma pasta de credenciais, uma variável de ambiente para tudo, mas na prática, isso vira bagunça muito rápido para quem alterna entre clientes, empresa e projetos paralelos. Eu resolvi isso criando o Cloak, uma ferramenta em Rust que permite isolar identidades por diretório. Com ele, consigo ter quantas instâncias eu quiser abertas ao mesmo tempo, o limite é o número de contas que eu possuo. Com ele, cada projeto pode ter seu próprio perfil. Então eu consigo, ao mesmo tempo, usar uma conta no projeto da empresa, outra conta em um side project e até abrir várias instâncias da mesma CLI sem conflito. Na prática, o fluxo é simples: associo um perfil ao diretório com `cloak use work` ou `cloak use personal`; o Cloak resolve o perfil correto subindo a árvore de diretórios; injeta o ambiente isolado da CLI; remove variáveis globais que poderiam vazar contexto; e entrega a execução para a ferramenta real. Para o terminal, parece que a CLI está rodando normalmente. Mas por baixo, ela está usando a identidade certa para aquele projeto. O resultado é bem direto: menos troca de login; menos risco de usar a conta errada; menos vazamento de contexto entre trabalho e vida pessoal. Além disso, o Cloak também permite: inspecionar qual conta está logada em cada perfil; isolar configuração de editores como Cursor e VS Code; centralizar snapshots de limites de uso por perfil. A imagem abaixo mostra exatamente isso: quatro instâncias do Claude abertas ao mesmo tempo, cada uma em uma conta diferente, sem conflito. maioria das CLIs modernas de IA não foi feita para quem "multitaska" entre diferentes clientes ou contextos. Elas assumem que você é um usuário único com uma chave única. Se você exporta uma ANTHROPIC_API_KEY global, ela vaza para todos os seus projetos. A Solução: Isolamento de Processo via exec(2) O cloak não é um wrapper pesado ou um daemon. Ele funciona como um roteador de ambiente: Associação por diretório: Você define qual perfil um repositório usa com um simples cloak use work ou cloak use personal. Resolução de Escopo: Ao subir a árvore de diretórios, ele encontra o arquivo .cloak e resolve o caminho de configuração isolado (ex: ~/.config/cloak/profiles/work/claude). Ponte de Execução: Ele define as variáveis de ambiente necessárias (como CLAUDE_CONFIG_DIR) e limpa as globais para evitar vazamentos. Substituição de Processo: Ele usa a syscall exec para substituir o processo atual pelo da CLI real. Para o seu terminal, é como se a CLI original estivesse rodando nativamente, mas com o "manto" (cloak) da identidade correta. O Diferencial: Múltiplos Perfis Simultâneos A grande vantagem é que o isolamento acontece no nível do processo filho. Isso significa que eu posso: No diretório /projeto-a, rodar o Claude com a conta da empresa. No diretório /side-project, rodar o Claude com a conta pessoal. Tudo ao mesmo tempo. Funcionalidades Adicionais Account Inspection: Ele lê os arquivos de credenciais locais (JWTs, JSONs) e te diz exatamente quem está logado em cada perfil antes de você disparar um comando caro. Editor Integration: Consegui isolar até o user-data-dir de editores como Cursor e VS Code, garantindo que as extensões também respeitem o perfil do projeto. Usage Limits: Ele captura os snapshots de limites de uso e centraliza tudo em um comando cloak profile limits. O projeto está em Rust pela performance e segurança de memória, garantindo que esse roteamento de ambiente tenha overhead zero. O que acham dessa abordagem de isolamento por diretório comparado ao uso de containers ou VMs para desenvolvimento? Repositório: https://github.com/juniormartinxo/cloak