AesCode 32B vs North Mini Code: O arquivo de pesos não é o compromisso

Ambos estes modelos são Apache 2.0, ambos podem ser descarregados e ambos foram criados para uma tarefa restrita — e é aí que a semelhança deixa de ser útil. AesCode 32B é o checkpoint de investigação da Microsoft para gerar HTML e CSS editáveis: slides, cartazes, painéis e relatórios. O seu repositório Hugging Face foi criado em 29 de setembro de 2026 e o commit intitulado "Release AesCode-32B" chegou a 7 de outubro de 2026; a Microsoft não publicou qualquer anúncio, e a ficha do modelo não tem data nenhuma. Nano Mini Code é o modelo de codificação agêntica de pesos abertos da Cohere, uma mistura de especialistas de 30B com 3B parâmetros ativos, lançado em junho de 2026, destinado a engenharia de software e trabalho de terminal. A forma óbvia de os comparar é através de benchmarks, e não funciona, porque os dois nunca foram medidos no mesmo benchmark e só um deles foi medido por alguém fora do seu próprio laboratório. A comparação que funciona — a que decide se é realmente possível executá-los — é o ficheiro de pesos.

Dois checkpoints, duas contas muito diferentes

Este é o eixo que a maioria das comparações ignora e, para dois modelos auto-hospedados, é o eixo que mais importa.

• Parâmetros — AesCode 32B: 33B, denso. North Mini Code: 30B no total, 3B ativos, mistura de especialistas.

• Memória para executá-lo — AesCode 32B: o card recomenda planejar cerca de 65 GB de memória do acelerador só para os parâmetros bf16. North Mini Code: quantizado, cerca de 20–24 GB é suficiente, e as implantações de referência incluem um Mac Studio.

• Formato de serving — AesCode 32B: um modelo de visão-linguagem, portanto o caminho de serving transporta imagens, assim como texto, e seu próprio exemplo usa paralelismo tensorial de quatro vias. North Mini Code: texto de entrada, texto de saída; os benchmarks usaram uma única ferramenta de terminal.

• Licença — ambos Apache 2.0, pesos incluídos. Esta linha é um empate e não é o diferenciador que as pessoas presumem que seja.

• Contexto — AesCode 32B: 24.576 tokens na configuração relatada, com prompts e respostas de treinamento limitados a 8.192. North Mini Code: 256K de entrada, 64K de saída.

• O que ele emite — AesCode 32B: um documento HTML completo, tabelas como tabelas HTML e gráficos como especificações ECharts. North Mini Code: qualquer texto ou chamada de ferramenta que o harness solicitou.

• Avaliação independente — AesCode 32B: nenhuma publicada; todos os números são da Microsoft. North Mini Code: avaliado no Artificial Analysis, que também sinalizou sua verbosidade.

Leia a segunda linha duas vezes. Um modelo denso de visão e linguagem de 32B que exige 65 GB e paralelismo quádruplo é uma decisão de aquisição diferente de um MoE com 3B ativos que cabe, quantizado, em uma estação de trabalho. Se o seu motivo para considerar pesos abertos era "queremos isso no nosso próprio hardware", essa linha é a maior parte da resposta antes mesmo de você executar um único prompt.

A licença não é o motivo para escolher qualquer um dos dois.

Quase toda comparação de modelos de pesos abertos começa pelo licenciamento, e aqui isso é um beco sem saída: ambos são Apache 2.0, ambos vêm com os pesos completos, e nenhum dos dois traz uma restrição de uso que impediria uma implantação comercial. Não há cláusula de compartilhamento de dados para ponderar contra um desconto, nem nível de contribuidor, nem ressalva de campo de uso. Qualquer que seja o critério que você esteja usando para escolher entre esses dois, não é permissão.

O que resta depois de tirar o licenciamento da mesa é o que o modelo foi treinado para fazer — e esses dois foram treinados em direções opostas.

Um foi treinado em um terminal, o outro em uma tela.

O cartão de modelo do North Mini Code declara abertamente seu objetivo: geração de código, engenharia de software agêntica e terminal. A Cohere o treinou com vários harnesses de agentes — SWE-Agent, mini-SWE-Agent, OpenCode, Terminus 2 — especificamente para que funcione dentro de qualquer um que você já execute, e o avaliou no SWE-Bench Verified, SWE-Bench Pro, Terminal-Bench v2 e Terminal-Bench Hard. Sua fraqueza publicada é real e foi descoberta por um avaliador externo, em vez de ter sido divulgada espontaneamente pelo fornecedor: ele emite aproximadamente três vezes mais tokens de saída do que a mediana de sua classe de tamanho. Modelos prolixos escrevem longas trajetórias de agente, e trajetórias longas são o que você paga depois que o preço promocional acaba.

O AesCode 32B foi treinado em algo completamente diferente, e o card deixa excepcionalmente claro que o alvo é o artefato. Todo o propósito do design é que um modelo de código não consegue enxergar como layout, hierarquia e cor se combinam em uma tela, então o AesCode usa uma imagem gerada a partir do mesmo prompt como referência estética, mantendo o prompt como fonte da verdade para o conteúdo. A supervisão é um "grafo de design" de nós e arestas, sete canais de recompensa — execução, texto, limite, tabela/gráfico, layout, espaço em branco, design — seis deles verificadores determinísticos e um juiz de visão e linguagem trabalhando a partir de uma rubrica por amostra. Os candidatos são renderizados em um navegador Playwright em sandbox com requisições externas bloqueadas e pontuados a partir do DOM, dos estilos computados, das caixas delimitadoras e de uma captura de tela.

Esse mecanismo existe para tornar verdadeira uma coisa: a saída é uma página renderizada que um humano vai abrir e editar, não um patch aplicado a um repositório. O AesCode 32B nunca foi treinado para usar um shell, e nada no design da recompensa o recompensaria por tentar.

A assimetria de evidências, dita honestamente

O North Mini Code foi executado por terceiros. A Artificial Analysis atribui-lhe 33,4 no seu Coding Index e 27,6 no seu Intelligence Index, e publica a conclusão sobre a verbosidade. O número de destaque da própria Cohere — 61,0% pass@1 no SWE-Bench Verified — é reportado pelo fornecedor, mas pode ser verificado contra um modelo que qualquer pessoa pode descarregar, e a ficha é franca quanto às suas escolhas de harness, chegando ao ponto de assinalar que, para o Terminal-Bench Hard, seguiu a própria metodologia da Artificial Analysis para manter a comparação justa.

AesCode 32B não tem equivalente. Sua avaliação de infográfico com 300 amostras, três gerações por prompt sem seleção, produz 85,89 Overall contra 81,28 para o GPT-5.5 e 80,39 para o Claude Opus 4.8 — tudo medido dentro do harness da Microsoft, nas amostras da Microsoft, com os canais de pontuação contra os quais a Microsoft treinou o modelo. Há uma chance real de que os números sejam justos; o design é mais transparente do que a maioria das tabelas de fornecedores, a pilha de verificação e o construtor de rubricas são de código aberto, e o cartão publica o fato de que nenhum modelo na comparação ultrapassa 60 na sua dimensão de estilo. Mas nenhum laboratório externo reproduziu qualquer parte disso, e não há listagem em arena, nem colocação em leaderboard, nem teste de throughput independente. Se um benchmark de fornecedor que por acaso favorece o próprio benchmark do fornecedor — uma tarefa de infográfico — está pesando muito na sua decisão, você está sendo solicitado a aceitar a única leitura disponível.

Observe o que isso significa especificamente para a comparação: não há um número compartilhado. Nenhum. Um modelo é avaliado com base em se tarefas de engenharia de software são aprovadas; o outro, com base em se o texto é legível e se o layout não transborda a tela. Qualquer página que coloque 33,4 ao lado de 85,89 está comparando um Coding Index com uma pontuação Overall de infográfico, e nenhum dos modelos sabe em que o outro foi testado.

Nenhum dos dois é um modelo de propósito geral, e esse é o custo real.

Aqui está a armadilha nas duas metades desta comparação. Adotar qualquer um dos modelos significa manter um caminho de serving auto-hospedado para um especialista: 65 GB de VRAM e uma stack multimodal para aquele que renderiza páginas; um slot para um MoE de 3B ativos para aquele que lida com tarefas de terminal. Ambos são bons no que fazem, e nenhum consegue fazer o trabalho do outro, o que significa que uma equipe que quer as duas capacidades agora está rodando duas implantações de inferência — e, para tudo o que fica no meio, o modelo que não é nem renderizador de páginas nem agente de terminal, ela está rodando uma terceira.

É o caso em que uma camada de roteamento conquista seu lugar em vez de ser acoplada à força. Uma chave para mais de 200 modelos ao preço de tabela do provedor, sem acréscimo, significa que o trabalho especializado permanece no seu próprio hardware, onde a economia e o tratamento dos dados fazem sentido, e o trabalho de rotina vai para o modelo hospedado que for melhor para ele naquela semana. A família de backbone Qwen3-VL é uma boa ilustração de quão tênue fica a linha: a Microsoft criou o AesCode 32B sobre o Qwen3-VL-32B-Instruct, e os membros de visão e linguagem dessa família podem ser invocados no catálogo do OrcaRouter — Qwen3-VL 235B A22B Instruct a $0.40 por milhão de tokens de entrada e $1.60 de saída, ou o menor Qwen3-VL 8B Instruct a $0.18 e $0.70. Nenhum desses é o AesCode 32B: o fine-tune é da Microsoft e nenhum provedor o disponibiliza. Mas se o que você queria do AesCode 32B era um modelo que lê uma captura de tela e escreve código, e você não precisava especificamente do fine-tune de design estético, a opção invocável existe e custa uma fração da GPU. O failover automático sob o mesmo endpoint é a diferença entre experimentar isso e apostar um caminho de produção nisso.

Como decidir de verdade

Tire a licença da mesa primeiro, porque é um empate e não vai decidir nada.

Então pergunte o que você quer que seja o resultado. Se a resposta for uma página renderizada e editável — um deck, um relatório, um painel —, o North Mini Code não pode ajudar você, e o AesCode 32B é o único dos dois voltado para o problema. Entre com os olhos bem abertos em relação aos 65 GB, ao contexto de 24K, à ausência de avaliação independente e ao fato de este ser um modelo não anunciado com uma contagem de downloads de dois dígitos. É um lançamento de pesquisa, e lançamentos de pesquisa recompensam equipes que podem se dar ao luxo de ser curiosas.

Se a resposta for uma alteração em um repositório — uma migração, uma correção, um trabalho de terminal em várias etapas —, o North Mini Code é quem tem o treinamento de harness, a janela de 256K, o perfil de implantação com 3B ativos e uma medição externa tanto da sua qualidade quanto da sua verbosidade. Considere no orçamento a contagem de tokens, não a tarifa anunciada.

E se a sua lista de coisas para fazer neste trimestre incluir tanto um artefato de design quanto uma migração de repositório, não encare isso como uma decisão de dois modelos quando na verdade é uma decisão de seis modelos. Execute o especialista onde vale a pena, encaminhe o restante.

O problema do modelo não anunciado

Uma última coisa separa esses dois, e não é técnica. O North Mini Code tem um fornecedor por trás que publicou um model card, um post de blog, um Hugging Face Space para testá-lo e uma trilha documental de metodologia de benchmark que dá para contestar. O AesCode 32B tem um repositório, um README e uma linha de citação que diz “Em revisão, 2027”. A Microsoft não disse que ele existe.

Isso muda quando você puder adotá-lo. Com o North Mini Code, a questão em aberto é se sua verbosidade o torna antieconômico em escala — uma questão que você pode responder executando-o. Com o AesCode 32B, a questão em aberto é o que a Microsoft pretende fazer com ele: se é um artefato de pesquisa, o primeiro lançamento de uma linha de produtos, ou algo que será silenciosamente substituído por uma versão de 70B em seis semanas. Nada no repositório responde a isso, e nenhuma quantidade de leitura do model card responderá. Fique atento a três sinais — um anúncio oficial, a menção ao 85B, ou um provedor de inferência adotando o checkpoint — e trate a ausência de todos eles como o estado atual das evidências, e não como um motivo para o modelo ser desinteressante.