Segunda rodada, 4 de setembro de 2026, pelo Paulo. Você respondeu, e a pergunta mudou. Tudo que estava aqui continua abaixo, com duas correções marcadas. Novo nesta rodada: a apuração do que houve ontem, a medição dos 71 subagentes e um segundo teste de bancada. Nada da configuração da Mari foi tocado.
Ontem foi queda da Anthropic, não limite seu, e isso muda o remédio. Dos três desenhos que você pediu, um não existe do jeito imaginado, outro já está construído aqui e o terceiro eu testei hoje. O conserto que resolve os 98 minutos de ontem é uma lista de padrões, não um provedor novo.
A frase que você mandou junta duas coisas que não têm o mesmo remédio. Separei, porque uma delas eu consegui provar ontem e a outra eu consegui medir.
A ideia é rodar lado a lado, pra multiplicarmos a força tarefa em demandas múltiplas quando o Claude tem sobrecarga e fica fora do ar (como ontem).
Tem dois problemas dentro dessa frase, e eles pedem coisas diferentes. Um é ficar sem ninguém. O outro é ter gente demais pra pouca mão.
Você escreveu que a Mari já dispara vários subagentes em paralelo e que são eles que consomem o token. Confere, e o número é maior do que parece: nos últimos 7 dias saíram 71 subagentes, e eles sozinhos queimaram 666 milhões de tokens de entrada contra 2,84 milhões de saída. A mão de obra é quase toda a conta.
A parte que não confere é a solução. Você imaginou a Mari em Claude e a mão de obra em Kimi dentro da mesma sessão. Isso não existe, e eu vou mostrar exatamente onde trava.
Essa era a pergunta que podia derrubar o plano inteiro. Fui em duas fontes independentes, o painel de status da Anthropic e o registro da própria sessão aqui na máquina. As duas batem.
Em 03/09 a Anthropic abriu Elevated errors for multiple models, impacto classificado como maior, atingindo claude.ai, a API e o Claude Code. A lista de modelos afetados que eles publicaram cita o Opus 5, que é o que a Mari roda. Duração de 2h50, das 10:26 às 13:16.
Do lado de cá, o registro da sessão dela tem 8 erros de servidor no mesmo intervalo: três 500 Internal server error e cinco 529 Overloaded. E o mais revelador: os três primeiros caíram 2 minutos antes de a Anthropic publicar o incidente. A Mari bateu na falha antes do painel de status contar.
Erro de limite de conta em 03/09: zero. Nenhuma ocorrência de usage limit, session limit ou 429 em nenhum dos 49 registros do dia.
tenta de novo...Sem resposta.
?Sem resposta.
Mari, cade vc!?Sem resposta. Os 529 Overloaded seguem até 11:50.
Mari, voltou à vida?Sem resposta. Quarta mensagem no vácuo.
Tem uma contingência montada em /opt/mari-bot/contingency.py, com vigia rodando de 2 em 2 minutos. Quando ela dispara, quem responde é o Codex, que é OpenAI, provedor completamente diferente. Ou seja: a redundância de provedor já está instalada e paga.
Ela não entrou ontem por um motivo bobo. A lista de padrões que aciona o gatilho só reconhece texto de limite de uso: you've hit your session limit, usage limit, coisas assim. Não tem uma linha pra 500 nem pra 529. Ontem a tela estava cheia de 529 e o vigia olhou, não reconheceu e seguiu em frente.
Isso explica o alerta errado das 10:30. A frase que culpa contexto cheio ou créditos
é texto fixo dentro de monitor-session-context.sh, escrito na mão. Não é medição, é chute, e ontem o chute apontou pro lado errado. Foi ele que fez todo mundo achar que era teto de conta.
Não. Isso eu preciso corrigir do que ficou escrito aqui de manhã. Conta separada resolve teto de plano, e teto de plano não teve nenhuma participação ontem. Se você tivesse duas contas MAX, as duas teriam tomado 529 igual, porque o problema estava no servidor deles, não na sua cota.
Para dar tamanho: em 30 dias foram 8 falhas de servidor da Anthropic contra 1 episódio de limite de conta (26/08, janela de 5 horas, resolveu sozinho). O painel deles registrou 31 incidentes no período, 9 deles de impacto maior ou crítico. O problema recorrente é instabilidade do provedor. Redundância de provedor é a resposta certa. Só que você já tem uma.
Cada um com o passo a passo real, o que custa e onde quebra. Dois deles eu consigo derrubar com evidência, não com opinião.
Você perguntou se a variável vale por sessão, por agente, e se dá pra ter agente no Claude e agente no Kimi ao mesmo tempo. Fui ler o binário instalado, porque documentação envelhece e código não mente.
2.1.239. Ela lê CLAUDE_CODE_SUBAGENT_MODEL antes de tudo e só olha o frontmatter se a variável estiver vazia. O próprio código carrega os rótulos da ordem, nessa sequência: env, tool, frontmatter, inherit. Sua premissa está correta.2.1.251 a ordem vira ao contrário e o frontmatter passa a ganhar da variável. Hoje a Mari está protegida porque o start.sh sobe com DISABLE_AUTOUPDATER=1, então a versão está presa. Mas um npm i -g distraído inverte esse comportamento sem avisar ninguém. Se um dia isso for montado, precisa de trava de versão explícita.family_step_down ou parent_inherit. O fail silently da documentação da Moonshot é sobre configurar só parte das 9 variáveis, não sobre resolver modelo de subagente. Corrigido.CLAUDE_CODE_SUBAGENT_MODEL troca o nome do modelo, não o endereço do servidor. Quem manda no endereço é ANTHROPIC_BASE_URL, e ela está na mesma lista de variáveis do processo, lida uma vez quando o programa sobe. A lista de campos que um subagente aceita no frontmatter não tem endereço nem provedor. Então subagente em outro provedor, na mesma sessão, não existe. Trocar só o nome é pedir kimi-k3 pra Anthropic, que não conhece esse modelo.A única saída seria subir um proxy aqui no servidor, apontar a Mari pra ele e deixar esse proxy decidir, pelo nome do modelo, se manda pra Anthropic ou pra Moonshot. É construível, não é mágica. Mas repare no que isso cria: um programa nosso, escrito por nós, na frente de toda chamada da Mari. Ele cai, ela para. E ele passa a ser mais um ponto de falha justamente num plano que nasceu pra ter menos pontos de falha.
Suponha que o proxy exista e funcione. A pergunta seguinte é a sua: quanto de dado sensível vai junto? Medi nos 71 subagentes reais dos últimos 7 dias, um por um, sem amostragem.
.env do bot foi lido por 20 deles, o da Mari por 18.A sua intuição era que mandar só o pedaço de cada agente limitaria o vazamento. Está certa no briefing e errada na execução: o briefing é inócuo, mas 85% dos subagentes tocam credencial ou dado de cliente enquanto trabalham, e isso vai inteiro pro modelo, com prompt limpo ou não.
Pior: a distribuição não colabora. O paulo-dev sozinho é 62% dos disparos e 78% de tudo que foi lido, e é onde apareceram 100% dos segredos vivos. É o agente que mais roda, o que mais precisa de raciocínio forte e o que menos pode sair daqui, as três coisas ao mesmo tempo.
Os que dariam pra mandar sem susto são o jonathan-copy e a juliana-ops (ela não abriu .env nenhuma vez em 10 execuções). Rafael, Davi e Flávio não rodaram uma única vez na semana. Esse recorte seguro é 17 dos 71 disparos e 8% do volume lido. Você montaria um proxy, assumiria um ponto de falha novo e um contrato de dados na China para tirar 8% da carga.
Isso já é o cenário bom, supondo que a Moonshot tenha cache tão eficiente quanto o da Anthropic. Sem cache equivalente, a conta é sobre os 666 milhões brutos: US$ 2.041 por semana, US$ 8.746 no mês. Não consegui confirmar o cache deles na fonte, então trate a linha de cima como o melhor caso, não como o provável. Marquei como suposição de propósito.
Esse desenho já foi construído aqui, testado em produção e está rodando. Só que o cérebro reserva é o Codex, não o Kimi, e ele não é uma segunda Mari. Essa diferença é a resposta pro seu medo.
route_if_blackout(). Esse é o único portão da casa.codex exec. É uma chamada só, que nasce e morre ali. Sem sessão, sem tmux, sem histórico próprio.pending.md, num bloco marcado [contingencia ...].build_catchup() escreve um recado e injeta na Mari contando que ela esteve fora e onde ler o que ficou pendente. O bastão volta sem buraco.Você perguntou se fica ligado o tempo todo ou sobe sob demanda, e quanto demora. A resposta é que a pergunta não se aplica nesse formato. Não existe processo dormindo esperando. O bot chama uma linha de comando na hora, com um limite de 240 segundos. Nada fica de pé consumindo recurso, e não tem tempo de partida.
you've hit your session limit e parentes. Não cobrem 500, 529 nem Overloaded. Foi por isso que ontem ele ficou olhando pra tela cheia de erro e não reconheceu nada./contingencia on. Isso foi uma escolha consciente de quem construiu, não um defeito, mas significa que ontem, mesmo se tivesse detectado, ele só teria mandado um aviso.Permission denied no binário dele três vezes seguidas. Nunca foi testado depois disso. Não afirmo que funciona hoje: afirmo que existe e que precisa de um teste antes de alguém contar com ele.A trava do desenho A é que endereço de servidor é do processo. Então a saída é óbvia e não precisa de proxy nenhum: em vez de tentar mudar o provedor dentro da sessão dela, você abre outro processo. Cada processo tem o ambiente dele e um não enxerga o outro.
ANTHROPIC_BASE_URL apontando pra Moonshot e a chave do Kimi. Esse processo nasce com o ambiente dele, não com o dela./opt/mari/memory, sem .env e sem os CSV de lead. A trava é permissão de arquivo, não instrução no texto.max, os 7 agentes continuam em claude-opus-5 e a sessão dela seguiu viva o tempo todo.Kimi no meu lado, não no dela), só que agora com o teste feito e o passo a passo escrito.
| Critério | A · subagente | B · reserva | C · frota |
|---|---|---|---|
| Roda hoje, sem construir nada? | Não, precisa de proxy | Existe, mas cego pra queda | Sim, testado hoje |
| Qual problema ataca | Capacidade | Redundância | Capacidade |
| Base de dados sai daqui? | Sai, em 85% dos casos | Sai a memória e o histórico | Só o que ela mandar |
| Custo novo por mês | US$ 1.530 a 8.746 | Quase nada, é sob demanda | Você decide o quanto usar |
| Ponto de falha novo | Proxy na frente de tudo | Nenhum | Nenhum |
| Duas Maris disputando saída | Não | Só se fizer errado | Não |
Arraste a tabela pro lado se estiver no celular.
Esse era o ponto que mais te preocupava, e com razão: já aconteceu aqui. A resposta curta é que o problema não se resolve com cuidado, se resolve com desenho. E o desenho certo já está montado.
Em 01/08 o reinício da Mari não matou a sessão anterior. A antiga ficou num estado torto e perigoso: parou de receber suas mensagens, porque o bot injeta só na sessão nova, mas continuou escrevendo no outbox. Você recebeu duas mensagens de boot quase iguais, de duas Maris que não sabiam uma da outra.
Guarde esse detalhe, porque ele mata metade das soluções óbvias: a sessão problemática é justamente a que parou de escutar. Qualquer trava que dependa dela conferir alguma coisa antes de escrever falha exatamente no caso em que você precisa dela. Trava que o processo doente precisa respeitar não é trava.
Em vez de deixar dois escritores e tentar coordená-los, o desenho que já está aqui garante que só exista um. Toda mensagem sua passa por um único ponto no bot, o route_if_blackout(), e é ele que decide quem responde. Ele escolhe um, nunca os dois, e o outro nem fica sabendo que chegou mensagem.
E a reserva foi feita de propósito sem sessão própria. Ela não tem tmux, não tem contexto que continua vivo, não tem memória. Nasce quando o bot chama, responde e morre. Um processo que não fica de pé não tem como brigar por nada.
Não tem duas Maris porque não pode haver duas. O portão está antes da bifurcação, e a reserva não tem onde morar.
Você pediu mecanismo, não recomendação de cuidado. Então, se em algum momento existirem mesmo dois processos de pé, essas quatro travas são o piso, e todas elas são de sistema, não de combinado:
flock. Um arquivo de posse que só um processo consegue segurar por vez. Esse padrão já é usado aqui: tem tasks.json.lock e vários cron rodando com flock -n. Quem não segura o arquivo não escreve.pending.md, que é o que a contingência já faz.TMUX_SESSION, um nome só, no singular, e ele é usado em quase toda função que fala com a Mari. Pra existir um segundo painel, isso vira lista e nasce a função que decide o alvo. Isso é reescrever o miolo do bot, não configurar.Eu não recomendo esse caminho. As quatro travas existem só para consertar um problema que o desenho atual simplesmente não tem, e a quarta é uma cirurgia no arquivo mais crítico da casa. Duas sessões vivas é a única forma de recriar o incidente de 01/08 de propósito.
Mudou do que estava escrito aqui de manhã, e mudou por evidência nova: ontem foi queda deles, não teto seu.
Estava escrito aqui que o remédio pro seu medo era isolar a Mari em conta própria. Isso partia de uma suposição que agora está desmentida: a de que você ficava sem ela por estourar limite. Ontem não foi limite, foi servidor deles fora do ar, e conta separada não teria mudado nada. Risquei essa recomendação.
Os seus dois problemas têm dois remédios diferentes, e nenhum dos dois é trocar o motor da Mari.
Pro problema 1, redundância: você já tem um cérebro reserva instalado, de outro provedor, e ele ficou parado ontem porque só sabe reconhecer texto de limite de uso. Ensinar ele a reconhecer 500 e 529 é mexer numa lista de padrões que já existe. Isso é o conserto mais barato do documento inteiro e ataca o problema exato que te deixou 98 minutos falando sozinho.
Pro problema 2, capacidade: o desenho C, que eu testei hoje e funciona. Frota separada, em outro processo, sem enxergar a memória nem as chaves, chamada quando aperta. Sem proxy, sem ponto de falha novo, sem mexer em nada do lado dela.
Uma Mari inteira no Kimi eu continuo não recomendando, e agora com um motivo a mais: ela emprestaria ao Kimi o único papel que o Kimi faz pior, que é julgar e decidir com você.
500, 529 e Overloaded na lista que aciona a contingência. Mesma trava de duas confirmações que já existe, pra não disparar à toa.Permission denied nas últimas três tentativas reais, em junho. Nunca foi validado depois. Não adianta consertar a detecção se o reserva não liga.contexto cheio ou créditosé texto fixo escrito na mão. Ontem ela apontou pro lado errado e foi o que fez todo mundo achar que era limite de conta.
.env e sem base de lead, ligada quando você mandar. Uma tarde de trabalho, e desligar é parar de chamar.Tudo abaixo é o levantamento que você já leu hoje de manhã, palavra por palavra. Continua valendo, com duas ressalvas que ficaram marcadas lá em cima: a delegação não morre calada (seção dos desenhos) e conta isolada não era o remédio (seção da recomendação).
O levantamento de 19/07 continua de pé no essencial, mas envelheceu em dois pontos que fariam a configuração falhar se você copiasse do jeito que está anotado.
api.kimi.com/coding/. A doc de hoje manda https://api.moonshot.ai/anthropic. Bati nos dois daqui do servidor, sem chave: os dois respondem, com o erro certinho de chave inválida. O velho não morreu, só saiu da documentação. Ficar no endereço que a doc não cita mais é apostar contra.ANTHROPIC_API_KEY, é ANTHROPIC_AUTH_TOKEN. E a doc avisa que ele tem precedência sobre o login salvo, que é exatamente como a Mari está autenticada hoje. Se sobrar a variável velha no ambiente, dá conflito.kimi-k3[1m] com 1.048.576 de contexto, kimi-k2.7-code e kimi-k2.6 com 256 mil. O k2.7 exige o modo Thinking ligado, senão devolve erro 400 em toda chamada.Os planos mensais do Kimi Code começam em US$ 19 e vão até US$ 199. Não consegui abrir a tabela oficial de planos hoje, a página é um aplicativo e não entrega o conteúdo pra leitura. O que achei em fonte de terceiro, e por isso trato como não confirmado, é que em julho as quatro faixas pagas apareceram esgotadas por falta de GPU, com reabertura em lotes. Antes de contar com plano fechado, alguém precisa abrir a página logado e confirmar se dá pra comprar.
Em vez de acreditar na doc, montei um endpoint falso numa pasta temporária, apontei uma instância limpa do Claude Code pra ele e li o que sai do outro lado. Sem chave da Moonshot, sem instalar nada, sem encostar em /opt/mari.
A pergunta que importava era uma só. Os seus sete subagentes, Juliana, Paulo, Flávio, Jonathan, Rafael, Pedro e Davi, têm model: claude-opus-5 cravado no cabeçalho do arquivo. O Kimi não tem nenhum modelo com esse nome. O que acontece quando a Mari delega?
cache_control no corpo. O protocolo passa inteiro, em SSE. Ler arquivo, rodar comando, editar, buscar na web, tudo isso é ferramenta e chega lá.kimi-k3[1m], mas o que sai no corpo da requisição é kimi-k3 limpo. O colchete é anotação de janela de contexto pra CLI. Funciona, só não se assuste ao ver diferente no log.[claude-code:unrecognized_model] no terminal. É cosmético, a conversa continua. Mas vai sujar o painel da Mari, e o bot do Telegram lê esse painel pra saber se ela está ocupada. Volto nisso na seção 3.Sua pergunta central. A resposta curta é que não existe integração pra fazer, porque quase tudo já é arquivo em disco e arquivo não pertence a modelo nenhum.
Não tem o que integrar. A memória da Mari é arquivo em disco e uma API HTTP local, então uma Mari apontada pro Kimi lê tudo no primeiro segundo, sem exportar, sem converter e sem plugin. O que não atravessa é uma variável de ambiente, não uma base.
/home/mari/.claude/projects/-opt-mari/memory/. É o formato do Claude Code, mas é Markdown legível. Se o carregamento automático não vier, ela lê na mão como qualquer pasta.POST em HTTP local, o modelo nem sabe que ela existe, só chama. O banco mari_memory tem 12.770 mensagens de histórico e se acessa por psql. Os dois funcionam igual atrás de qualquer modelo.~/.claude/skills/. O carregamento é da CLI, não do modelo, então elas aparecem. O que eu não medi é se o Kimi obedece a uma skill longa como a impeccable ou a humanizer com a mesma fidelidade. Carregar é uma coisa, seguir é outra.security-scan.py e o rastreador de tarefas são scripts Python disparados pela CLI antes das ferramentas. Continuam rodando igual, e essa é uma boa notícia: a varredura de comando perigoso não depende do modelo.~/.claude.json e no projeto: a lista está vazia nos dois. O acesso a Google que a Mari usa hoje sai por script próprio com o token em /opt/credentials/, ou seja, é Python, roda igual.CLAUDE_CODE_SUBAGENT_MODEL, todos os sete morrem calados. Com ela, todos funcionam sem editar arquivo. É a única coisa que separa "funciona" de "parece que funciona".mari e lê arquivos JSON da pasta outbox. Nunca menciona modelo. Só que, pra saber a hora de injetar, ele tira uma foto do painel e procura palavra como thinking e o cursor ❯. O Kimi é descrito como verboso, com raciocínio sempre ligado, e ainda imprime unrecognized_model a cada chamada. Se isso deixar o painel parecendo ocupado o tempo todo, o bot para de entregar as suas mensagens pra ela. Não testei com Kimi de verdade, mas é o ponto que eu checaria primeiro no dia 1.CLAUDE_CODE_AUTO_COMPACT_WINDOW em 1 milhão. Isso muda o ritmo de reinício da Mari e toda a rotina de restart que ela tem hoje foi calibrada em cima de outra janela. Não quebra, mas descalibra.A ressalva de julho continua valendo e ficou mais séria agora que dá pra medir. A Moonshot treina os modelos com o que recebe e não oferece opção de recusar. Contei com grep, não por impressão.
A Mari não vive do boot. Ela trabalha, e tudo que ela abre no dia vira mensagem pra Moonshot. O alcance real do primeiro mês de uso é este:
.env do projeto, com 29 linhas de credencial, que ela lê toda vez que precisa de um token.Fiz a conta. Das 4.531 linhas do pacote de boot, 371 carregam pessoa, dinheiro ou credencial. São 8,2%, e num primeiro olhar parece ótimo: sobrariam quase 92% do texto.
Só que a leitura correta é a inversa. Essas 8,2% são justamente as linhas que decidem alguma coisa. Quem é o lead, quanto custa, qual contrato está em pé, qual senha abre qual sistema. Tire isso e sobra a Mari sabendo trabalhar sem saber sobre o quê.
O núcleo que é 100% limpo de verdade, sem nenhum dado de pessoa nem valor, são o CLAUDE.md e o SOUL.md juntos: 15,2 KB, ou 3,6% do pacote. Essa é a Mari filtrada honesta. Ela tem personalidade, tom, protocolo de trabalho e nome dos subagentes. E não tem negócio nenhum dentro.
Aqui não é estimativa. Abri os registros de sessão da Mari e dos subagentes dos últimos 7 dias, somei token por token e apliquei a tabela publicada do kimi-k3.
7 dias reais, 13 sessões da Mari e 67 execuções de subagente, na tabela de US$ 3,00 de entrada, US$ 0,30 de cache e US$ 15,00 de saída.
O que domina a conta é o cache: mais de 1,1 bilhão de tokens relidos na semana, porque cada turno relê o contexto inteiro dela. Cobrei isso pelo preço de cache-hit deles, que é o mais barato possível. Se o cache do Kimi funcionar pior que o do Claude, a conta só sobe.
Em julho o motivo de olhar pro Kimi foi o medo de estourar a cota do MAX e te deixar sem Mari. Só que a Mari é justamente a carga mais pesada que roda aqui. Botar ela no Kimi é pegar a conta que hoje está coberta por uma assinatura fechada e transformar em conta por token, na peça que mais consome.
O plano fechado deles não salva: a faixa mais cara é US$ 199 por mês, com cota semanal. Esse consumo passa por cima de qualquer uma das faixas nos primeiros dias.
Os dois são executáveis. Descrevi cada um até o fim, com o que ganha e o que perde, pra você decidir com o preço na mão.
/opt/mari/.claude-profiles/kimi.sh. O gancho já existe: o start.sh dela lê o arquivo active e carrega o perfil correspondente. Hoje está em max.ANTHROPIC_API_KEY e CLAUDE_CODE_OAUTH_TOKEN pra não brigar com o login atual.CLAUDE_CODE_SUBAGENT_MODEL. Sem ela, os sete subagentes param em silêncio.active pra kimi e reiniciar. Voltar pro Claude é escrever max de novo. O rollback é uma palavra num arquivo, e isso é o que torna o teste barato./opt/mari-kimi, com cópia do CLAUDE.md e do SOUL.md e mais nada de memory/. São os 15,2 KB limpos.model apontando pro Kimi desde o cabeçalho, em vez de depender de variável.TMUX_SESSION própria. O bot já lê esse nome do ambiente, então dá pra separar sem mexer no código..env da casa, sem /opt/credentials. Se ela não pode ler, não pode vazar.Essa parte a casa já aprendeu na dor, duas vezes. Rodar duas Maris na mesma pasta e no mesmo bot não é conviver, é colidir:
mari. A segunda instância não recebe você, mas continua respondendo. É o pior formato possível: surda e falante.Por isso, no caminho B, bot próprio e sessão própria são o que faz o paralelo existir. Sem os dois, não tem paralelo, tem briga.
Documentação oficial da Moonshot lida hoje. Números do servidor contados com grep e com leitura dos registros de sessão. O teste de bancada rodou em pasta temporária, com endpoint falso, sem chave e sem tocar em /opt/mari.
Uma coisa eu não consegui confirmar na fonte: a tabela de planos fechados. A página de preço deles é um aplicativo e não entrega o conteúdo pra leitura automática. A faixa de US$ 19 a US$ 199 e a notícia de faixas esgotadas em julho vieram de fonte de terceiro e por isso estão marcadas como não confirmadas no texto. Isso não muda a recomendação, porque o consumo medido passa por cima de qualquer uma das faixas.