Eu acho excelente que isso esteja acontecendo. A maioria esmagadora dessas falhas vinha de riscos conhecidos há décadas, que continuavam em produção porque os desenvolvedores assumiam que ninguém perderia tempo vasculhando aquele canto do código.

Com agentes de IA, explorar bugs triviais ficou barato demais. Aquela “segurança por obscuridade” que parecia proteger sistemas menores evaporou da noite pro dia.

Você precisa se preocupar com segurança desde o primeiro commit. O único jeito de desenvolver esse músculo é adotar uma postura de security first o tempo inteiro, colocando segurança até no seu hello world.

Um caso real: meu consolidador financeiro pessoal

Para mostrar como isso funciona na prática, vou usar como exemplo um aplicativo desktop de investimentos e acompanhamento bancário que construí para uso próprio. Eu mantenho o código no meu servidor Gitea privado aqui em casa e jamais vou abrir o código dele, por motivos óbvios.

Ainda assim, vale compartilhar a arquitetura de segurança que desenhei para ele. Encare este artigo como uma maneira de resolver o problema (entre várias possíveis), para servir de inspiração e ponto de partida para você estudar mais a fundo.

O aplicativo é uma GUI local escrita em Rust com interface em QtQuick/QML (usando Quickshell) e um banco de dados SQLite local. Ele consolida saldos, carteira de ações, vencimento de títulos de renda fixa, cálculo de covered calls e projeções de caixa (runway) em uma única tela. Vale avisar que absolutamente todos os números, saldos, instituições (Institution Alpha, Institution Beta) e tickers que aparecem nas capturas de tela acima e abaixo são dados 100% falsos, gerados pelo modo --demo do próprio aplicativo.

Por que o aplicativo precisa automatizar um navegador web em vez de bater numa API REST bonitinha? Porque a maioria dos portais de web banking e corretoras para pessoa física tem uma usabilidade terrível e zero API para clientes individuais.

Fazer isso na mão exigiria entrar em cada banco, consultar extratos por período, baixar planilhas Excel ou PDFs de notas de corretagem e copiar tudo para outro lugar. No meu fluxo atual, o app abre um navegador controlado, eu faço o login e o 2FA manualmente na página do banco, clico em um botão “Take over” e a automação assume apenas para ler os extratos, alimentar o banco de dados e encerrar a sessão.

O pecado original da versão experimental

Na primeira versão experimental (aquela que a gente faz no embalo do vibecoding só para ver os gráficos funcionando na tela), eu cortei todos os caminhos possíveis:

• O banco SQLite ficava aberto em texto puro no disco, com permissão 0644, legível por qualquer processo rodando com o meu usuário.
• O navegador instrumentado salvava cookies e sessões em um perfil persistente no disco para acelerar o próximo acesso.
• As credenciais dos bancos ficavam guardadas no chaveiro da sessão (secret-tool), permitindo que um timer do systemd rodasse em background sem intervenção humana.
• O Chromium subia com --no-sandbox e abria a porta 9333 do Chrome DevTools Protocol (CDP) em localhost com --remote-allow-origins=*.
• Os códigos de verificação (OTP) eram lidos automaticamente da minha caixa de e-mail sincronizada localmente via mbsync.

Eu costumo ser bem paranoico com segurança, e justamente por isso comecei a ficar ansioso sabendo que esses dados estavam dando sopa em texto puro no SSD. Mesmo sendo o meu PC pessoal, trancado no meu escritório, onde ninguém mais tem acesso físico, qualquer pacote malicioso de npm, extensão de navegador, script Python ou binário comprometido rodando com o meu UID teria acesso integral à minha vida financeira.

Se um único processo comprometido no seu usuário consegue fazer cat no seu banco de dados ou conectar na porta de debug do seu navegador logado no banco, você tem um problema grave de arquitetura.

Decidi parar tudo e reescrever a fundação de segurança do projeto como se fosse um sistema crítico de produção. Vamos passar por cada camada passo a passo, num nível que qualquer desenvolvedor júnior consiga acompanhar e reproduzir nos próprios projetos.

Passo 1: criptografando o SQLite com SQLCipher e migração verificada

O primeiro passo óbvio era tirar o banco SQLite do texto puro. No ecossistema SQLite, o padrão ouro para criptografia transparente de páginas é o SQLCipher (disponível em Rust via feature bundled-sqlcipher-vendored-openssl da crate rusqlite).

Em vez de apenas criptografar colunas soltas, o SQLCipher criptografa o arquivo inteiro página por página (usando AES-256 em modo CBC com autenticação HMAC-SHA512). Nem os nomes das tabelas, nem os índices e nem o cabeçalho padrão do arquivo (SQLite format 3\0) ficam visíveis no disco.

Para garantir que nenhuma conexão abra o banco com parâmetros fracos por engano, toda conexão passa por um inicializador que rejeita cabeçalhos em texto puro e aplica o perfil criptográfico antes de qualquer query:

const RAW_SQLITE_MAGIC: &[u8; 16] = b"SQLite format 3\0";
const CIPHER_PAGE_SIZE: u32 = 4096;
const CIPHER_KDF_ITER: u32 = 256_000;

fn apply_cipher_pragmas(conn: &Connection, key: &DatabaseKey) -> Result<()> {
    let key_pragma = format!("PRAGMA key = \"{}\";", key.sqlcipher_raw_key_literal());
    conn.execute_batch(&key_pragma)
        .map_err(|_| VaultError::InvalidKeyOrCorruptDatabase)?;

    conn.execute_batch(&format!(
        "
        PRAGMA cipher_compatibility = 4;
        PRAGMA cipher_page_size = {CIPHER_PAGE_SIZE};
        PRAGMA kdf_iter = {CIPHER_KDF_ITER};
        PRAGMA cipher_kdf_algorithm = PBKDF2_HMAC_SHA512;
        PRAGMA cipher_hmac_algorithm = HMAC_SHA512;
        PRAGMA cipher_plaintext_header_size = 0;
        PRAGMA cipher_memory_security = ON;
        PRAGMA foreign_keys = ON;
        PRAGMA secure_delete = ON;
        PRAGMA temp_store = MEMORY;
        PRAGMA trusted_schema = OFF;
        "
    ))?;

    let _: i64 = conn
        .query_row("SELECT count(*) FROM sqlite_schema;", [], |row| row.get(0))
        .map_err(|_| VaultError::InvalidKeyOrCorruptDatabase)?;

    Ok(())
}

Para quem está começando, vale entender o papel de cada PRAGMA ali em cima:

• kdf_iter = 256000 e PBKDF2_HMAC_SHA512 fazem a derivação da chave passar por mais de 250 mil rodadas de hash SHA-512, tornando tentativas de força bruta muito lentas.
• cipher_plaintext_header_size = 0 criptografa inclusive os primeiros bytes do arquivo (onde fica o salt de 16 bytes), de modo que ferramentas externas como file ou hexdump enxergam apenas ruído aleatório.
• temp_store = MEMORY e cipher_memory_security = ON impedem que tabelas temporárias de ordenação vazem para /tmp em texto puro e limpam a memória alocada pelo SQLite antes de devolvê-la ao sistema operacional.
• trusted_schema = OFF evita que funções SQL ou triggers maliciosos embutidos num arquivo de banco de dados executem código inesperado.

Como migrar um banco existente sem perder dados

Quando você já tem meses de histórico financeiro num banco SQLite em texto puro, rodar um script de migração no susto é pedir para corromper dados. Eu implementei uma migração transacional com verificação matemática de integridade (logical fingerprint):

pub fn compute_logical_fingerprint(conn: &Connection) -> Result<String> {
    let mut hasher = Sha256::new();
    update_tagged(&mut hasher, "fingerprint-version", "1");

    let objects = load_schema_objects(conn)?;
    update_tagged(&mut hasher, "schema-object-count", &objects.len().to_string());
    for obj in &objects {
        update_tagged(&mut hasher, "schema-object-kind", &obj.kind);
        update_tagged(&mut hasher, "schema-object-name", &obj.name);
        update_tagged(&mut hasher, "schema-object-sql", &obj.sql);
    }

    for table in objects.iter().filter(|o| o.kind == "table") {
        hash_table_rows(conn, &table.name, &mut hasher)?;
    }

    Ok(hex_encode(&hasher.finalize()))
}

O processo completo de migração segue um roteiro estrito:

1. Pausa qualquer timer antigo e executa PRAGMA wal_checkpoint(TRUNCATE) para consolidar o arquivo WAL no banco principal.
2. Faz uma cópia de segurança com permissão 0600 e calcula o hash SHA-256 lógico de todo o esquema e de todas as linhas ordenadas de todas as tabelas.
3. Usa sqlcipher_export para copiar os dados para um novo banco criptografado, confere que o hash lógico permaneceu idêntico e importa também os PDFs de notas de corretagem que antes ficavam soltos em pastas de cache para dentro de uma tabela documents criptografada.
4. Gera um pacote de backup .mbbackup, restaura esse backup em um diretório temporário e recalcula o hash lógico pós-upgrade.
5. Só quando todos os hashes batem bit a bit, o sistema arquiva o banco antigo e move o banco criptografado para o caminho oficial usando a syscall renameat2 com a flag RENAME_NOREPLACE (que recusa sobrescrever qualquer backup existente por acidente).

Passo 2: onde guardar a chave? TPM 2.0, Polkit e queda de privilégios

Criptografar o banco de dados cria imediatamente o problema clássico de qualquer sistema de segurança: onde você guarda a chave que abre o banco?

Se você colocar a chave num arquivo .env ou config.json na sua pasta $HOME, você só trocou um cadeado aberto por um cadeado com a chave pendurada nele. Se você pedir para o usuário digitar uma senha toda vez e derivar a chave diretamente dessa senha, qualquer senha humana curta será o elo mais fraco; além disso, se a interface gráfica em QML ler essa senha, o processo da UI passa a ter acesso ao segredo.

A solução que implementei combina três recursos nativos do Linux moderno: o TPM 2.0, o systemd-creds e o Polkit (pkexec).

O que é um TPM?

Para quem nunca mexeu com isso: TPM (Trusted Platform Module) é um pequeno chip criptográfico dedicado que já vem soldado na placa-mãe de praticamente qualquer PC ou notebook moderno (ou integrado no próprio processador, como Intel PTT e AMD fTPM).

Diferente de um arquivo no seu SSD, o TPM possui chaves internas gravadas em hardware que nunca saem de dentro do chip. Você pode entregar um bloco de bytes para o TPM (no nosso caso, uma chave aleatória de 256 bits gerada via CSPRNG do kernel) e pedir para ele “selar” (seal) esse segredo.

O TPM devolve um arquivo criptografado (.cred). Se um atacante roubar o seu SSD ou copiar esse arquivo .cred para outro computador, ele será inútil: apenas o chip TPM físico da sua placa-mãe consegue descriptografar aquele envelope.

No Linux com systemd, nós nem precisamos escrever código C cabeludo falando com /dev/tpmrm0 diretamente. O utilitário systemd-creds já faz o seal (encrypt com --with-key=host+tpm2) e o unseal (decrypt com --refuse-null, lendo o tipo de chave direto do cabeçalho do .cred):

pub fn build_systemd_creds_encrypt_command(cred_name: &str) -> (PathBuf, Vec<OsString>) {
    (
        PathBuf::from("/usr/bin/systemd-creds"),
        vec![
            OsString::from("--with-key=host+tpm2"),
            OsString::from("--name"),
            OsString::from(cred_name),
            OsString::from("--newline=no"),
            OsString::from("encrypt"),
            OsString::from("-"),
            OsString::from("-"),
        ],
    )
}

pub fn build_systemd_creds_decrypt_command(
    cred_name: &str,
    credential_path: &Path,
) -> (PathBuf, Vec<OsString>) {
    (
        PathBuf::from("/usr/bin/systemd-creds"),
        vec![
            OsString::from("--name"),
            OsString::from(cred_name),
            OsString::from("--newline=no"),
            OsString::from("--refuse-null"),
            OsString::from("decrypt"),
            credential_path.as_os_str().to_os_string(),
            OsString::from("-"),
        ],
    )
}

Como a minha senha de login destrava tudo sem tocar na UI

O arquivo .cred selado pelo TPM fica salvo em /var/lib/.../vault.key.cred, pertencente ao usuário root:root com permissão 0600. Nenhum processo rodando com o meu usuário comum consegue sequer ler esse arquivo.

Quando eu abro o aplicativo no desktop e clico em “Unlock Vault”, acontece uma coreografia bem específica:

1. A interface gráfica dispara /usr/bin/pkexec /usr/lib/.../key-launcher.
2. O Polkit intercepta a chamada e abre o prompt nativo do sistema operacional pedindo a minha senha de login do Linux (configurado com <allow_active>auth_self</allow_active>, sem cache de sessão, exigindo autenticação a cada abertura).
3. A minha senha de login nunca passa pelo meu aplicativo. Quem valida a senha é o agente do Polkit/PAM do próprio sistema operacional.
4. Assim que o Polkit confirma minha senha, ele inicia o binário key-launcher como root.
5. O key-launcher confere que foi invocado pelo meu UID esperado (PKEXEC_UID), valida que os diretórios têm as permissões corretas sem symlinks maliciosos (usando O_NOFOLLOW), e chama o systemd-creds para pedir ao TPM que abra o arquivo .cred.
6. O key-launcher recebe os 32 bytes da chave em memória (protegida com ZeroizeOnDrop para ser zerada assim que sair de escopo), cria um pipe anônimo na memória do kernel, escreve os 32 bytes no File Descriptor 3 (FD 3) e fecha a ponta de escrita.
7. Antes de iniciar o backend do aplicativo, o key-launcher joga fora todos os privilégios de root de forma irreversível e substitui o próprio processo via execveat.

Olha como fica a sequência de queda de privilégios (privilege drop) e blindagem de memória em Rust dentro do key-launcher:

const KEY_FD: RawFd = 3;

fn drop_privileges_permanently(target_uid: u32, target_gid: u32) -> Result<()> {
    unsafe {
        libc::umask(0o077);
    }
    std::env::set_current_dir("/")?;

    drop_supplementary_groups()?;
    clear_capability_bounding_set()?;
    clear_ambient_capabilities()?;
    lock_no_root_securebits()?;

    // Troca GID e UID reais, efetivos e salvos de forma definitiva
    let rc_gid = unsafe { libc::setresgid(target_gid, target_gid, target_gid) };
    if rc_gid != 0 {
        return Err(LauncherError::Syscall("setresgid", io::Error::last_os_error()));
    }

    let rc_uid = unsafe { libc::setresuid(target_uid, target_uid, target_uid) };
    if rc_uid != 0 {
        return Err(LauncherError::Syscall("setresuid", io::Error::last_os_error()));
    }

    // Verifica que uma tentativa de recuperar root (setuid(0)) falha obrigatoriamente
    if unsafe { libc::setuid(0) } == 0 {
        return Err(LauncherError::PrivilegeVerification(
            "setuid(0) succeeded after privilege drop",
        ));
    }

    // Impede ganho de privilégios em execve futuros e bloqueia ptrace/core dumps
    unsafe {
        libc::prctl(libc::PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
        libc::prctl(libc::PR_SET_DUMPABLE, 0, 0, 0, 0);
    }
    set_zero_core_limit()?;
    Ok(())
}

Repare nos detalhes no final dessa função:

• PR_SET_DUMPABLE = 0 e RLIMIT_CORE = 0 proíbem o kernel de gerar arquivos de core dump no disco (que conteriam a chave do banco em memória) e impedem que outros processos do mesmo usuário anexem um gdb ou ptrace para inspecionar a RAM. Como o kernel Linux reseta o atributo dumpable para 1 após um execve em binários normais, tanto o session-backend quanto os binários auxiliares do navegador e do parser reaplicam PR_SET_DUMPABLE = 0 logo na primeira linha do main (enquanto RLIMIT_CORE = 0 e PR_SET_NO_NEW_PRIVS já vêm herdados do launcher).
• Passar segredos por --key=... ou variáveis de ambiente expõe o valor em /proc/<pid>/cmdline e /proc/<pid>/environ. Passando via um pipe anônimo no FD 3 que é lido uma única vez e fechado imediatamente no boot do session-backend, o segredo jamais aparece no /proc.
• A interface gráfica em QML conversa com o session-backend apenas por mensagens JSON delimitadas por linha (NDJSON com limite de 64 KiB). A UI nunca recebe a chave criptográfica e nem toca no arquivo SQLite diretamente.

Blindando a chave na memória RAM (mlock, MADV_DONTDUMP) e auto-lock por inatividade

Mesmo depois que o session-backend lê os 32 bytes do FD 3 e fecha o descritor, a chave precisa viver na memória RAM enquanto o cofre estiver aberto. Isso levanta dois riscos clássicos que muita gente esquece: e se o kernel do Linux resolver paginar aquela região de memória para uma partição de swap não criptografada no SSD (ou imagem de hibernação)? E se eu destravar o aplicativo de manhã, minimizar a janela e esquecer o cofre aberto pelo resto do dia?

Para resolver o primeiro problema, o tipo DatabaseKey guarda os 32 bytes dentro de um Box<[u8; 32]> na heap e trava a página física na RAM com mlock:

pub struct DatabaseKey(Box<[u8; KEY_BYTES]>);

impl DatabaseKey {
    pub fn from_bytes(mut bytes: [u8; KEY_BYTES]) -> Self {
        let mut boxed = Box::new(bytes);
        bytes.zeroize();
        lock_key_page(&mut boxed[..]);
        Self(boxed)
    }
}

impl Drop for DatabaseKey {
    fn drop(&mut self) {
        let ptr = self.0[..].as_mut_ptr().cast::<core::ffi::c_void>();
        self.0.zeroize();
        let _ = unsafe { rustix::mm::munlock(ptr, KEY_BYTES) };
    }
}

fn lock_key_page(buffer: &mut [u8]) {
    let ptr = buffer.as_mut_ptr().cast::<core::ffi::c_void>();
    let len = buffer.len();
    unsafe {
        let _ = rustix::mm::mlock(ptr, len);
        #[cfg(target_os = "linux")]
        let _ = rustix::mm::madvise(ptr, len, rustix::mm::Advice::LinuxDontDump);
    }
}

Um detalhe sutil de Rust aqui: por que usar Box<[u8; 32]> em vez de um array inline [u8; 32] dentro da struct? Porque a syscall mlock(2) trava um intervalo de endereços virtuais específicos, e qualquer move de um array na stack mudaria o endereço dos bytes, deixando o endereço antigo travado à toa e o novo desprotegido.

Com Box, o endereço na heap permanece estável do nascimento até o Drop, onde limpamos os bytes com zeroize() antes de chamar munlock. De quebra, MADV_DONTDUMP marca aquela página específica para jamais entrar em um dump de memória.

Já para não deixar o cofre aberto indefinidamente quando esqueço a janela aberta em outro workspace, o loop principal do session-backend roda com um timer de inatividade (IDLE_LOCK_TIMEOUT de 15 minutos). Se passarem 15 minutos sem nenhuma requisição da UI e sem nenhuma coleta bancária em andamento, o backend fecha a conexão do SQLCipher, destrói a DatabaseKey (disparando o zeroize + munlock), avisa a UI que a sessão expirou (idle_locked) e encerra o próprio processo. Para voltar a usar o app, sou obrigado a passar novamente pelo prompt do Polkit e pelo TPM.

Passo 3: colocando o navegador e o parser de PDFs em uma prisão (sandbox)

Com o banco de dados trancado a sete chaves, sobrava a parte mais perigosa de qualquer aplicação moderna: o navegador web.

Um navegador é praticamente um sistema operacional inteiro executando JavaScript arbitrário vindo da internet. Na minha primeira versão, o navegador rodava solto na minha sessão com acesso à minha pasta $HOME, ao meu servidor gráfico principal e à internet inteira.

Para resolver isso, desenhei um pipeline em dois estágios isolados: um sandbox para o navegador durante o login manual, e um segundo sandbox sem rede apenas para fazer o parsing dos arquivos baixados.

Prós e contras de isolar o navegador em uma sandbox

Antes de ver o código, vale colocar na balança o que você ganha e o que você paga ao isolar o navegador dessa forma.

Do lado dos benefícios:

• O navegador enxerga apenas um /home/banker sintético montado em RAM (tmpfs), sem qualquer acesso aos seus arquivos pessoais, chaves SSH (~/.ssh), GPG, carteira de cripto ou ao cofre SQLCipher.
• Assim que a coleta termina e o processo morre, cookies, tokens de sessão, cache e localStorage desaparecem da memória RAM.
• Em vez de abrir a janela direto no compositor principal da sessão, rodamos dentro de um compositor Wayland dedicado (cage), evitando que outras janelas façam keylogging ou captura de tela silenciosa.
• Mesmo que um script malicioso tente enviar dados para um domínio externo, o firewall interno da sandbox bloqueia qualquer IP fora da lista do banco.

Do lado do custo operacional:

• Como o perfil começa do zero a cada execução e nenhuma credencial fica salva, eu preciso digitar meu login e aprovar o 2FA no celular toda vez que quero sincronizar os dados.
• Como trancamos os IPs de saída no início da sessão, se o banco usar um CDN que muda de IP no meio do login, a conexão cai e precisa ser reiniciada.
• O empacotamento exige ter bubblewrap (bwrap), slirp4netns, nftables e cage instalados e configurados no host.

Como funciona o bloqueio de rede dentro do Bubblewrap

Muita gente usa o bubblewrap (bwrap) com slirp4netns --disable-host-loopback achando que isso basta para isolar a rede. Essa flag realmente impede que o navegador acesse serviços rodando no 127.0.0.1 da máquina host, mas continua permitindo que o navegador conecte em qualquer IP público da internet.

Para impedir que o navegador converse com qualquer servidor fora do banco que estou acessando, o sandbox cria dois usuários diferentes dentro do namespace de rede: o navegador roda como UID 1000 (BROWSER_UID) e um pequeno proxy Rust interno (Pinned Egress Broker) roda como UID 1001 (BROKER_UID).

Antes do navegador abrir, um conjunto de regras nftables com política padrão drop é aplicado dentro do namespace:

pub fn generate_nftables_ruleset(
    pinned: &PinnedEgress,
    broker_port: u16,
    browser_uid: u32,
    broker_uid: u32,
) -> Result<String> {
    let mut allowed_ips = Vec::new();
    for addrs in pinned.host_addrs.values() {
        for addr in addrs {
            if !is_globally_routable_bank_ip(*addr) {
                return Err(SessionError::PinnedIpNotPublic(*addr));
            }
            if !allowed_ips.contains(addr) {
                allowed_ips.push(*addr);
            }
        }
    }

    let ip_list = allowed_ips
        .iter()
        .map(Ipv4Addr::to_string)
        .collect::<Vec<_>>()
        .join(", ");

    Ok(format!(
        "table inet bank_sandbox {{\n\
         \tchain output {{\n\
         \t\ttype filter hook output priority 0; policy drop;\n\
         \t\tct state established,related accept\n\
         \t\toifname \"lo\" meta skuid {browser_uid} ip daddr 127.0.0.1 tcp dport {broker_port} accept\n\
         \t\toifname \"lo\" meta skuid {broker_uid} ip daddr 127.0.0.1 accept\n\
         \t\tmeta skuid {broker_uid} ip daddr {{ {ip_list} }} tcp dport 443 accept\n\
         \t\tdrop\n\
         \t}}\n\
         }}\n"
    ))
}

Olha que elegante o efeito dessas cinco linhas de nftables:

1. O navegador (skuid 1000) é proibido de sair para a internet diretamente (policy drop). O único pacote que o kernel deixa o navegador enviar é para 127.0.0.1:18080, onde mora o nosso broker.
2. O broker (skuid 1001) recebe o pedido HTTP CONNECT host:443, confere se o host está na lista estrita daquele banco (ex.: ebanking.bank-alpha.example), e conecta diretamente nos endereços IPv4 públicos que foram pré-resolvidos antes do navegador nascer.
3. IPs privados (RFC 1918), loopback, link-local e endpoints de metadados (169.254.169.254) são rejeitados na hora, anulando ataques de DNS rebinding.
4. Como o Chromium roda dentro do bwrap com um namespace de usuário mapeado adequadamente, nós mantemos o sandbox interno do próprio Chromium ligado (sem --no-sandbox), e o CDP escuta em uma porta efêmera (--remote-debugging-port=0) acessível apenas dentro do namespace isolado.

Ponte de área de transferência unidirecional e de uso único (--paste-once --sensitive)

Isolar o navegador em um compositor Wayland próprio (cage) com um diretório XDG_RUNTIME_DIR separado cria um problema prático imediato: como eu colo uma senha aleatória de 30 caracteres vinda do meu gerenciador de senhas do desktop para dentro do navegador isolado?

Se você compartilhar o socket Wayland principal só para fazer o Ctrl+V funcionar, você joga fora todo o isolamento gráfico e permite que uma página maliciosa leia ou sobrescreva a sua área de transferência do host.

A solução foi construir uma ponte de clipboard estritamente unidirecional (do host para o cage) usando wl-paste e wl-copy:

fn nested_clipboard_offer_command(wl_copy: &Path, runtime: &Path, nested_display: &str) -> Command {
    let mut command = Command::new(wl_copy);
    command
        .args([
            "--foreground",
            "--paste-once",
            "--trim-newline",
            "--type",
            "text/plain;charset=utf-8",
            "--sensitive",
        ])
        .env_clear()
        .env("PATH", "/usr/bin")
        .env("XDG_RUNTIME_DIR", runtime)
        .env("WAYLAND_DISPLAY", nested_display)
        .stdout(Stdio::null())
        .stderr(Stdio::inherit());
    command
}

Funciona assim: o processo supervisor fora do bwrap observa apenas texto puro copiado no host e o injeta no socket Wayland aninhado (wayland-bank) com as flags --paste-once e --sensitive.

O navegador dentro do sandbox consegue receber um único Ctrl+V da senha que acabei de copiar no gerenciador de senhas; imediatamente após essa colagem, o wl-copy destrói a oferta dentro do sandbox e encerra. E como não existe ponte no sentido inverso, o navegador jamais consegue escrever nada de volta na área de transferência do meu desktop.

O segundo estágio: fazendo parsing de PDFs e Excel sem rede

Depois que eu faço o login no banco, clico em “Take over” e o worker baixa os extratos ou notas de corretagem para a pasta /handoff, o supervisor mata imediatamente todo o grupo de processos do navegador e da rede.

Só que agora temos outro risco: fazer parsing de arquivos PDF e planilhas XLSX vindos de fora. Bibliotecas que leem PDF e formatos legados de Excel são historicamente cheias de vulnerabilidades de memória e denial of service (inclusive atualizamos a crate calamine durante o projeto por conta do advisory RUSTSEC-2026-0436).

Em vez de deixar o processo principal que tem a chave do banco abrir esses PDFs, o sistema congela o diretório de staging com permissão 0500 (somente leitura) e dispara um segundo sandbox bwrap, dessa vez com --unshare-net (zero interface de rede) e limites rígidos de recursos via prlimit:

const PARSER_AS_LIMIT_BYTES: u64 = 768 * 1024 * 1024; // 768 MiB RAM max
const PARSER_CPU_LIMIT_SECONDS: u64 = 10;             // 10s CPU max
const PARSER_NOFILE_LIMIT: u64 = 64;                  // max 64 file descriptors
const PARSER_NPROC_LIMIT: u64 = 16;                   // max 16 threads/processes

pub fn build_sandboxed_parser_command(
    bwrap_program: &Path,
    prlimit_program: &Path,
    parser_binary: &Path,
    staging_dir: &Path,
    output_file: &Path,
    bank: &str,
) -> (PathBuf, Vec<OsString>) {
    // ...
    let args = vec![
        OsString::from("--unshare-all"),
        OsString::from("--unshare-net"),
        OsString::from("--die-with-parent"),
        OsString::from("--new-session"),
        OsString::from("--clearenv"),
        // Monta /usr, /lib e o diretório de staging em modo somente-leitura (--ro-bind)
        // ...
    ];
    // Executa sob prlimit --as=768M --cpu=10 --nofile=64 --nproc=16 --core=0
}

Se um PDF malformado tentar explodir a memória (um zip bomb dentro de um XLSX) ou explorar um bug no parser, o processo bate no teto de cerca de 770 MB de RAM ou 10 segundos de CPU, fica sem rede para exfiltrar nada, sem acesso ao banco de dados e acaba morto pelo kernel. O processo principal só aceita o resultado se o parser devolver um JSON estritamente tipado e validado dentro do limite de tamanho.

Passo 4: backups autenticados, chave de recuperação e NAS

Quando você trava seu banco de dados no chip TPM da placa-mãe, surge uma pergunta inevitável: e se a minha placa-mãe queimar amanhã?

Se o único jeito de abrir o banco fosse o chip TPM daquela placa-mãe específica, um defeito de hardware significaria perder todos os seus dados financeiros para sempre. Segurança sem plano de recuperação de desastres é só uma forma sofisticada de perder dados.

Por isso, a estratégia de backup e recuperação foi dividida em três camadas.

1. Código de recuperação offline com checksum

No momento em que o cofre é criado (enrollment), o key-launcher gera a chave de 256 bits e, antes de selá-la no TPM, exibe uma única vez no terminal (/dev/tty) um código de recuperação codificado em Base32 no formato MBRK1-XXXX-XXXX-..., protegido por um checksum SHA-256 de 5 bytes contra erros de digitação.

O programa exige que você redigite esse código às cegas no terminal para provar que você realmente o anotou (eu guardo o meu em uma nota segura no meu gerenciador de senhas, fora da máquina) antes de permitir que o cofre seja ativado. Se meu PC pegar fogo, basta rodar o utilitário de restauração do pacote em uma máquina nova, informar o código MBRK1-... e o sistema restaura o cofre e re-sela a chave no TPM do computador novo.

2. Pacotes .mbbackup autenticados com teste de restauração imediato

Copiar um arquivo SQLite com cp enquanto ele está aberto pode gerar um backup corrompido. Por isso o app possui um formato próprio de backup (.mbbackup) que empacota:

• Um cabeçalho mágico (MBBACKUP) + versão do formato;
• Um manifesto em JSON canônico (seguindo a RFC 8785) contendo a versão do schema, parâmetros do SQLCipher, quantidade de documentos embutidos e o logical fingerprint SHA-256 de todos os dados;
• O payload binário do banco já criptografado pelo SQLCipher;
• Uma assinatura HMAC-SHA256 de 32 bytes calculada sobre o cabeçalho, o manifesto e o payload, usando uma subchave derivada via HKDF-SHA256.

O detalhe mais importante: toda vez que um backup é criado, a própria função de backup abre imediatamente o arquivo .mbbackup recém-gerado, restaura em um diretório temporário, valida o HMAC e compara o fingerprint lógico antes de retornar sucesso. Backup que nunca foi testado na restauração não existe.

3. Backup externo diário no NAS com dupla criptografia

Por fim, manter o backup apenas no mesmo SSD onde mora o banco original deixa você exposto a falha de disco ou ransomware.

Aqui em casa eu mantenho meus servidores NAS em RAID-6 (incluindo o QNAP com ZFS RAID-Z2 para onde evacuei meus dados recentemente depois que quase perdi 90 TB de dados quando dois discos do meu antigo Synology falharam juntos durante um rebuild, e o próprio Synology reconstruído em RAID-6). Toda madrugada, às 3h da manhã, um timer do systemd na minha estação de trabalho roda o Restic fazendo snapshot incremental da minha pasta de projetos e dados via NFS para o NAS, mantendo uma rotação enxuta de snapshots diários, semanais e mensais (3 diários, 3 semanais e 2 mensais).

Repare na defesa em profundidade aqui: mesmo que alguém invada a rede local, comprometa o servidor NFS ou roube fisicamente os HDs de dentro do NAS, o atacante encontrará um repositório Restic criptografado; e mesmo que por algum milagre ele tivesse a senha do Restic, o arquivo dentro do backup já é um cofre SQLCipher criptografado cuja chave mora dentro do TPM da minha estação de trabalho.

Conclusão: segurança como gestão de risco contínua

Quão seguro tudo isso deixa o meu aplicativo? Ele é seguro o suficiente para o meu modelo de ameaça, sabendo que segurança absoluta simplesmente inexiste no mundo real.

No próprio documento de arquitetura do projeto (ADR 0001), eu deixei registrado explicitamente os riscos residuais que escolhi aceitar:

• Eu mantenho o Secure Boot desabilitado na minha estação por conta do meu fluxo de boot e drivers no Linux; logo, o selo do TPM protege contra roubo de disco e processos desprivilegiados, enquanto ataques físicos ao bootloader antes do sistema subir ficam fora desse escopo.
• O compositor Wayland aninhado (cage) isola o navegador em wayland-bank, mas o próprio cage ainda é um cliente do compositor principal da sessão (Hyprland/wlroots). Um processo malicioso rodando com o meu UID no host ainda poderia usar protocolos de captura de tela do compositor (zwlr_screencopy_v1 / ext_image_copy_capture_v1, como o grim) enquanto a janela do banco está visível, ou ler a senha no clipboard do host antes de ela ser limpa após o Ctrl+V.
• O key-launcher garante em tempo de execução (via O_NOFOLLOW) que os binários instalados em /usr/lib/... pertencem a root:root, impedindo que um processo do meu usuário troque o executável instalado. Porém, como eu desenvolvo o projeto na mesma máquina com o meu UID normal, um malware no meu usuário poderia tentar alterar o código-fonte ou scripts de build (cargo/makepkg) esperando a próxima vez que eu compilar e instalar um pacote atualizado com pacman -U, o que exige revisar git status e o diff antes de empacotar.
• Apagar o banco antigo em texto puro em um SSD moderno com sistema de arquivos Copy-on-Write (como Btrfs) desvincula o arquivo do sistema operacional, mas o wear leveling da controladora flash física pode reter blocos antigos até serem sobrescritos.
• Enquanto o cofre está aberto e desbloqueado na minha sessão, um malware que já tenha conseguido execução de código como root no meu kernel ativo pode fazer o que quiser.

É aqui que a maioria das pessoas se engana. Muita gente trata segurança como se fosse um interruptor binário: ou o sistema é “seguro” ou é “inseguro”.

Na vida real, segurança é um jogo contínuo de avaliação de risco: “quanto você está disposto a proteger, e a que custo de preço, tempo e usabilidade?”.

O único computador “perfeitamente seguro” é aquele desligado da tomada, sem placa de rede, trancado dentro de um bloco de concreto no fundo do oceano (e ele também não serve para nada).

Se o seu aplicativo precisa se conectar ao site do seu banco pela internet para buscar um extrato, ele já deixou de ser perfeitamente isolado por definição. A partir daí, o nosso trabalho como engenheiros é empilhar mitigações em camadas (criptografia em repouso, chave selada em hardware, queda de privilégios, isolamento de namespaces, firewall por UID, parser sem rede, backups verificados) e entender exatamente quanto risco residual ainda sobra em cada camada.

A inteligência artificial é fantástica para escanear vulnerabilidades conhecidas e até para implementar essas blindagens quando você sabe exatamente o que pedir para ela. Mas a IA jamais vai adivinhar o seu modelo de ameaça sozinha, e muito menos vai salvar você da própria ignorância.

Se você apenas pedir para o agente criar um app no vibecoding e aceitar tudo de olhos fechados, confiando 100% na IA sem entender como funcionam permissões do Linux, processos, memória, rede e criptografia, o seu aplicativo nascerá inseguro por padrão. Estude os fundamentos, desconfie do caminho mais fácil e coloque segurança desde o seu primeiro hello world.

Muita gente leu aquilo pensando só em privacidade, como se a preocupação fosse o TikTok encontrar a senha do banco. O problema começa bem antes. Essas empresas precisam reconhecer quem voltou, registrar o que essa pessoa fez e prever o que vai prender sua atenção em seguida.

É aí que aparecem alguns folclores. A pessoa curte e favorita uma pilha de vídeos de cachorro pra “confundir o algoritmo”. Instala uma VPN e acha que virou anônima. Limpa o cache, reinstala o aplicativo, cria outra conta ou troca de celular e acredita que ganhou uma folha em branco. Também tem quem nunca aperte Like e conclua que não entregou preferência nenhuma.

Tudo isso pode mudar algum sinal. Nenhuma dessas ações apaga o conjunto inteiro.

Sua intenção fica na sua cabeça. O sistema recebe o seu comportamento.

Não existe um “algoritmo” só

Quando alguém fala “o algoritmo do TikTok”, parece que existe uma função mágica escolhendo o próximo vídeo. Na prática são várias camadas trabalhando juntas:

1. Identidade: decide se este aparelho, esta instalação e esta conta já apareceram antes.
2. Telemetria: registra o que aconteceu, como tempo assistido, pausa, repetição, busca, comentário, compartilhamento, toque e rolagem.
3. Recomendação: estima quais vídeos têm maior chance de produzir a próxima interação.
4. Experimentação: coloca conteúdo diferente no feed pra medir reações e atualizar o perfil.

O fingerprint fica principalmente na primeira camada. Ele ajuda a manter continuidade quando um cookie, um ID de instalação ou uma conta muda. O histórico de comportamento alimenta as demais.

O próprio TikTok explica que usa vídeos assistidos até o fim ou pulados, likes, compartilhamentos, comentários, contas seguidas, sons, hashtags, localização, idioma e tipo de aparelho. Para a maioria dos usuários, tempo assistido e outras interações recebem mais peso que configurações do aparelho.

A descrição pública é simplificada, claro. A nossa análise estática encontrou o texto de cada busca e eventos de play_time, percentual assistido, pausa, repetição, arrastar a barra de progresso, entrada e saída de tela, troca de conta e milhares de outras ações. O serviço que entrega o feed inevitavelmente sabe o que você pediu e por quanto tempo ficou ali.

Fingerprinting: reconhecer sem depender de um número só

Um fingerprint combina sinais pequenos demais pra identificar alguém isoladamente. Modelo do celular, resolução, CPU, GPU, lista de sensores, câmeras, fuso horário, idioma, operadora, versão do sistema, tempo desde o último boot e características da instalação formam um retrato muito mais específico quando aparecem juntos.

Alguns sinais são estáveis. Outros variam. O sistema trabalha com graus de confiança e tolera diferenças entre observações.

No mesmo aparelho e perfil Android, o caso é bem direto. O ANDROID_ID usado pelo TikTok é estável por combinação de aparelho, usuário Android e chave de assinatura do aplicativo. Limpar os dados ou reinstalar troca IDs aleatórios guardados pelo app, mas não troca esse identificador. Modelo, sensores, tela, câmera, rede e estado de hardware também continuam parecidos.

Quando você troca de aparelho, a situação muda. O hardware novo produz outro fingerprint. Entrar na mesma conta resolve a associação de forma determinística. Criar outra conta deixa o cruzamento probabilístico: mesma rede doméstica, região, idioma, horários, relações sociais e um padrão de consumo muito semelhante podem sugerir que as duas identidades pertencem à mesma pessoa, sem provar a relação.

Esse mercado chama o conjunto de cross-device tracking ou device graph. Há correspondências determinísticas, como o mesmo login ou e-mail, e probabilísticas, baseadas na combinação de sinais. Pesquisadores já documentavam essa diferença em 2017. A política americana atual do próprio TikTok diz que a empresa atribui IDs de aparelho e usuário e pode usar essas informações pra identificar atividade entre dispositivos.

Portanto, “troquei de celular” pode significar três coisas completamente diferentes:

• você entrou na mesma conta e informou a ligação;
• criou outra conta, mas deixou várias pontes que permitem uma associação provável;
• criou uma identidade realmente isolada, sem conta, contatos, parceiros, rede ou hábitos compartilhados, reduzindo muito a confiança da associação.

Um exemplo simplificado

Os dados abaixo são inventados e servem pra visualizar como um servidor compara observações. O formato interno e qualquer pontuação real do TikTok continuam desconhecidos.

conta: 84721
id_da_instalacao: "A9F2"
android_id: "7c81"
aparelho: "Pixel 10"
tela: "1080x2424@120"
sensores: "hash-31b7"
idioma_fuso: "pt-BR / America-Sao_Paulo"
rede_frequente: "200.10.x.x"
horario_de_uso: "22h-01h"
interesses_observados: [carros, tecnologia, politica]
gestos: "rolagem rapida, pressao media 0.42"

O código confirma a coleta de pressão, tamanho e trajetória dos toques como sinais de humanidade e antifraude. A análise estática não demonstra que o TikTok trate isso como uma biometria pessoal capaz de reconhecer sua mão, por isso o campo aparece no exemplo como telemetria e fica fora da comparação de identidade abaixo.

Agora compare o que acontece:

Depois da reinstalação, sobram sinais fortes demais pra chamar aquilo de um desconhecido. No celular novo com conta nova, sobra uma hipótese. Quanto mais pontes você mantém, mais a hipótese ganha confiança. Se você entra na conta antiga, acabou a dúvida.

O fingerprint pode começar sem seu nome. Em algum momento você entra numa conta, usa um e-mail, sincroniza contatos, abre um link identificado ou faz qualquer ação que ligue o pseudônimo a você. A partir daí, o histórico anterior pode ser costurado à identidade conhecida. Um relatório técnico de 2026 do Georgetown Law Institute for Technology Law & Policy chama isso de identifier bridging: um fingerprint probabilístico ganha uma ponte pra um identificador estável.

O teatro dos vídeos de cachorro

Vamos usar o exemplo mais comum. Você quer evitar política, fake news e teorias conspiratórias. Então busca vídeos de cachorro, assiste vários até o fim, curte cinquenta e favorita vinte. O feed passa a mostrar mais animais. Funcionou?

Parcialmente. Você ensinou que vídeos de cachorro produzem interação. O TikTok oferece até ferramentas explícitas pra fazer isso: “Não tenho interesse”, filtros de palavras, gerenciamento de temas e atualização do feed Para Você.

Só que você não apagou política do perfil. Você acrescentou outro interesse. O servidor ainda tem o histórico anterior, as contas seguidas, buscas, vídeos assistidos, pausas, comentários, compartilhamentos e os sinais de pessoas com comportamento semelhante ao seu.

Também existe uma diferença enorme entre o que você acha que comunicou e o que a máquina recebeu:

• você abriu um vídeo absurdo pra entender o que estavam dizendo;
• assistiu até o final porque ficou indignado;
• voltou um trecho pra conferir;
• abriu os comentários;
• respondeu dizendo que era mentira;
• mandou o vídeo pra alguém acompanhado de “olha que absurdo”.

Para você, foram seis manifestações de rejeição. Para um modelo olhando eventos, foram vários minutos de atenção e uma sequência rara de interações. O conteúdo funcionou.

O mesmo vale pra sua atuação com animais. Nos eventos enviados ao servidor não existe o campo estou_fingindo_gostar_de_cachorro; chegam buscas, vídeos completos, likes e favoritos. O perfil pode carregar vários interesses ao mesmo tempo. O resultado pode ser alguém que gosta de cachorro e consome política quando aparece, especialmente se o segundo assunto gerar reações mais fortes.

Auditorias independentes confirmam que o feed reage a mais de um tipo de sinal. Um experimento com contas controladas encontrou efeitos de seguir, curtir e tempo assistido, com seguir como o fator mais forte naquele teste. Outro estudo sobre exploration e exploitation de interesses mediu como duração, likes e follows mudam a personalização ao longo da timeline.

Você consegue influenciar o feed. Isso é bem diferente de apagar o perfil ou conquistar imunidade contra manipulação.

O feed sempre volta a testar você

Um recommender não pode servir só o que já sabe. Se fizer isso, fica repetitivo e nunca descobre um interesse novo. Por isso ele alterna exploitation, conteúdo com alta chance de funcionar, e exploration, apostas usadas pra aprender.

É por isso que o vídeo político, a dieta milagrosa ou a conspiração volta a aparecer no meio dos cachorros. Pode ser popular na sua região, recente, parecido com algo que você viu, consumido por um grupo semelhante ao seu ou simplesmente um teste. O próprio TikTok reconhece que popularidade, diversidade e comportamento de usuários parecidos participam da seleção.

Você pode passar uma semana disciplinado e ignorar tudo. Basta uma noite cansada, um assunto que mexe com você ou um vídeo especialmente eficiente pra produzir os sinais que faltavam. A recomendação se ajusta de novo.

Uma auditoria publicada em 2025 observou reforço persistente de conteúdo e redução gradual de diversidade em timelines controladas. O resultado descreve um mecanismo de feedback, sem decretar que todo usuário termina preso numa bolha idêntica: recomendação gera comportamento, comportamento alimenta recomendação, e o próximo lote fica mais parecido com o que funcionou.

O nome “echo chamber” faz parecer que alguém fechou uma porta por fora. Muitas vezes você participa da construção. Escolhe assistir, comentar, seguir e compartilhar; o sistema reduz a fricção pra repetir aquilo. Em pouco tempo, frequência vira familiaridade e familiaridade começa a parecer consenso.

A armadilha de achar que você venceu

Este é o pedaço mais perigoso. Quem sabe que o feed é manipulado mantém alguma desconfiança. Quem acredita que enganou o sistema baixa a guarda.

“Eu treinei meu algoritmo pra não me mostrar fake news” vira uma licença pra tratar o que sobrou como confiável. A lógica é circular: se apareceu depois da sua limpeza, deve ter passado pelo seu filtro. Só que o filtro otimiza probabilidade de interação. Ele não funciona como auditor de fatos.

Um estudo publicado no PNAS encontrou um problema parecido fora do TikTok: três em cada quatro participantes superestimaram a própria capacidade de distinguir notícias verdadeiras de falsas. Em média, se colocaram 22 percentis acima do desempenho real. Os mais confiantes também visitavam mais sites não confiáveis e demonstravam maior disposição pra curtir ou compartilhar conteúdo falso alinhado à própria política.

Uma auditoria recente do TikTok encontrou outro sinal preocupante: interagir com desinformação sobre um assunto levou a recomendações de desinformação relacionada e também de outros assuntos. Contas novas sem histórico também receberam mais recomendações desse tipo em alguns experimentos. Um perfil vazio não começa necessariamente num ambiente neutro e limpo.

Sua confiança subjetiva não entra como evidência de que o feed ficou seguro. Ela só reduz a chance de você conferir.

“Não tenho nada importante lá”

Outra defesa comum é dizer que o aplicativo não tem senha de banco, documento secreto nem foto comprometedora. A pessoa avalia cada campo isoladamente e conclui que entregou apenas lixo.

O valor está nas inferências e nas decisões tomadas em cima delas. A política do próprio TikTok diz que a empresa infere idade, gênero e interesses. Comportamento repetido pode sugerir rotina, poder de compra, religião, posição política, estado emocional, vulnerabilidades, relacionamentos e acontecimentos importantes da vida. Algumas inferências estarão erradas, o que também causa dano.

Esse poder de inferência já era mensurável muito antes do TikTok. Em 2013, um estudo com mais de 58 mil voluntários mostrou que Facebook Likes permitiam prever atributos sensíveis como orientação sexual, etnia, religião, posição política, personalidade, idade e gênero. Likes são dados banais até alguém cruzar milhares deles.

Uma plataforma já consegue afetar você escolhendo conteúdo e anúncios. A segmentação também pode ser explorada por campanhas, vendedores e golpistas pra alcançar pessoas no momento em que parecem mais receptivas. Tudo parte de um perfil que você não vê e raramente consegue corrigir.

A FTC analisou as práticas de nove grandes plataformas, incluindo a ByteDance, e descreveu coleta em massa, retenção ampla e monetização por publicidade direcionada. O modelo econômico transforma pequenas observações em segmentação e previsão sem precisar encontrar uma senha valiosa.

Privacidade não protege apenas segredos. Ela limita quem pode montar um modelo seu e usar esse modelo pra decidir o que você verá em seguida.

Os outros truques que não fazem o que você imagina

Vale limpar mais alguns mitos:

• VPN: troca o IP público e ajuda a esconder sua origem da operadora ou da rede local. O app vê que existe uma VPN e continua recebendo conta, fingerprint e comportamento.
• Modo anônimo: serve pro navegador não guardar parte do histórico local. Não muda nada dentro do aplicativo nativo e não impede fingerprinting remoto.
• Limpar cache ou reinstalar: remove estado local descartável. No mesmo aparelho e perfil, identificadores e hardware estáveis continuam.
• Criar outra conta: separa perfis visíveis. No mesmo aparelho, o serviço ainda consegue observar que as duas contas compartilham o dispositivo.
• Nunca apertar Like: deixa de fornecer um sinal explícito. Tempo assistido, conclusão, repetição, busca, pausa, skip e sequência de telas continuam falando.
• Seguir fontes variadas: ajuda e vale a pena, mas até o feed “Seguindo” é ordenado. O TikTok diz que duas pessoas seguindo os mesmos criadores ainda recebem ordens diferentes.

Essas medidas podem reduzir exposição ou mudar recomendações. O erro é transformar mitigação em fantasia de invisibilidade.

Como usar sem terceirizar seu juízo

Se você decidiu continuar numa rede social, trate o feed como uma seleção interessada. Cada item foi escolhido porque algum modelo estimou uma reação. Verdade, relevância e equilíbrio são critérios diferentes.

Algumas práticas ajudam:

1. Use os controles reais da plataforma: “Não tenho interesse”, filtros de palavras, gerenciamento de temas e refresh do feed.
2. Pare de comentar por raiva. Bloqueie, denuncie quando for o caso e siga em frente. Engajamento indignado continua sendo engajamento.
3. Para notícias, abra a fonte original fora do aplicativo. Procure confirmação independente e confira data, autoria e contexto.
4. Misture fontes por decisão própria. Não espere que a exploração automática represente o contraditório de maneira honesta.
5. Separe diversão de informação. Um feed otimizado pra retenção é uma péssima redação jornalística.
6. Quando privacidade importar, isole a identidade. Como expliquei no artigo anterior, um perfil Android separado ou aparelho secundário reduz as pontes; spoofing aleatório costuma criar mais anomalias.

Também faça pausas. A personalização depende do loop contínuo de recomendação e reação. Sair do fluxo devolve a você a chance de escolher o próximo assunto, em vez de aceitar a próxima aposta do modelo.

Conclusão

O mecanismo cabe numa frase: a plataforma tenta reconhecer você, mede suas ações e usa o resultado pra escolher o próximo estímulo. Fingerprinting, telemetria e recomendação fecham esse ciclo.

Favoritar cachorro pode colocar mais cachorro no feed. VPN pode trocar seu IP. Reinstalar pode renovar IDs locais. Cada medida altera uma parte pequena e nenhuma concede imunidade.

O melhor sistema de defesa continua fora do aplicativo: desconfiar do conteúdo que encaixa bem demais nas suas crenças, conferir informação em fontes independentes e lembrar que relevância algorítmica mede a chance de uma reação. Verdade exige outro trabalho.

O algoritmo procura o assunto, o formato e o momento em que você para de questionar. A convicção de que você já venceu facilita exatamente esse trabalho.

Agora que eu tenho o REA, resolvi ir mais fundo. Peguei a versão 47.7.1, a mais recente, e dessa vez abri também o código nativo da pilha de rede no Ghidra. Tudo está no repositório tiktok_analysis, com os relatórios novos de 14 a 17 e as evidências linha por linha.

Este artigo é pra duas pessoas ao mesmo tempo: o usuário comum, que quer saber o que o app faz com ele, e o engenheiro de software, que quer saber se dá pra bloquear. E no final tem a parte que interessa a todo brasileiro.

O TikTok não trata todo mundo igual. O app separa os usuários por região, e Estados Unidos, Europa e Coreia do Sul ganham tratamento próprio. O resto do mundo cai num balde só, e o Brasil está nele, no grupo menos protegido. É por isso que, do jeito que está, o TikTok bate de frente com a LGPD e com a Lei Felca.

Tudo aqui vem de análise estática: eu li o código do app, não capturei o tráfego de um celular rodando. Isso prova o que o app foi construído pra fazer e pra onde ele foi construído pra mandar. Não prova byte a byte o que sai em cada requisição, porque a parte mais sensível é criptografada em código nativo.

Como foi feita, e como reproduzir

Na versão 46, o trabalho foi o jadx transformando o app em Java legível e o LLM lendo o código. O código nativo, as bibliotecas .so em C e C++, ficou só na varredura de strings.

Na 47, um agente rodou tudo sozinho:

• o jadx descompilou as 58 partes de código Java do app, umas 365 mil classes;
• o REA abriu as bibliotecas nativas no Ghidra e decompilou funções específicas, como o resolvedor de DNS próprio dentro da libsscronet.so;
• subagentes em paralelo varreram a árvore inteira, um por assunto (identificadores, fingerprint, servidores), devolvendo arquivo e linha de cada evidência.

Se você quiser refazer, ou aplicar o mesmo método em outro app, o relatório 11 tem o passo a passo, com os prompts prontos pro agente principal e pros subagentes e a sequência exata de ferramentas do REA.

O que o TikTok coleta, em português claro

Primeiro a boa notícia, porque ela é importante e muita gente erra aqui. O TikTok não espiona o resto do seu celular:

• não lê seus SMS, seu histórico de ligações, suas notificações, nem o que você digita em outros apps;
• não tem serviço de acessibilidade, que é o jeito que apps maliciosos usam pra ler a tela de outros apps;
• não lista todos os apps instalados;
• não pega IMEI, número de telefone nem endereço MAC.

O sandbox do Android impede, e o app não pede as permissões que contornariam isso. O relatório 10 verificou isso na árvore inteira, inclusive a área de transferência, que só é lida quando você cola algo. A única permissão nova do Android na versão 47 serve pra detectar quando alguém está gravando a tela do próprio TikTok.

A má notícia é o que ele coleta sem pedir nada, porque o Android não exige permissão pra isso. O relatório 14 tem o inventário completo. Resumindo:

• quem é o seu aparelho: vários identificadores persistentes, incluindo o ANDROID_ID, que sobrevive a limpar os dados e a reinstalar o app. E toda vez que você abre ou volta pro app, no máximo uma vez por hora, ele reenvia os principais identificadores, criptografados, pra um endpoint dedicado;
• o que o seu aparelho é: modelo, CPU, GPU, memória, a lista de sensores, a especificação completa de cada câmera (sem pedir permissão de câmera), os teclados instalados e os serviços de acessibilidade ativos;
• uma prova assinada pelo Google do seu aparelho: o app pede ao chip de segurança do celular uma atestação de hardware, que confirma o modelo, o estado do bootloader e o nível de patch. Isso não dá pra falsificar;
• como você segura e toca o celular: pressão e tamanho do toque em cada tela, e amostras de seis sensores de movimento (detalhes logo abaixo);
• onde você está, sem pedir localização: operadora, país do chip, fuso horário, idioma, os servidores de DNS do seu Wi-Fi e se você está usando VPN ou proxy;
• tudo o que você faz dentro do app: são mais de 6 mil tipos de evento diferentes, incluindo quanto tempo você assiste cada vídeo, o que você pesquisa, o que curte, quem visita.

Coisas que você nem imagina que são medidas

A lista acima já é grande, mas o detalhe impressiona mais. A sonda de risco do app sozinha tem cerca de 90 campos, e o motor de segurança nativo tem outra lista própria. Algumas das variáveis que o código lê, todas sem pedir permissão:

• cada toque na tela: a pressão, o tamanho da área de contato, o tipo de “ferramenta” (dedo, caneta), o dispositivo de entrada e o caminho completo do dedo, ponto a ponto, com o tempo de cada ponto. Isso descreve cada rolagem e cada deslizar, e é registrado em todas as telas do app. As teclas que você digita ficam de fora;
• como o celular se move na sua mão: acelerômetro, giroscópio, magnetômetro, gravidade, aceleração linear e rotação, além da orientação do aparelho calculada a partir deles. O app usa isso pra saber se tem um humano segurando o celular. Mas são exatamente esses os sinais que permitem dizer se você está andando, sentado, deitado ou dentro de um carro;
• o “tremor” do giroscópio e a variação do sensor de luz, ou seja, o quanto sua mão treme e o quanto a luz em volta muda;
• a bateria: nível, se está carregando, e um histórico das últimas 20 leituras mais ou menos;
• o volume da mídia, o modo avião e o estado do chip;
• se o microfone e a câmera têm permissão, mesmo quando você não está usando;
• quando o celular foi ligado pela última vez e há quanto tempo está ligado, o que permite juntar sessões mesmo depois de reinstalar o app;
• quais teclados e quais serviços de acessibilidade estão instalados;
• espaço em disco, memória, taxa de atualização da tela, modelo da GPU, criando um contexto gráfico só pra perguntar;
• se você está numa ligação ou com o microfone ativo em outro app, se o modo desenvolvedor está ligado, se tem cabo USB conectado.

E dentro do app, além do que você assiste, ele registra quanto tempo você fica em cada vídeo, quando você pausa, repete ou arrasta a barra de progresso, e o texto de cada busca.

Nenhum desses dados sozinho parece grave. Juntos, eles descrevem o seu aparelho, a sua mão e os seus hábitos com uma precisão que nenhum formulário de cadastro jamais pediria.

O que é fingerprinting, e por que isso é perigoso

Quase tudo da lista acima serve pra montar uma coisa chamada fingerprint, a impressão digital do dispositivo.

A ideia é simples. Nenhum dado sozinho identifica você: milhões de pessoas têm o mesmo modelo de celular, o mesmo fuso horário, a mesma operadora. Mas a combinação de dezenas desses sinais é tão específica que vira praticamente única. É um número de série que você nunca autorizou e nem sabe que existe.

O que torna isso valioso, e perigoso, é a persistência:

• um cookie você apaga;
• o identificador de anúncio você reseta;
• o fingerprint sobrevive a limpar os dados e a reinstalar o app. Só um reset de fábrica troca o ANDROID_ID, e mesmo assim o modelo, os sensores e a atestação continuam descrevendo o mesmo aparelho.

O servidor ainda pode reemitir o mesmo identificador de dispositivo quando reconhece os outros sinais. No mesmo aparelho e no mesmo perfil, recomeçar do zero é muito difícil.

Por que isso é nefasto

O problema não é só anúncio. Um identificador que não morre permite:

• juntar tudo: o que você assiste, pesquisa e curte vira um perfil ligado ao aparelho, que sobrevive mesmo se você apagar a conta;
• cruzar entre apps: o TikTok tem um endpoint específico pra ligar os identificadores do seu aparelho entre os apps da ByteDance, como CapCut e Lemon8;
• reidentificar você: se você apaga a conta e cria outra no mesmo celular, a plataforma tem como saber que é o mesmo aparelho, porque o ANDROID_ID é o mesmo;
• inferir o que você não contou: o que você assiste e por quanto tempo pode revelar interesses, estado emocional, orientação, religião, política. E você não tem como ver nem corrigir esse perfil.

E tem o agravante que já apareceu na análise de julho: o fingerprint é montado e criptografado em código nativo, dentro da biblioteca libmetasec_ov.so (o relatório 13 mostra o que dá pra ler dela). Nem descompilando o app inteiro dá pra saber exatamente o que vai nele. Na versão 47, as strings dessa biblioteca parecem ainda mais criptografadas que na 46.

Você não consegue auditar, não consegue apagar, e no mesmo aparelho é muito difícil recomeçar. Esse é o ponto central.

Dá pra bloquear? A parte pros engenheiros

A minha primeira ideia foi a óbvia: bloquear os servidores de telemetria no meu DNS, o NextDNS, ou modificar o app pra tirar a coleta. Pedi pro agente estudar as duas opções a fundo. Nenhuma das duas resolve.

Por que bloquear no DNS não funciona

Bloquear por DNS (NextDNS, Pi-hole, AdGuard) funciona assim: o app pergunta “qual o IP de log.tiktokv.com?” e o seu DNS responde “nenhum”. Só que o TikTok foi construído pra não depender do seu DNS:

• ele tem o próprio resolvedor de DNS, ligado por padrão, e chega nele por IP direto (34.102.215.99 fora dos EUA). Quando o app usa esse resolvedor, o seu DNS não vê a consulta, e quem decide quando usar é o servidor;
• os servidores principais da API estão fixados em IPs da própria ByteDance, cravados no código;
• o servidor pode reescrever as rotas a qualquer momento: na abertura, o app baixa uma lista de regras que pode mandar qualquer endereço pra outro, ou fixar qualquer nome num IP;
• os IPs de resolvedor de reserva ficam salvos no celular, então um IP aprendido uma vez sobrevive ao bloqueio que você fizer depois;
• as estatísticas de cada vídeo assistido viajam no mesmo servidor do feed. Uma regra embutida força isso. Se você bloquear, o feed para junto.

Dá pra reduzir bastante. O relatório 14 tem uma lista de bloqueio em camadas e as regras de firewall pro roteador que fecham o resolvedor próprio. Isso corta rastreadores de terceiros, uploads de log e crash, o reenvio de identificadores de hora em hora e boa parte do fluxo de eventos. Mas não esconde do TikTok o que você assiste, e o servidor pode mudar as rotas na próxima atualização.

Por que modificar o app também não funciona

A segunda ideia era reempacotar: descompilar, transformar os coletores em código morto, reassinar e instalar. O relatório 15 estudou isso, e esbarra em três paredes:

1. o fingerprint é o assinador das requisições. A mesma biblioteca nativa que monta o fingerprint assina todas as chamadas à API. Se você tira um, perde o outro, e o servidor rejeita a requisição sem assinatura. O feed para;
2. a sua assinatura entra na assinatura do aparelho. O código nativo lê o certificado com que o app foi assinado. Reassinar com a sua chave muda isso, e o servidor sabe que você roda um cliente modificado. Pode responder com captcha, verificação de telefone ou conta limitada, quando quiser;
3. a configuração vem do servidor. Rotas, regras de DNS e listas de eventos são baixadas em tempo de execução, então um patch estático só muda os valores padrão.

Dá pra remover a telemetria “de luxo” na fonte: o reenvio de identificadores, o AppsFlyer, o Firebase Analytics, os uploads de crash. Mas não o fingerprint nem o seu comportamento, e você entra numa esteira de refazer o patch a cada atualização do TikTok.

Falsificar também não

E falsificar os dados piora.

O app verifica root, Magisk, Xposed, Frida, emulador, localização falsa, bootloader destravado e modo desenvolvedor. A atestação de hardware assinada pelo Google denuncia qualquer modelo falsificado. Os sensores de toque e movimento existem justamente pra detectar valores sintéticos. O relatório 8 explica por que cada tentativa de falsificar sai pela culatra. Falsificar coloca você no balde de “aparelho adulterado”, e o fingerprint sai do mesmo jeito.

A única saída hoje: isolar

Se não dá pra esconder o comportamento de quem te entrega o feed, o objetivo muda: fazer com que esse comportamento fique ligado a uma identidade descartável, que não leva até você. Isolar, sem falsificar nada. Tem dois jeitos:

Um celular secundário

Um aparelho barato, ou um tablet, só pro TikTok:

• sem chip, ou só no Wi-Fi: os campos de operadora e país do chip vão vazios, o que é normal em tablet;
• sem login, ou com um e-mail que você não usa em nenhum outro lugar. Nada de entrar com Google, Facebook ou número de telefone;
• sem permissões: negue localização, contatos, fotos, microfone e câmera;
• ID de anúncio apagado, em Configurações → Privacidade → Anúncios;
• na rede, a lista de bloqueio e as regras de roteador do relatório 14.

Prós: é a separação mais completa. Tudo o que o fingerprint descreve é aquele aparelho, e nada é falsificado, então nada contradiz a atestação. O CapCut e os outros apps da ByteDance ficam longe da sua vida real.

Contras: custa um aparelho, é mais um equipamento pra carregar e atualizar, e é menos prático. E o que você assiste continua sendo registrado, só que preso a uma identidade que não é a sua.

Um perfil separado no mesmo celular

O Android permite um espaço isolado: o Espaço Privado no Android 15 ou mais novo, ou um perfil de trabalho com apps como Shelter ou Island. O TikTok vai lá dentro, com as mesmas regras de sem login e sem permissões.

Prós: custo zero. Cada perfil tem o próprio ANDROID_ID, o app não enxerga seus contatos, fotos e outros apps, e nada é falsificado.

Contras: o hardware é o mesmo. O fingerprint de hardware, a atestação e o chip do seu celular continuam iguais, então quem quiser cruzar consegue ligar o perfil ao aparelho. Isola bem os identificadores de software, mas o aparelho continua o mesmo.

Não existe configuração que faça o TikTok parar de saber o que você assiste. O que existe é garantir que esse “você” seja uma identidade descartável.

O brasileiro é o usuário menos protegido

Aqui fica pior pra gente. O relatório 16 mostra que o app separa todo usuário em cinco regiões de compliance:

• US: Estados Unidos;
• EU: Europa, no caso o Espaço Econômico Europeu;
• KR: Coreia do Sul, por causa da lei de proteção de dados de lá;
• ROW: “rest of world”, o resto do mundo. O Brasil cai aqui;
• UNKNOWN: ainda não determinado.

O que muda entre elas:

O que cada modo coleta exatamente fica dentro do código nativo criptografado, então não dá pra medir a diferença byte a byte. Mas a estrutura é clara: o caminho com freio regulatório foi escrito pros EUA e pra Europa, e o Brasil cai no padrão. A Coreia pelo menos ganhou o próprio balde no código; o Brasil, com uma lei inspirada na GDPR, não ganhou nem isso.

E não adianta trocar a região da loja do Google pra Europa. O balde vem da região da conta TikTok, que o servidor define, e forçar divergências tende a virar sinal de fraude.

LGPD e Lei Felca: por que o TikTok precisa se adequar

O relatório 17 cruza essas descobertas com a lei. Vale a ressalva: quem decide se houve infração é a ANPD e a Justiça, olhando também a política de privacidade, as telas de consentimento e o que acontece no servidor. A análise do app mostra onde ele bate de frente com a lei.

LGPD

A Lei Geral de Proteção de Dados tem princípios que o app tem dificuldade de cumprir:

• necessidade (art. 6º): coletar só o necessário pra finalidade. Reenviar os principais identificadores a cada hora, uma sonda de cerca de 90 campos sobre root e hardware, toque e sensores de movimento, tudo isso vai muito além do que assistir vídeo curto exige;
• transparência (arts. 6º e 9º): o titular tem direito a saber o que é coletado. Com o fingerprint criptografado em código nativo, o usuário não tem como saber, e nem descompilando o app dá pra ver;
• direitos do titular (art. 18, IV e VI): eliminação de dados desnecessários ou excessivos, e dos dados tratados com consentimento. Um identificador que sobrevive à limpeza e à reinstalação, e que o servidor pode reemitir ao reconhecer o aparelho, esvazia esse direito na prática;
• transferência internacional (art. 33): sem infraestrutura dedicada pro Brasil, os dados vão pra infraestrutura global da ByteDance;
• dados de crianças (art. 14): o app tem um Modo Infantil que apaga identificadores e zera o ID de anúncio, mas ele só vale se o app souber que o usuário é criança. O caminho padrão perfila todo mundo.

Esse último ponto não é teoria. A ANPD já abriu processo contra o TikTok em novembro de 2024 por tratar dados de crianças e adolescentes sem verificação de idade, e mandou desativar o acesso ao feed sem cadastro no Brasil.

Em agosto de 2026 veio a conta: a ANPD multou a ByteDance em R$ 153,7 milhões por tratar dados de crianças e adolescentes, dizendo que a empresa “aceitou o risco de realizar o tratamento massivo de dados pessoais de crianças e adolescentes”. O feed sem cadastro continua existindo, mas dentro de um plano de conformidade, sem anúncios e com a coleta limitada.

Lei Felca (ECA Digital)

A Lei 15.211/2025, o ECA Digital, ganhou o apelido de Lei Felca por causa dos vídeos do influenciador Felca sobre adultização de crianças na internet, que empurraram o projeto em 2025. Está em vigor desde março de 2026 e exige das plataformas, entre outras coisas:

• verificação de idade confiável, que não seja só autodeclaração;
• contas de menores de 16 anos vinculadas a um responsável;
• proibição de publicidade direcionada com dados de crianças;
• proteção desde o design.

A maior parte disso acontece no servidor, então a análise do app não prova nem cumprimento nem infração. O que ela mostra: a ferramenta pra proteger dados de crianças existe no código (o Modo Infantil), mas depende inteiramente de o app saber quem é menor. E é exatamente aí que a ANPD já apontou falha.

Se adequar ou sair

Juntando tudo:

• o app tem tratamento regulatório pros EUA e pra Europa, e nada pensado pro Brasil (a única minimização que vale aqui é o Modo Infantil, que é igual em todo lugar);
• os dados dos brasileiros não têm infraestrutura dedicada;
• o fingerprint não é auditável nem apagável;
• a proteção de menores depende de uma verificação de idade que o regulador já considerou fraca.

A ByteDance sabe fazer diferente: fez pros americanos e pros europeus, porque lá foi obrigada. Nos EUA, a obrigação foi tão longe que a operação americana virou uma joint venture separada. O Brasil tem uma lei de proteção de dados no mesmo espírito da GDPR e agora uma lei específica pra crianças.

O TikTok precisa tratar o usuário brasileiro como trata o europeu: com infraestrutura dedicada, minimização de verdade e verificação de idade que funcione. Se não fizer isso, não deveria poder operar aqui.

Enquanto isso não acontece, a proteção fica nas suas mãos. Se for usar, use num aparelho ou perfil isolado, sem login e sem permissões. E se tem criança em casa com TikTok no celular, agora você sabe o que está sendo coletado.

Depois de fazer esses launchers pra trazer de volta os meus jogos favoritos, eu quis que mais gente pudesse fazer o mesmo com os jogos deles. Pra isso, juntei tudo num framework: o rea-launcher-sdk.

Este artigo conta como ele nasceu, e por que eu fiz na ordem que fiz.

Primeiro os apps, depois o framework

Muito amador pensa do jeito errado: primeiro você desenha um framework novo e bonito, e depois constrói aplicações em cima dele. Esse é o caminho completamente errado pra fazer biblioteca ou framework.

O caminho certo é o contrário:

1. implementar vários projetos do mesmo tipo, cada um resolvendo o seu problema de verdade;
2. avaliar todos eles juntos, comparando o que cada um fez;
3. normalizar com refatoração, até todos terem a mesma fundação comum;
4. só então extrair as partes comuns pra um framework de verdade.

O Rails nasceu assim, extraído do Basecamp. Framework desenhado antes do primeiro app sempre resolve o problema que o autor imaginou, e erra o que aparece na prática.

Você só sabe o que é comum depois de ver a mesma coisa feita três, quatro, cinco vezes. Antes disso, é chute.

Foi o que eu fiz aqui. A diferença é que dessa vez cada passo foi feito com LLMs.

Os launchers antes do SDK

Todos os launchers foram feitos com agentes, e eu usei vários: Claude, Codex, Antigravity e outros. O que mais tomou meu tempo foi o primeiro, o do Colin McRae 1. Ele começou em 20 de outubro e hoje tem quase 800 commits, porque foi nele que eu descobri o que um launcher desses precisa ter, junto com o recomp e o pacote de texturas HD.

Pros outros, bastava dizer algo como “copie tudo do rea-colin-mcrae e adapte pro jogo X”. Isso acelerou muito os seguintes. O problema é que cada agente copiou e adaptou do seu jeito, e no fim cada launcher estava pra um lado.

A auditoria que o agente do SDK fez depois mostrou o tamanho da bagunça. Cada bug encontrado existia em uma ou mais cópias, e já estava corrigido em outra:

• o launcher do Colin McRae 3 tinha uma conversão do executável que nunca rodava, porque o caminho do programa era passado duas vezes na linha de comando;
• o do Screamer criava a cópia privada com links simbólicos pra pasta original, então o jogo podia escrever na instalação do usuário;
• o do Sega Rally escrevia "Disable Hidraw", com espaço, numa chave que o Wine lê como DisableHidraw;
• o do OutRun copiava saves sem checar qual era o mais novo, e o comando de parar matava o shell auxiliar em vez do jogo;
• três launchers montavam um script interpolando o caminho do launcher sem escapar as aspas.

Umas 2 mil linhas de código se repetiam em cada launcher, cada cópia com os seus próprios bugs.

Extraindo o SDK

Quando eu achei que tinha material suficiente, criei o rea-launcher-sdk e pedi pro Claude fazer exatamente o que eu prego: estudar cinco dos sete launchers que eu tinha até ali (o Colin McRae 1 e o DiRT entraram depois), normalizar, extrair o que era comum e montar um framework de verdade, com as minhas técnicas de engenharia de software embutidas em forma de skills.

O primeiro commit, às 10h50 de hoje, diz “SDK inicial extraído dos cinco launchers rea”. Cada peça é a melhor versão entre as cinco cópias, e um documento de auditoria registra de qual launcher veio cada uma. A cópia privada veio de um, a instalação de DLLs de outro, e o hook de fechar janela, que entrou na 0.3.0, veio do Colin McRae 04.

O que ficou no SDK:

• o núcleo portátil (rea-launcher): cópia privada do jogo, espelho de saves, identificação do executável por SHA-256, patches binários declarativos, a tabela de opções, edição de INI, downloads com hash fixo;
• a camada Windows (rea-launcher-win32): registro, processos, instância única, mensagens de erro, detecção de GPU e de Wine;
• a interface (rea-launcher-ui): a janela de configurações em egui, com tema, checagem de contraste e testes da interface sem tela;
• o hook de fechar (rea-launcher-close-hook): uma DLL que transforma o Alt+F4 ou o botão de fechar no caminho de saída do jogo, configurável sem recompilar;
• o lado Linux: uma biblioteca de shell pro script de jogar com gamescope e Wine, e o empacotamento em AppImage;
• a CI: workflows reutilizáveis de build, testes, checagem de importações e release, e um workflow semanal que abre um pull request quando sai versão nova do SDK.

O que não foi extraído é o conhecimento de cada jogo: qual byte patchear, qual chave de registro escrever, qual community fix usar. Isso continua em cada launcher, e o SDK recebe como dado.

De 0.1 a 0.3 em umas quatro horas

A primeira versão saiu às 11h07, depois de uma revisão completa do próprio SDK. A 0.3.3 saiu às 15h12. Entre uma e outra, o ciclo foi sempre o mesmo:

1. migrar os launchers pra versão nova do SDK;
2. a migração expõe um bug ou uma lacuna no SDK;
3. o SDK corrige e solta outra versão;
4. os launchers sobem de versão de novo.

Alguns exemplos do que esse ciclo pegou:

• Flags no formato --chave=valor. A tabela de opções nova parou de aceitar esse formato, que os scripts dos launchers usavam. A 0.3.2 trouxe de volta, com teste.
• Erros invisíveis no Wine. Os scripts de Linux, o AppImage e o Proton mandam a saída pra um log, então o SDK achava que tinha terminal e não mostrava o erro pro jogador. A 0.3.2 criou um relatório que decide quem precisa ver a mensagem.
• DLL reescrita a cada partida. O Sega Rally reescrevia uns 70 MB de DLLs em toda execução. O SDK passou a pular arquivos idênticos.
• O Wine ignora WINEDLLOVERRIDES. O teste no jogo real do Sega Rally mostrou que o Wine carregava a DLL embutida dele no lugar da DLL da Microsoft que estava na cópia privada. A 0.3.3 passou a escrever os overrides no registro do Wine, por programa, e cinco launchers adotaram.

E a migração também achou bugs específicos de cada launcher, que só apareceram quando todos foram forçados pro mesmo padrão:

• o linker do GNU binutils 2.47 deixava importações do kernel32 fora da tabela; no Screamer eram 53, e o launcher crashava antes do main. Virou regra do SDK linkar com o lld e checar as importações na CI;
• no Colin McRae 3, desmarcar uma opção de imagem apagava a escolha que o jogador tinha feito no menu do jogo;
• no Colin McRae 04, abrir o launcher de novo encontrava a janela do próprio jogo, ou até uma pasta do Explorer com o mesmo nome, e saía em silêncio;
• no Sega Rally, o menu em polonês aparecia em inglês, e os saves vazios que o launcher criava faziam o jogo acusar dados corrompidos.

Teve até bug gerado pelo próprio processo. O snapshot de teste do --help incluía o número da versão, então o commit de release mudava a versão e quebrava o build da tag. As releases 0.2.0 do Colin McRae 3, 0.3.0 do 04 e 0.2.0 do OutRun foram marcadas e nunca publicadas, e saíram corrigidas minutos depois.

No fim, os sete launchers estavam no SDK, todos verdes, com releases novas. Além de compartilharem a mesma camada, ficaram mais corretos do que eram antes.

As técnicas embutidas

O SDK tem um documento de padrões com umas 540 linhas, e a maioria das regras veio de bug real que apareceu nos launchers. As principais:

Teste antes da correção

Toda correção de bug começa com um teste que falha no código antigo. Depois o agente reverte a correção temporariamente pra confirmar que o teste falha mesmo sem ela, porque vários “testes de regressão” passavam dos dois jeitos.

Outras regras de teste:

• testar o comportamento: o bug do xdelta no Colin McRae 3 sobreviveu porque o teste unitário conferia a lista de argumentos errada. Onde existe ferramenta real, testa contra ela;
• testar a fiação inteira: opção → launcher.cfg → arquivo do jogo, registro e ambiente, de ponta a ponta;
• testes como história do jogador: “o jogador restaura um backup antigo de save”, “a sessão é morta antes de copiar os saves de volta”, “abre o launcher de novo com o jogo rodando”;
• entradas hostis: caminhos com espaço, apóstrofo e acento (José/Jogos d'Ação), arquivo em code page do Windows, CRLF, BOM, arquivo truncado;
• código de Windows roda com semântica de Windows: os testes do alvo Windows rodam dentro do Wine, sem tela. Quatro bugs do SDK só apareceram assim.

Snapshots dourados

Cada launcher guarda snapshots de tudo o que produz: o --help, o launcher.cfg gerado, e pra cada perfil visual os arquivos de configuração do jogo, os valores de registro, as variáveis de ambiente e os patches que ele aplicaria. Se uma atualização do SDK muda qualquer byte disso, o teste quebra, e a mudança é revisada como código.

Sem tela por padrão

Testes, sondas e até o jogo real rodam headless: o gamescope sem saída de vídeo, um sink de áudio nulo do PipeWire e um prefixo Wine descartável. A evidência vem de log, código de saída, tabela de processos, arquivos escritos e screenshots capturados sem monitor.

Uma janela só abre quando precisa de um humano, como julgar a aparência da interface ou testar um controle. E o agente avisa antes: o que vai abrir, por quê e o que olhar.

CI que pega o que o humano esquece

A CI de cada launcher roda formatação, lint, os testes do alvo Windows dentro do Wine, a checagem de importações, auditoria de dependências e o empacotamento. A release só sai com a CI verde, gera SHA256SUMS e atestado de proveniência, e as notas vêm direto do CHANGELOG.

Código de IA não precisa ser slop

Tem muita gente que olha código gerado por IA e assume que é “AI slop”: funciona no exemplo, quebra no resto, e ninguém sabe por quê. Isso acontece quando a pessoa pede código e aceita o que vier.

Com as técnicas certas, acontece o contrário. Eu diria que o código que eu gero com IA hoje é muito superior ao do desenvolvedor humano médio, que ainda briga contra escrever teste direito por preguiça.

Eu medi. Rodei a suíte de testes e a cobertura de linhas de cada projeto, no Linux:

São mais de 1.200 testes, todos passando, e nove dos dez projetos com 85% ou mais de cobertura. Pra cada duas linhas de código de produção, tem mais ou menos uma de teste.

A cobertura é só do que compila no Linux. O código exclusivo de Windows, como a DLL de hooks do Colin McRae 1, fica de fora da conta, e é testado na CI rodando os testes do alvo Windows dentro do Wine. O Screamer é o mais baixo: a configuração, a cópia privada e os hooks dentro do emulador ficam abaixo de 75%.

Os números sozinhos não contam a história. O que conta é o tipo de bug que esses testes pegaram.

O teste que passava errado

No Colin McRae 3, a conversão do executável pra versão sem DRM nunca acontecia, em silêncio. O launcher montava os argumentos do xdelta repetindo o caminho do programa, e o xdelta recebia xdelta.exe xdelta.exe -f -d -s ….

O teste unitário passava, porque conferia exatamente essa lista errada. A auditoria do SDK rodou o xdelta3 de verdade e tomou “too many filenames”. A correção veio com um teste novo que gera um patch minúsculo com o xdelta3 real, aplica com os argumentos do launcher e compara os bytes.

Daí saiu uma das regras do SDK: testar o comportamento, com a ferramenta real sempre que ela existir.

A correção “segura” que perdia saves

No Colin McRae 3, depois de um crash, o launcher restaurava o save antigo por cima do novo. A correção foi “o mais novo ganha”, e a auditoria achou tão boa que levou pro OutRun e pro Screamer na mesma manhã.

Só que “o mais novo ganha” joga fora o backup antigo que o jogador restaurou de propósito, e os saves trazidos de outro PC com data velha. Em 20 minutos, os três launchers trocaram a regra por um registro do estado da última sincronização. Os testes têm nome de história: a_restored_older_backup_wins, a_session_killed_before_saving_is_recovered.

Um revisor independente pegou o problema, e foi por causa dele que o SDK passou a exigir testes escritos como histórias do jogador.

O checklist que marcou FAILED

No Sega Rally, a verificação no jogo real tinha um item: “o WINEDLLOVERRIDES chega no jogo”. Ele ficou marcado como FAILED. O launcher registrava os overrides no log, mas com WINEDEBUG=+loaddll dava pra ver o jogo carregando a DLL embutida do Wine.

O WINEDEBUG=+module mostrou duas causas. O Wine troca pela versão dele qualquer DLL que se identifique como da Microsoft no recurso de versão, mesmo na pasta do programa, e ignora o WINEDLLOVERRIDES colocado só no ambiente do processo filho. A correção foi pro SDK, com um teste que prova o bug (env_block_overrides_do_not_reach_wine), e cinco launchers adotaram. Sem a regra de verificar no jogo real, ninguém teria notado: o log dizia que estava tudo certo.

Duas correções erradas antes da certa

No Screamer, chegar na tela de título não provava nada. Uma execução headless trocando a prévia das pistas reproduziu o crash real: mipmap cannot span 2 Mbyte boundary.

A primeira correção tratou um caminho que nunca acontecia. A segunda causou o mesmo erro sozinha e foi revertida. A terceira, depois de ler a desmontagem, achou um jle com sinal que deixava passar uma textura terminando exatamente no limite, mais dois caminhos que pulavam a checagem. A correção final troca um byte (jle vira jl) e anula os dois desvios, com um teste que confere os três pontos.

Errar de primeira é normal, pra humano e pra IA. O que muda é que o agente só faz commit quando o jogo confirma, e o teste garante que o erro não volta.

Agentes que jogam o jogo

O que mais acelerou tudo isso é que os agentes têm acesso pra rodar o jogo de verdade. Eles aplicam o patch, abrem o jogo num gamescope headless, conferem o resultado no log e na captura de tela, e só fazem commit quando tudo está confirmado funcionando.

Isso economiza horas, às vezes dias, de teste manual. Eu não preciso abrir o jogo a cada tentativa de patch, só nos pontos em que o meu olho ou a minha mão no controle fazem diferença.

E quando o jogo crasha, fica um dump. O agente abre no gdb ou no winedbg, acha a instrução que falhou e chega na causa com uma precisão que eu raramente tinha quando fazia isso na mão, anos atrás. Três exemplos:

• OutRun 2006: o launcher crashava logo depois de copiar os saves. O winedbg com símbolos colocou a falha numa chamada a GetModuleHandleW cujo slot na tabela de importação não pertencia a nenhum descritor, então o loader nunca preencheu. A causa era o linker do binutils 2.47 do meu toolchain, e a correção foi trocar pro lld.
• Colin McRae Rally 2005: o jogo crashava na abertura no Wine, num endereço dentro da rotina que mede a largura do texto. Ela lia o cabeçalho da fonte antes de checar se a fonte tinha carregado, e a fonte nunca carregava porque o jogo monta os caminhos a partir de chaves de registro que só o instalador escreve. Existia um bug no Wine com o mesmo crash, que sumiu reinstalando o jogo e acabou fechado sem explicação.
• DiRT Rally: o port de Linux de 2017 crashava logo depois de iniciar o SDL em processadores novos. O jogo mapeia memória só com permissão de execução e depois lê dela. Em CPUs com Memory Protection Keys (Ryzen com Zen 3 ou mais novo, Intel a partir da 11ª geração), o kernel torna essa memória realmente só de execução, e a leitura falha. O problema já era conhecido na comunidade, e a correção do launcher é uma bibliotequinha própria em Rust que intercepta o mmap e o mprotect e adiciona permissão de leitura, sem mexer no jogo.

Testando o SDK com dois jogos novos

Com tudo verde, chegou a hora de testar o SDK de verdade: dois launchers novos, do zero, o do Colin McRae Rally 2005 e o do DiRT Rally. Dessa vez eu só precisei dizer “use o rea-launcher-sdk e crie um launcher novo pro jogo X”.

O agente seguiu o playbook: pesquisa primeiro, depois o scaffold gerado pelo script new-launcher do SDK (66 arquivos e quase 11 mil linhas de partida), depois a implementação em passos, a verificação no jogo real e a release.

Claro que cada jogo teve as suas peculiaridades, e precisou de teste manual, prompt extra e intuição minha.

Colin McRae Rally 2005

• o crash da abertura, explicado acima, resolvido escrevendo as chaves de registro a cada início;
• o instalador da GOG trava no Wine, então o launcher desempacota os arquivos do instalador com o innoextract e nunca roda o instalador;
• com o renderizador do Wine, uma etapa rodava a 20 fps; com o DXVK, passou de mil;
• um monitor principal em retrato fazia o jogo parar com “Adapter has no modes!”, e a chave de desktop virtual por programa do Wine é ignorada no Wine 11. A solução foi abrir o jogo num desktop virtual do tamanho do monitor em paisagem;
• num prefixo Wine novo, a janela do launcher não abria, porque o Wine só lê a configuração de EGL quando o processo começa. O launcher agora troca pra GLX e reinicia a si mesmo.

Os dois últimos só apareceram quando eu joguei no meu desktop, com o meu monitor em retrato e o meu Hyprland. Nenhum teste headless pegaria isso.

DiRT Rally

• o crash de processador novo, explicado acima;
• as bibliotecas antigas que o Linux de hoje não tem mais (OpenSSL 1.0, libidn11, librtmp, OpenLDAP 2.4, GConf) vêm de pacotes fixos do Steam Runtime, e só o jogo enxerga, porque vazar elas pro gamescope derruba o gamescope;
• a janela de pré-jogo da Feral: as flags óbvias de preferência não funcionaram. O agente decompilou a decisão com o REA e achou as duas chaves certas. Pular a janela sem escrever a resolução derrubava o jogo, então o launcher escreve as duas coisas;
• os controles levaram três tentativas. O meu 8BitDo Ultimate 2 aparecia como joystick genérico. A primeira correção, via variável do SDL, fez o controle sumir. A causa real era uma lista própria de controles da Feral, dentro do jogo, e o launcher agora adiciona os controles de layout padrão nela.

O DiRT Rally também expôs a maior premissa escondida do SDK: ele foi feito pra executável de Windows rodando no Wine. O DiRT Rally é um binário nativo de Linux, então faltava janela de erro nativa, trava de instância única no Unix, progresso na cópia de 40 GB e leitura de controle no Linux pra janela do launcher. O agente escreveu tudo isso no próprio launcher primeiro, e depois isso subiu pro SDK.

Os números

Comparando os commits e as horas de sessão (somando os intervalos entre commits) até cada launcher chegar no padrão do SDK:

Os números dos antigos incluem a primeira versão, as correções e a migração pro SDK, e a migração sozinha foi uns 35 a 50 commits de cada um. O DiRT tem pouco commit porque quase todo o trabalho dele foi feito antes do primeiro commit.

O Colin McRae 2005 já nasceu com tudo: testes, snapshots, CI, README no padrão, formulários de issue, releases com hash. O DiRT Rally saiu sem os snapshots dourados, ganhou logo depois da release, e essa falha virou regra no SDK (mais abaixo). Os números de teste e cobertura dele na tabela anterior são de depois da release.

A maioria dos launchers antigos precisou de 70 a 90 commits e de 8 a 18 horas pra chegar no padrão. Os dois novos chegaram lá na primeira release, ou quase, com menos de 20 commits e umas 4 horas cada, feitos em paralelo na mesma tarde e noite.

Menos commit significa menos ida e volta. O agente acertou mais de primeira porque o SDK já tinha resolvido o que os outros launchers precisaram descobrir apanhando.

O SDK aprende com os launchers novos

Depois que os dois saíram, eu voltei pro agente do SDK e pedi pra ele avaliar os dois: ajustar o que precisasse neles, e aprender o que desse pra trazer pro framework. É a mesma regra de antes: só vira framework o que já apareceu em projeto real.

O resultado foi a versão 0.4.0. O que ela trouxe:

• do DiRT Rally: trava de instância única pra launcher nativo de Linux, janela de erro nativa, cópia com progresso, leitura de controle no Linux;
• do Colin McRae 2005: a troca pra GLX com reinício num prefixo novo, paletas claras com contraste certo, e um modo novo no hook de fechar pra jogos que tomam o teclado em modo exclusivo do DirectInput, onde o Alt+F4 nunca chega;
• de vários: o tamanho do gamescope por perfil visual, que o Colin McRae 1, o 2005, o 04 e o OutRun tinham reimplementado cada um no seu hook;
• do bug das releases: um helper de snapshot que nunca grava o número da versão.

E o que veio dos dois launchers novos já vai beneficiar os antigos também. O OutRun, o Colin McRae 1 e o 04, por exemplo, vão poder apagar o código próprio que dimensionava o gamescope e usar o do SDK, e vários ganham a janela de erro certa, a segunda execução tratada do mesmo jeito e a remoção segura dos overrides de DLL. É o ciclo fechando: o projeto novo ensina o framework, e o framework melhora os projetos velhos.

E veio uma ideia nova: um verificador de conformidade, o launcher-check, que roda na CI de cada launcher e falha o build quando um launcher repete um erro conhecido. São 33 regras, e cada uma explica por que existe e como corrigir. Um erro que apareceu em um launcher e que dá pra detectar olhando os arquivos vira regra. Por exemplo, “o DiRT Rally saiu sem snapshots” virou uma.

O playbook de launcher novo também ganhou seções de padrões: port nativo de Linux, os ports antigos da Feral, instalador da GOG com innoextract, monitor em retrato com desktop virtual.

Nenhum software está “pronto”. Mas eu acredito que o SDK já é bom o suficiente: foi testado em batalha com nove launchers e onze jogos de verdade, e qualquer pessoa pode começar a usar.

Feito pra ser usado por IA

O SDK foi desenhado AI-first. O README diz isso logo no começo: ele foi escrito pra ser dirigido por um agente de código. O agente faz a pesquisa, a engenharia reversa e o código; você entra com o jogo e com as decisões.

E não precisa ser o Claude. A estrutura funciona com o agente que você preferir, seja Claude Code, Codex, opencode ou Cursor:

• AGENTS.md é a porta de entrada pra qualquer agente: uma tabela de “tarefa → playbook” e as regras fáceis de esquecer. O CLAUDE.md só aponta pra ele;
• os playbooks são Markdown puro: launcher novo, patch binário, componentes da comunidade, CI e releases, mudanças no SDK, contribuir de volta, e o modelo de README;
• docs/STANDARDS.md são as regras obrigatórias, e cada launcher recebe uma cópia delas;
• as skills do Claude (rea-new-launcher, rea-sdk-change, rea-contribute-back) são só ponteiros finos pros playbooks, pra quem usa Claude Code.

Algumas regras que o agente segue sem você precisar lembrar:

• nunca distribuir arquivos do jogo, e nunca modificar a pasta do jogo;
• identificar cada executável pelo SHA-256 e nunca patchear uma versão desconhecida no chute;
• pesquisar os fixes da comunidade antes de escrever código;
• registrar as decisões do dono do projeto, com data;
• não publicar nada, nem push, nem release, nem post em fórum, sem aprovação.

Como fazer o launcher do seu jogo favorito

Se você tem um jogo antigo que não roda mais direito, o caminho é este.

1. Prepare as ferramentas. Clone o SDK e instale o REA no seu agente:

git clone https://github.com/akitaonrails/rea-launcher-sdk ~/Projects/rea-launcher-sdk
npx rea-agents setup                                  # REA, o MCP de engenharia reversa
~/Projects/rea-launcher-sdk/scripts/install-skills    # só pra Claude Code

Você também precisa do toolchain: Rust com os alvos de Windows, MinGW, lld, Wine, gamescope e mais algumas ferramentas que o README lista. O jeito mais fácil é usar um container que já tenha tudo, como o meu distrobox-gaming.

2. Tenha o jogo instalado. A sua própria cópia, numa pasta que o agente possa ler. Ela nunca é modificada, nem copiada pro repositório.

3. Peça pro agente. Abra o agente numa pasta vazia e cole um prompt como este, adaptado do README:

Crie um novo launcher rea para Need for Speed: Porsche Unleashed (PC, 2000) usando o SDK em ~/Projects/rea-launcher-sdk. Leia o AGENTS.md, o docs/STANDARDS.md e o docs/playbooks/new-launcher.md e siga o playbook fase por fase. O jogo está instalado em /mnt/games/NFSPU (só leitura, nunca copie pro repo). Use as ferramentas MCP do REA pra analisar. Pesquise os fixes da comunidade primeiro e me mostre o que encontrou antes de escrever código. Mantenha os testes headless. Não faça push nem publique nada sem me perguntar.

Com o Claude Code e as skills instaladas, “faça um launcher rea pro jogo X em /caminho” já basta.

4. Revise nos pontos de checagem. O playbook para em quatro momentos pra você decidir:

1. o que a pesquisa encontrou;
2. a lista de problemas que o launcher vai resolver;
3. as opções que a janela vai oferecer;
4. o que foi verificado no jogo real, registrado no docs/RUNTIME_NOTES.md.

Entre eles, o agente segue as fases: conhecer o jogo com o REA, gerar o scaffold, construir em ordem (edição do jogo, cópia privada, componentes, configuração, patches, perfis visuais, janela, linha de comando, script de Linux, empacotamento), e verificar com os testes e com o jogo real rodando headless.

5. Jogue. Essa parte é sua. É jogando no seu PC, com o seu monitor e o seu controle, que aparecem os bugs que nenhum teste pega.

6. Publique. Quando você aprovar, o agente faz o push, e a release sai pela CI com o AppImage pra Linux, o zip pra Windows e os hashes. O playbook ainda tem uma fase de contribuir de volta: rascunhos pro PCGamingWiki e pros projetos da comunidade, que só são postados com a sua aprovação.

Ferramenta boa nasce de uso real

O rea-launcher-sdk saiu do zero pra versão 0.3.3 em umas quatro horas e meia, mas isso só foi possível porque antes existiam sete launchers funcionando, com quase mil commits somados. O framework é a parte fácil quando você já tem os projetos.

Não comece pelo framework. Faça o mesmo tipo de projeto várias vezes, deixe as cópias divergirem, e só depois extraia. Com agentes, esse ciclo que levaria meses cabe em poucos dias.

Se o seu jogo favorito está preso no passado, o SDK está aberto. Aponte o seu agente pra ele, aponte pra pasta do jogo, e solte o seu próprio launcher.

TL;DR: fiz launchers que instalam e rodam Colin McRae Rally 1, 3, 04, 2005 e DiRT, DiRT Rally, OutRun 2006, Sega Rally Revo e a trilogia Screamer em PC moderno, com 4K, widescreen e controle de Xbox, no Linux e no Windows. Se você só quer baixar e jogar, pule direto pra lista dos jogos, com os links das releases, vídeos e instruções.

No artigo anterior eu mostrei os meus dois projetos em cima do Colin McRae Rally de 1998: o recomp em Rust, que tenta reconstruir o jogo do zero, e o launcher, uma camada fina em volta do executável original que faz ele rodar em 4K, widescreen e 60 fps num PC moderno.

O resultado do launcher me agradou muito, e o mais interessante foi perceber como a receita era fácil de repetir. Então resolvi trazer mais abandonware de volta pra era moderna. Entre a noite de 31 de outubro e a noite de 2 de novembro saíram mais oito launchers, cobrindo dez jogos de corrida:

• Colin McRae Rally 3 (2003)
• Colin McRae Rally 04 (2004 no PC)
• Colin McRae Rally 2005 (2004)
• Colin McRae: DiRT (2007)
• DiRT Rally (2015), no port nativo de Linux de 2017
• OutRun 2006: Coast 2 Coast (2006)
• Sega Rally Revo (2007)
• a trilogia Screamer (1995 a 1997), da era do MS-DOS

Os seis primeiros substituíram as instalações manuais que eu mantinha no meu projeto distrobox-gaming. Por enquanto o objetivo foi só um: instalação fácil e reproduzível, com o jogo rodando bem.

Os dois últimos, o Colin McRae Rally 2005 e o DiRT Rally, saíram na noite de 2 de novembro, depois da primeira versão deste artigo, já criados direto do SDK que eu explico no final.

O problema do abandonware

Existem centenas de jogos em estado de abandonware: não tem nenhuma forma oficial e suportada de jogar hoje. Eles não estão na Steam, não estão nem na GOG. E mesmo alguns que estão na GOG só rodam direito depois de muito ajuste manual. A trilogia Screamer é um exemplo: a GOG vende o Screamer e o Screamer 2 (o Screamer Rally não está lá), e a versão dela vem com um stub de Glide pra Windows que simplesmente não funciona no DOS.

O motivo é que a compatibilidade quebrou em camadas.

Jogos de MS-DOS precisam de emulador. Jogos de Windows 95/98 falam com DirectDraw e Direct3D 5, APIs que o Windows moderno mantém só por compatibilidade, com bugs e limitações que a Microsoft não prioriza mais. Jogos de Windows XP de 32 bits dependem de proteções de disco como o SafeDisc e versões antigas do SecuROM, que a Microsoft bloqueou em 2015 por questão de segurança. No Windows 10 e 11, a maioria desses jogos não sobe sem configuração manual, e no Linux a lista de ajustes é ainda maior.

Dois exemplos do que era preciso fazer

O Colin McRae: DiRT de 2007 era assim no meu setup antigo:

1. Rodar o instalador InstallShield de 2007 de forma interativa, porque ele não tem modo silencioso confiável.
2. Aplicar a cadeia de patches oficiais na ordem: 1.1, 1.2, 1.21 e 1.22, cada um com seu assistente.
3. Descobrir que o jogo abre os menus, mas trava ao carregar qualquer corrida num processador com 32 threads. O motor EGO monta mapas de distribuição de trabalho por número de núcleos, e os mapas originais não sabem lidar com tanta thread.
4. Aplicar um fix da comunidade, o MTFix, que corrige isso mas apaga o cache de configuração e reseta todas as opções gráficas.
5. Lembrar que, depois de mudar a resolução, o botão “reiniciar agora” do jogo só fecha o jogo.

O Sega Rally Revo de 2007 tinha outra lista:

• um microstutter permanente em toda corrida, causado por dois bugs de tempo empilhados que o patch 4.060 introduziu;
• uma chave de registro obrigatória, sem a qual o jogo não abre;
• um configurador em .NET que não funciona direito no Wine;
• vídeos de logo que faziam a inicialização parecer travada;
• tela cheia exclusiva falhando em monitor de 240 Hz, e tela preta em PC com duas GPUs, a integrada e a dedicada.

A maioria das pessoas simplesmente não vai fazer nada disso. Elas desistem do jogo, e o jogo morre um pouco mais.

Decomp, recomp e por que eu fiz só launcher

O hype do retrogaming hoje está nos decomps e recomps. Um decomp reconstrói, a partir do binário, um código-fonte equivalente ao original, que compila pro mesmo binário, como foi feito com o Super Mario 64 e com o Ocarina of Time, que virou o Ship of Harkinian. Um recomp traduz o binário automaticamente pra C e compila isso como código nativo, como o N64Recomp faz com jogos de Nintendo 64, que gerou ports de PC com ultrawide e fps alto.

A vantagem dos dois é enorme: você deixa de depender do binário original e consegue compilar o jogo pra qualquer plataforma, de ARM e Android a Mac. É o que eu tentei com o recomp do Colin McRae 1, e é trabalho de meses.

Pra mim, a coceira era outra. Eu queria que os jogos que eu gosto fossem fáceis de instalar e de manter no meu distrobox. Pra isso, um launcher basta.

O conceito: religar o jogo nas bordas

Todos os launchers seguem a mesma ideia. O jogo original continua igual, e o que muda são as bordas dele com o mundo, as partes que envelheceram:

• gráfico: a API de 1998 ou de 2003 passa a conversar com uma API moderna;
• entrada: controle de Xbox, gatilho analógico e rumble no lugar de teclado e joystick de porta de jogos;
• áudio e arquivos: registro do Windows, arquivos de configuração, saves e caches escritos certo antes de o jogo abrir;
• tela: escolher o monitor certo, a resolução certa e o modo de janela que não quebra.

Cada launcher identifica o executável, por hash ou por assinatura de bytes, recusa versões desconhecidas, e trabalha numa cópia privada do jogo. A pasta original nunca é modificada; qualquer patch vai só na cópia.

As peças de compatibilidade

Quase nada disso eu escrevi do zero. Os launchers orquestram ferramentas que a comunidade levou décadas construindo:

• Wine: a camada que implementa a API do Windows no Linux. Os launchers dos jogos de Windows levam o próprio Wine 11.20 dentro de um AppImage.
• DXVK: traduz Direct3D 8, 9, 10 e 11 pra Vulkan. É o que deixa jogo de DirectX 9 rodar rápido no Linux.
• dgVoodoo 2: um wrapper do desenvolvedor Dege que pega APIs gráficas antigas (Glide da 3dfx, DirectDraw e Direct3D das primeiras versões até a 9) e traduz pra Direct3D 11 ou 12. É como fazer um jogo de 2003 achar que está numa placa da época enquanto roda em placa moderna.
• dosbox-staging: um emulador de DOS moderno, com emulação da placa 3dfx Voodoo.
• gamescope: o compositor da Valve que roda o jogo numa tela própria e faz o escalonamento pro monitor.
• patches e ferramentas da comunidade: SilentPatch pro Colin McRae 3, OutRun2006Tweaks pro OutRun, o fix de stutter do Sega Rally, e o Xidi, que apresenta controles XInput pros jogos que só leem DirectInput.

E o REA, a minha ferramenta de engenharia reversa, entra onde não tem ferramenta pronta: achar a função do jogo que calcula a projeção, o formato do arquivo de perfil do controle, o lugar certo pra um hook.

Os que exigiram mais engenharia reversa

Colin McRae Rally 04: três camadas de tradução

O CMR04 usa Direct3D 9, mas é hostil a widescreen: sem patch, o 16:9 não mostra mais cenário dos lados. E o menu gráfico do jogo só lista modos até 2048x1536, reescreve o registro e trava.

O pipeline final ficou com três camadas no Linux: o Direct3D 9 do jogo passa pelo dgVoodoo 2.80, que converte pra Direct3D 11, o DXVK converte o Direct3D 11 pra Vulkan, e o Wine roda tudo por baixo. No Windows, fica só o dgVoodoo. A versão mais nova do dgVoodoo crashava, e a 2.80 nem está mais disponível completa no site oficial, então o repositório guarda só a DLL testada.

Pro widescreen, a engenharia reversa achou a função de projeção e a matemática dela: o patch de 16:9 da comunidade só funciona se o jogo renderizar em 4:3 e a imagem for esticada depois. Renderizar direto em 16:9 com o patch deixava os carros 25% mais estreitos. Então o launcher renderiza em 4:3 na altura da tela e o dgVoodoo estica pra 16:9 com a geometria certa.

E teve detalhe de todo tipo:

• o jogo ignora o Alt+F4: a função da janela devolve zero pra mensagem de fechar e o loop principal ignora a de sair, então o launcher injeta um hook que fecha o processo;
• o perfil do controle fica num arquivo binário de quase 1 MB, e o launcher escreve os bytes certos pra o controle já vir configurado, conferido byte a byte contra o arquivo que o próprio jogo salvou;
• num monitor principal em retrato, a imagem saía numa faixa de 3829x682, então o launcher escolhe o maior monitor em paisagem.

Sega Rally Revo: corrigindo o stutter em Rust

O stutter do Sega Rally tem uma correção da comunidade, de um desenvolvedor chamado stuken, mas o script dele não tem licença. Por isso a correção do launcher é uma implementação clean room: foi escrita a partir de uma especificação do que ela precisa fazer e do código do próprio jogo, lido pelo REA, por um agente que nunca viu o patch original. O stuken fica com o crédito por achar os bugs e mostrar que dava pra corrigir.

O resultado são “code caves” escritas no executável da cópia privada:

• uma trava que impede o jogo de criar a thread de ritmo duplicada a partir da segunda etapa;
• uma rotina única que todas as escritas no relógio de corrida passam a chamar, que lê o relógio mestre e nunca deixa o tempo andar pra trás;
• uma atualização desse relógio a cada quadro, na thread principal.

Medido no jogo, o relógio de corrida fica a menos de 1 ms do tempo real em 99,9% dos quadros, a 60 fps, a 120 fps e sem limite. Cada ponto de hook é conferido byte a byte antes de escrever, e o executável resultante é conferido pelo hash. O mesmo esquema aplica o patch de aspecto pra 21:9 e 32:9, achando as tabelas por padrão de bytes.

O resto foi lidar com o Wine: o jogo roda sempre num desktop virtual isolado, o launcher fixa a GPU NVIDIA em máquina com duas placas, e configura o driver de controle do Wine pra o XInput nativo do jogo funcionar.

A trilogia Screamer: hackeando o próprio emulador

A trilogia Screamer é de MS-DOS, então o caminho foi outro: um dosbox-staging modificado, com uma biblioteca em Rust ligada estaticamente dentro do emulador.

• 3dfx Glide de verdade. O Screamer 2 e o Screamer Rally carregam o GLIDE2X.OVL do DOS, que conversa com a Voodoo 1 emulada pelo dosbox. O Screamer 2 da GOG traz um stub de Windows que não funciona; com o Screamer Rally na mesma pasta, o launcher usa o OVL genuíno de DOS dele.
• Um bug do próprio jogo. O código de upload de texturas tinha um erro na fronteira de 2 MiB, corrigido com um patch de três instruções.
• Controle analógico. Com o emulador rodando na velocidade máxima, a leitura de joystick da porta de jogos termina antes de o capacitor emulado descarregar, e o controle não funciona. A solução foi achar na memória do jogo os registros de controle e escrever direção, acelerador e freio direto neles, em 10 bits.
• Widescreen e distância de desenho vieram de patches no executável Watcom: a matriz de câmera ganha um campo de visão maior antes da projeção, e os limites de distância dos objetos aumentam.

Uma primeira versão usava LD_PRELOAD pra interceptar o relógio do sistema e travava o SDL, porque rodava em várias threads do emulador ao mesmo tempo. Por isso o hook acabou dentro do loop principal do dosbox.

Depois de rodar, melhorar

Com o jogo rodando de novo no Linux e no Windows, dá pra ir além do original. É aqui que o launcher vira mais que um instalador.

Resolução e aspecto

Jogo de 1998 foi feito pra 640x480 ou 800x600 em monitor 4:3. Renderizar em 4K é a parte fácil, quando a API permite.

O difícil é o aspecto: esticar uma imagem 4:3 pra 16:9 deixa tudo largo. O certo é o Hor+, que mantém a altura e mostra mais cenário nas laterais, aumentando o campo de visão horizontal. Isso exige mexer na projeção da câmera, e foi o que eu fiz no Colin McRae 1 e no Screamer. No Colin McRae 3, o SilentPatch já entrega Hor+ em qualquer proporção.

Taxa de quadros

Muitos jogos antigos amarram física e renderização no mesmo relógio, e destravar o fps acelera o jogo inteiro. O Colin McRae 1 tem física num tick fixo de 25 Hz e interpola os quadros, então chega a 60 fps sem mexer na física. O Screamer não: a física lê uma tabela de 50 posições indexada pelo tempo do quadro, e passar de 50 fps faz os carros voarem na largada ou derruba o jogo.

Pro Screamer, o launcher tem um modo experimental de geração de quadros a 100 fps: entre dois quadros reais ele desenha um quadro intermediário, com uma busca de movimento simples feita num shader. Funciona, mas custa uns 10 ms de atraso, e por isso fica desligado por padrão.

Filtragem anisotrópica

Quando uma textura é vista quase de lado, como o asfalto lá na frente, a filtragem comum borra tudo, porque amostra a textura como se ela estivesse de frente. A filtragem anisotrópica amostra mais pontos na direção em que a textura está inclinada, e o asfalto e as placas ao longe ficam nítidos. Nos jogos de Direct3D 9, como o Colin McRae 3 e o OutRun, dá pra forçar até 16x.

Escaladores

Quando o jogo renderiza numa resolução e a tela tem outra, alguém precisa escalonar a imagem. No Linux, quase todos os launchers usam o gamescope, que oferece:

• nearest: repete pixels inteiros, ideal pra quem quer a cara original;
• pixel: mantém os pixels nítidos mas suaviza a borda entre eles, bom pra arte em pixel numa escala que não é inteira;
• linear: interpola entre os pixels, suave, mas borra;
• FSR: o FidelityFX Super Resolution 1.0 da AMD, que reconstrói bordas e aplica nitidez, bom pra subir de 1080p pra 4K;
• NIS: o equivalente da NVIDIA, usado no CMR04.

O Screamer tem um FSR próprio, escrito como shader dentro do dosbox, e um “superscale” 2x da Voodoo emulada: o emulador renderiza a placa 3dfx no dobro da resolução, multiplicando as coordenadas dos triângulos.

Cor e gama no Colin McRae 3

O Colin McRae 3 sempre teve uma imagem lavada. Medindo um quadro em 4K, a imagem inteira ficava entre uns 25 e 160 numa escala de 0 a 255: preto que não é preto, branco que não é branco.

O launcher gera uma LUT, uma tabela de conversão de cores em 3D, que reajusta ponto preto, ponto branco, gama e saturação, e aplica ela com o vkBasalt por cima do DXVK, junto com um filtro de nitidez. Tem dois perfis, “Colour” e “Cinematic”, ambos opcionais e por enquanto só no Linux.

Texturas HD geradas por IA no Colin McRae 1

O projeto que mais me divertiu foi o pacote de arte HD do Colin McRae 1. O jogo guarda as imagens num formato próprio, e uma ferramenta em Rust extrai todas, inclusive as que ficam dentro dos modelos 3D: céus, pinturas dos carros, placas na beira da pista.

A primeira tentativa foi o Real-ESRGAN, um upscaler clássico. Ficou ruim: inventou textura de couro rachado na fibra de carbono e contornou as letras. Daí em diante, cada tipo de imagem ganhou um método:

• arte chapada (HUD, logos, bandeiras, ícones) passa por um algoritmo determinístico de despixelização, sem IA, e depois é travada na paleta original;
• o resto é redesenhado em 4K pelo modelo de imagem do Google, o Gemini 3.1 Flash Image, com um modelo de visão conferindo se cada palavra e número do redesenho é real. Se nenhuma tentativa passa, fica a imagem original.

Os erros da IA foram didáticos: o “50” do mostrador virou outro “60”, “SNR” virou “SMX”, apareceu “New ZeZealand”, carros ganharam estepe e entrada de ar que não existiam. A regra que ficou: nunca confiar nas cores do modelo, pegar a melhor de três tentativas, e comparar cada resultado com o original.

O pacote 4 cobre o HUD, os menus, os céus de todas as etapas, 124 das 164 placas e 247 das 370 texturas de carro. A arte bruta tem uns 800 MB; comprimida, fica em uns 47 MB. No jogo, um hook troca cada textura original pela versão HD na hora de desenhar, sem mudar o layout.

Os jogos

Todos seguem o mesmo esquema de instalação, então explico uma vez. Você precisa ter a sua própria cópia do jogo, na versão que cada launcher pede, e nenhum deles distribui arquivos do jogo.

• Linux: baixe o AppImage da release, dê permissão de execução e rode. Ele já traz o Wine, e o DXVK nos jogos de Direct3D 9; o do Screamer traz o dosbox modificado. Se o gamescope estiver instalado, quase todos usam.
• Steam / Steam Deck: adicione o AppImage como jogo não-Steam, ou o executável de Windows do launcher com um Proton forçado. O Screamer roda nativo, sem Proton.
• Windows: baixe o zip, descompacte e rode o executável do launcher.

Na primeira execução, aponte a pasta onde o jogo está instalado, escolha um perfil visual e aperte Play.

chmod +x CMR4Launcher-*-x86_64.AppImage
./CMR4Launcher-*-x86_64.AppImage

Colin McRae Rally (1998)

Release v0.8.0 · precisa da versão em CD, atualizada pra EU v1.5.

• 4K, widescreen Hor+ e 60 fps, com a física original a 25 Hz;
• pacote de arte HD gerado por IA no HUD, menus, céus, placas e carros;
• filtragem trilinear com mipmaps, distância de desenho estendida, buffer de profundidade de 24 bits;
• pedais nos gatilhos, rumble e layouts de botão modernos.

Colin McRae Rally 3 (2003)

Release v0.2.1 · precisa da versão oficial 1.1.

• SilentPatch com widescreen em qualquer proporção e interface HD em 4K;
• conversão do executável oficial 1.1 pro executável sem DRM das reedições;
• filtragem anisotrópica até 16x, campo de visão ajustável, sombras nítidas ou suaves;
• correção de cor e gama opcional no Linux;
• gatilhos como pedais e o controle já configurado no perfil novo.

Colin McRae Rally 04 (2004)

Release v0.3.1 · precisa da sua instalação do jogo, com o cmr4.exe original.

• 16:9 com a geometria correta, via dgVoodoo, ligado sozinho quando a resolução escolhida é 16:9;
• escolha automática do monitor em paisagem e fechar a janela funcionando;
• gatilhos analógicos como pedal combinado e perfil do controle pré-configurado;
• limite de fps e vsync opcionais.

Colin McRae Rally 2005 (2004)

Release v0.1.0 · precisa da versão 1.1 da GOG, instalada ou só os três arquivos do instalador; as versões em DVD usam a proteção StarForce e não são suportadas.

• corrige o crash logo na abertura no Wine: o jogo procura os arquivos por chaves de registro que o instalador grava, e o launcher escreve essas chaves a cada início;
• instala direto dos arquivos do instalador da GOG, que trava no Wine, desempacotando tudo com o innoextract;
• widescreen 16:9 com a visão widescreen do próprio jogo, no maior tamanho que cabe na tela;
• DXVK no Linux: uma etapa que rodava a umas 20 fps passou de 1000 fps, com limite de fps e vsync configuráveis;
• saves numa pasta própria e fechar a janela funcionando.

Colin McRae: DiRT (2007)

Release v0.2.0 · precisa da versão oficial 1.22.

• correção própria do crash em processador com muitas threads, aplicada sozinha (até 12 threads) e sem resetar as configurações;
• flag Large Address Aware no executável da cópia, pra ele usar mais de 2 GB de memória, conferida byte a byte;
• cópia privada com hard links pros cerca de 9 GB de dados estáticos, quando está no mesmo disco do jogo, sem duplicar espaço;
• preset Ultra em 4K, 16:9 nativo do jogo e XInput nativo.

DiRT Rally (2015)

Release v0.1.0 · só pra Linux. Precisa do port de Linux da Feral Interactive, versão 1.0 (o build final de 2017), numa cópia que já rode sem o cliente da Steam. O jogo foi retirado de venda em 2022, e a versão de Windows ainda não é suportada.

• corrige o crash logo na abertura em AMD Ryzen 5000 e mais novos (e Intel recentes), com uma pequena biblioteca, sem mexer no jogo;
• traz as bibliotecas antigas que o Linux moderno não tem mais (OpenSSL 1.0, libidn11, librtmp, OpenLDAP 2.4, GConf), de pacotes fixos do Steam Runtime, e entrega só pro jogo;
• pula a janela da Feral e o aviso de “distribuição Linux não suportada”, e abre em tela cheia na resolução do monitor, 4K inclusive;
• controles novos, como os da 8BitDo e os estilo Xbox recentes, entram na lista de controles do próprio jogo, com o preset pronto;
• cópia privada de uns 40 GB, ou hard links quando está no mesmo disco do jogo.

O RaceNet foi desligado, então eventos online e ligas não funcionam mais. Carreira offline e etapas avulsas funcionam.

OutRun 2006: Coast 2 Coast (2006)

Release v0.2.1 · precisa da sua cópia de PC do jogo.

• o OutRun2006Tweaks, que conserta o port de PC e remove o DRM de disco, instalado automaticamente numa versão fixa e testada;
• 4K, filtragem anisotrópica 16x, reflexos em 2048 e distância de desenho maior;
• a música “Rush a Difficulty” com os dois segundos iniciais que faltavam na versão de PC;
• pacote de texturas HD opcional, baixado sob demanda;
• rumble e gatilhos completos pelo SDL.

Sega Rally Revo (2007)

Release v0.2.0 · precisa da versão 4.0.6.0 de PC.

• correção do stutter própria, feita em clean room;
• 4K, qualidade Ultra e ultrawide 21:9 e 32:9;
• limite de 60 ou 120 fps, controle XInput nativo e teste de rumble.

Trilogia Screamer (1995 a 1997)

Release v0.7.0 · precisa do Screamer e do Screamer 2 da GOG ou dos CDs originais; o Screamer Rally só existe em CD.

• 3dfx Glide com o OVL genuíno de DOS e superscale 2x da Voodoo;
• FSR em shader, widescreen Hor+ e distância de desenho estendida;
• controle analógico de verdade, inclusive no 8BitDo Ultimate 2;
• trilha de CD funcionando e geração de quadros experimental a 100 fps.

Windows e Linux ao mesmo tempo

Fazer o mesmo launcher funcionar nos dois sistemas exige algumas escolhas:

• um executável só. Os launchers dos jogos de Windows são escritos em Rust, com interface em egui, e compilados como executável de Windows. No Windows ele roda direto; no Linux, o mesmo executável roda dentro do Wine;
• o AppImage leva tudo. No Linux, cada launcher de jogo de Windows empacota um Wine 11.20, e o DXVK quando o jogo precisa, com o próprio prefixo, sem depender de nada instalado na máquina;
• o gráfico muda por sistema. No Windows o jogo usa o Direct3D nativo; no Linux, o DXVK traduz pra Vulkan, e o Colin McRae 1 usa o wined3d do próprio Wine;
• o Screamer é nativo nos dois, porque o dosbox-staging compila pra Linux e Windows;
• o DiRT Rally é a exceção: ele roda o port nativo de Linux da Feral, sem Wine, então por enquanto o launcher só existe pra Linux.

Teve pegadinha nisso também. O linker do GNU binutils 2.47 descartava parte da tabela de importação do executável de Windows, e o launcher crashava logo ao abrir. A correção foi trocar pro linker do LLVM, o lld. Hoje todos os launchers do SDK (abaixo) linkam com ele, e a CI confere as importações de cada executável.

Todos os launchers foram testados de ponta a ponta no Linux (com Wine 11, com o dosbox no Screamer, ou nativo no DiRT Rally), numa RTX 5090 e com controle estilo Xbox. No Windows nativo eles ainda não foram testados. Se você tem algum desses jogos e um PC com Windows, teste e abra uma issue no repositório, com o SHA-256 do executável e o log. Contribuições são muito bem-vindas.

Quanto tempo levou

Pelo histórico do git, somando as sessões de trabalho, e contando o trabalho antes do primeiro commit pelas datas dos arquivos do projeto:

Vários foram feitos em paralelo: o CMR04 e o DiRT na mesma tarde, o OutRun e o Sega Rally na mesma noite. Somando, são umas 38 horas de sessões de trabalho nos seis launchers novos, mas como eles andaram em paralelo, tudo coube em pouco mais de um dia de calendário. O Colin McRae Rally 2005 e o DiRT Rally vieram depois, em paralelo, numa tarde e noite só.

O que deu errado no caminho

• A versão nova nem sempre é a melhor. O dgVoodoo 2.87 crashava no CMR04; a 2.80, que funciona, nem está mais disponível completa.
• O jogo também tem bugs. O Screamer tinha um bug de upload de textura, e o DiRT tem mapas de threads incompletos pra 6 núcleos.
• Código que parece morto pode estar vivo. No Screamer, uma área de “preenchimento com zeros” usada pra um patch era código alcançável, e o jogo fechava no meio da corrida.
• Diagnóstico errado custa caro. No CMR3, um controle virtual criado por outro script na minha máquina me fez caçar um bug de mapeamento que não existia.
• O Wine tem as suas manias. O EGL do Wine 11 caía pra renderização por software na NVIDIA, a tela cheia escolhia o monitor em retrato, e um crash do player de vídeo travava o jogo atrás de um depurador invisível.

A receita virou SDK

Depois da primeira leva, o código que se repetia nos sete launchers saiu de cada repositório e foi pra uma base comum, o rea-launcher-sdk. Ali ficam a janela de configurações, a cópia privada do jogo, a identificação do executável por SHA-256, os patches binários, o hook de fechar a janela, o empacotamento em AppImage com Wine e a CI.

Com isso, cada launcher ganhou de uma vez:

• uma instância por vez: abrir o launcher de novo traz a janela aberta pra frente, e com o jogo rodando ele avisa em vez de abrir uma segunda cópia;
• uma tabela única de opções, de onde saem a janela, o --help e o launcher.cfg, com um teste que falha se a janela e a linha de comando divergirem;
• lld e checagem de importações na CI de todos;
• formulários de issue padronizados, pra bug e pra versão desconhecida do jogo, pedindo o SHA-256 do executável e o log.

O SDK foi escrito pra ser usado por um agente de código. O README tem o passo a passo: instalar o REA, apontar o agente pro SDK e pra pasta do seu jogo, e pedir um launcher novo. O agente pesquisa os fixes da comunidade, faz a engenharia reversa e escreve o código, e você revisa nos pontos de checagem que o playbook define.

O Colin McRae Rally 2005 e o DiRT Rally foram os primeiros a nascer assim, a partir do script new-launcher do SDK: cada um levou umas 4 a 5 horas da primeira pesquisa até a release.

Ferramentas velhas, velocidade nova

Nada aqui é técnica nova. Wine existe desde 1993, o DOSBox desde 2002, o dgVoodoo e o DXVK há anos, e os patches da comunidade foram feitos por gente que passou noites com depurador e editor hexadecimal. Ghidra, disassembler, winedbg, xdelta: tudo ferramenta de décadas.

A diferença é que agora um LLM opera essas ferramentas comigo. Ele lê a documentação, escreve o hook, roda o jogo, compara o resultado e tenta de novo, enquanto eu decido o que vale a pena consertar e reconheço quando a estratégia está errada. O REA dá a ele acesso estruturado à engenharia reversa, e o resto é a caixa de ferramentas que a comunidade de preservação já tinha construído.

Portar abandonware de volta pra era moderna costumava levar semanas por jogo, e por isso quase ninguém fazia. Com LLMs operando ferramentas que existem há décadas, cada jogo virou trabalho de algumas horas, e eu fiz oito em uns dois dias.

Os launchers são experimentais e vão continuar mudando. Se o seu jogo favorito está preso no passado, a receita está aberta nos repositórios.

Isso ajuda muito. Só não confunda ajuda com botão mágico. Você não escreve “REA, decompila este jogo” ou “porta isso pra Windows” e vai tomar café enquanto ele termina. Precisa entender a arquitetura, o formato do binário, as APIs antigas, o que observar em runtime, qual ferramenta usar e como provar que a reconstrução bate com o programa original.

O trabalho de pensar continua com você. O REA acelera a coleta de evidências e dá braços extras pra quem sabe conduzir a investigação. Sem conhecimento técnico, o resultado continua sendo um amontoado de pseudocódigo plausível.

O projeto está no GitHub e ainda é experimental e work in progress. A versão que mostro aqui já permite jogar uma etapa inteira, mas estou construindo a próxima rodada: controle de frame pacing e vsync, filtros bilinear, trilinear e anisotrópico, além de estudar mipmaps sem alterar os dados originais. Também faltam testes em mais máquinas e no Windows nativo. Espere mudanças e releases novas.

Agora assista a isto:

Esse é o Colin McRae Rally original de 1998 rodando uma etapa inteira da Nova Zelândia. A captura está em 1080p, mas o jogo chega a 4K, em 16:9 real, mostrando mais cenário nas laterais. O HUD foi reposicionado nos cantos, a distância de desenho aumentou e aquele pop-in constante quase desapareceu.

A imagem é apresentada a 60 fps nessa configuração, com a física original no tick fixo de 25 Hz. O jogo já separava atualização e renderização e interpolava os frames. A velha cadeia de DirectDraw/Direct3D 5 só precisava chegar corretamente ao display moderno.

E abaixo está o launcher que fiz pra isso:

Sim, eu fiz um launcher moderno pro primeiro Colin McRae Rally de PC.

O jogo que ficou preso em 1998

Muita gente lembra do Colin McRae Rally pelo PlayStation. Era um jogo 4:3 de baixa resolução, feito pro ritmo dos televisores PAL e NTSC da época. Em 2026, ainda dá pra jogar num emulador e subir a resolução interna, porém o resultado continua carregando as limitações visuais e de apresentação do console.

A Codemasters também lançou uma versão nativa pra Windows em 1998. Ela foi feita pra Windows 95 e 98, num executável x86 de 32 bits com Direct3D 5 e DirectX 6.

Hoje o jogo está fora de catálogo e é tratado como abandonware pela comunidade. Esse rótulo descreve a realidade de preservação, não concede licença pra redistribuir nada. Meu launcher não leva executável, pista, carro, música ou qualquer asset da Codemasters. Você precisa da sua própria cópia instalada, do CD ou de um backup antigo, atualizada pro patch 1.5.

Encontrar os arquivos virou arqueologia. Eu não vou hospedar nem apontar download de jogo comercial. O projeto aceita hoje duas variantes europeias conhecidas do Rally.exe 1.5 e mostra o SHA-256 quando encontra outra versão, justamente pra podermos adicionar suporte sem adivinhar offsets.

A novela anterior ao launcher

Eu já tinha automatizado o Colin McRae no meu projeto de retrogames de corrida no Distrobox. Funcionava, mas leia a lista do que foi necessário:

• copiar uma instalação portátil e reconstruir no Wine as chaves CDPath, HDPath, AVIPath e WAVPath do Registry;
• forçar o perfil de compatibilidade do Windows XP SP3;
• prender um Xwayland rootful numa tela de 800x600, porque o menu abre em 640x480 e a corrida troca de modo;
• forçar o backend GLX e o offload pra NVIDIA, evitando que o Wine escolhesse a iGPU AMD ou llvmpipe na minha máquina;
• emular teclado a partir do gamepad, porque o caminho antigo de DirectInput detectava o controle, mas o jogo não aceitava os eixos;
• conviver com a imagem 4:3 esticada e com os becos sem saída de gamescope, dgVoodoo2 e outros wrappers.

Depois de tudo isso, o jogo chegava a 800x600, 4:3, com a distância de desenho original. O controle precisava estar ligado antes de abrir. Clicar no velho painel de joystick podia deixar a tela preta com a música tocando. Era o tipo de configuração que funciona no meu PC porque eu gastei horas documentando cada gambiarra.

No Windows 11 talvez você consiga montar outra combinação de compatibility mode e wrappers. Eu não testei. A própria PCGamingWiki recomenda compatibilidade com XP SP3 e documenta os problemas da versão de 1998 em sistemas atuais.

Depender de uma sequência secreta de Registry, Xwayland, Wine e wrapper gráfico reduz a “preservação” a algo que funciona temporariamente no computador de alguém.

Eu tentei fazer o decomp completo

O OpenCMR2 me animou a tentar algo mais ambicioso. Ele é um port nativo em andamento do Colin McRae Rally 2.0, construído sobre o CMR2Decomp, usando SDL3 e os dados da cópia original. É exatamente o tipo de projeto que permite abandonar DirectDraw, DirectInput e outras APIs antigas.

Tentei fazer o equivalente pro primeiro jogo. Comecei a reconstrução no dia 20 de outubro. Quando parei pra revisar a direção no dia 28, depois de oito dias de commits quase contínuos, o experimento já tinha cerca de 250 mil linhas de Rust, 2.922 testes, 2.168 procedures mapeadas no executável, 32.530 símbolos e 2.310 strings catalogadas. O roadmap marcava 117 itens completos de 119.

No oitavo dia, o padrão ficou claro. O REA continuava encontrando funções, relações e evidências locais, e os agentes continuavam transformando cada descoberta em mais código e testes. Só que o processo estava derivando. O volume do repositório crescia, enquanto a distância até um port fiel e utilizável deixava de diminuir.

A parte parcial concentrava justamente a integração mais difícil: colisão e suspensão em runtime, animação de carro e rodas, produtores de marcha e giro, fluxo completo de chegada e pós-corrida, fidelidade de pintura, reflexos, danos e execução equivalente no Windows. Existia um harness dirigível, útil pra provar subsistemas, com partes recuperadas e outras aproximadas. Cada nova camada revelava outros contratos escondidos no executável original.

Quando o repositório cresce mais rápido que o resultado, está na hora de revisar a estratégia.

Eu tratei aquilo como qualquer spike de engenharia: aprendi o que precisava, reconheci que o caminho estava se afastando do objetivo e parei. Continuar só porque já havia investido oito dias seria custo afundado. O experimento cumpriu sua função ao mostrar onde a reconstrução completa começava a perder convergência.

No dia 28, mudei o plano. O executável original já resolvia física, renderização, áudio, menus e toda a lógica do jogo. A opção mais curta era preservar esse núcleo e corrigir apenas as fronteiras quebradas pelo tempo. Foi daí que nasceu o launcher.

Essa estratégia serve pra muitos jogos antigos de Windows. Se o executável x86 ainda roda e Wine ou Proton conseguem fornecer as APIs básicas, a tarefa muitas vezes se resume a refazer a ligação com o sistema atual, mantendo dentro do binário as decisões originais. Isso já basta pro objetivo de voltar a jogar num computador moderno.

O custo esperado em tokens de LLM cai muito. Um decomp completo obriga o agente a ler, explicar, reconstruir e testar física, áudio, renderização, menus, formatos de arquivos e cada estado intermediário. O launcher reduziu o problema a uma lista fechada: Registry, checagem de CD e Windows, modo de vídeo, controles, resolução, projeção, HUD e distância de desenho. Quando a meta é jogar, esse tipo de rewiring entrega muito mais por token.

Um launcher fino em volta do original

O projeto está no GitHub. A arquitetura ficou bem menor: um launcher em Rust prepara um ambiente privado, valida a versão do jogo, configura o runtime e aplica correções em memória no Rally.exe. Uma DLL pequena intercepta os pontos em que resolução e HUD precisam de contexto extra.

Nada é alterado no diretório original. Na primeira execução, o launcher cria uma cópia privada em %LOCALAPPDATA%\CMRLauncher\Rally, sincroniza os arquivos e guarda os saves fora da instalação. Isso evita depender de escrita em Program Files, VirtualStore e restos de estado de uma tentativa anterior.

O launcher também recria as chaves de Registry que o jogo espera. Ele aponta CDPath, HDPath, vídeos e áudio pra cópia privada, escolhe o idioma e prepara o hardware. O velho CD deixa de ser uma dependência de execução, desde que a instalação tenha sido feita no modo completo.

As correções ficam associadas ao hash exato do executável. Hoje o projeto conhece a versão europeia 1.5 oficial e uma variante de fan pack. Se o binário não bater, ele recusa aplicar endereços de outra versão. Patch binário por aproximação é uma ótima maneira de transformar um jogo antigo em crash aleatório.

Compatibilidade básica

O executável começa testando uma coleção de premissas dos anos 90. Eu removi ou substituí as que não fazem sentido hoje:

• o teste do CD e o bloqueio por versão do Windows;
• leituras privilegiadas de portas VGA;
• o caminho de vídeo 8-bit incompatível, trocado pelo frontend de 16 bits que já existia no jogo;
• o comportamento em que fechar a janela ou apertar Alt+F4 era ignorado;
• um busy-wait baseado num relógio de CPU que se comporta mal em processadores modernos.

Wine e Proton continuam fornecendo DirectDraw, Direct3D 5, WinMM e as outras APIs antigas. Meu trabalho ficou concentrado no contrato entre o jogo e a camada de compatibilidade, sem reescrever um renderer inteiro.

Controles modernos

O jogo reconhecia controles antigos de DirectInput e esperava eixos de uma época anterior aos triggers analógicos atuais. Agora aceleração e freio podem usar os gatilhos ou o analógico direito, e Start pausa.

Também corrigi um bug em que o jogo salvava um controle inexistente, voltava sozinho pro teclado ou carregava uma configuração quebrada e deixava o carro girando. O launcher detecta esse estado e repara o save. Isso elimina a ponte de teclado que eu mantinha no Distrobox.

Resolução e widescreen

As quatro resoluções originais eram 320x240, 512x384, 640x480 e 800x600. O frontend foi desenhado em 640x480, enquanto a corrida recria o dispositivo gráfico com a resolução escolhida.

O launcher permite 1920x1080, 2560x1440 e 3840x2160. Durante a corrida, toda a interface 2D passa a usar uma tela virtual de 640x480. Sprites, fontes, mensagens, pausa, resultados e loading screen são escalados dessa área virtual; os elementos laterais do HUD ficam ancorados nos cantos da tela real.

O widescreen usa projeção Hor+. O centro mantém o mesmo enquadramento do 4:3 e a tela ganha informação nas laterais, em vez de esticar carros e árvores. Eu validei a geometria comparando 1440x1080 com 1920x1080: a faixa central permanece igual.

Os menus continuam sendo desenhados internamente em 640x480 e são ampliados com pixels nítidos. Em 4K essa cópia pode ficar abaixo de 30 fps em algumas máquinas. A corrida não sofre do mesmo problema; 1440p ou 1080p também deixa a navegação mais leve.

Distância de desenho

As pistas já são carregadas inteiras. O sumiço do cenário vinha do far plane e dos limites de culling gravados nos dados de cada etapa, normalmente entre 100 e 200 metros.

O launcher pode multiplicar essas distâncias em até três vezes. Ele ajusta o far plane, o wedge de objetos, o limite de terreno e o cap especial de algumas etapas. A geometria estava lá o tempo todo; o PC de 1998 só não tinha orçamento pra desenhá-la.

Aumentar demais custa desempenho e pode expor flicker distante por causa da precisão do Z-buffer de 16 bits. Por isso o controle é configurável entre 1.0 e 3.0, e o padrão não força a melhoria.

60 fps sem mexer na física

Esta parte me surpreendeu. A simulação roda em 25 Hz e existe um modo escondido de 50 Hz que muda o resultado da física. Alterar isso seria mudar o jogo.

No modo normal, uma thread de timer atualiza a simulação e o loop principal renderiza tão rápido quanto o Flip permite. O código calcula um alpha pelo tempo desde o último tick e interpola carro, câmera e objetos. Em gamescope sem vsync, medi cerca de 190 frames apresentados por segundo em 1080p. Em 4K, o renderer por software ficou perto de 60 fps.

Os 60 fps vêm desse pipeline original de renderização interpolada. Num display real, o jogo apresenta no refresh do monitor, limitado pelo vsync da camada que o hospeda. A física continua a mesma de 1998.

Atualização: voltei pro recomp

Com a primeira versão jogável do launcher publicada, voltei ao repositório do recomp, enquanto os dois continuaram evoluindo em paralelo. O primeiro novo commit entrou na madrugada do dia 30, poucas horas depois do vídeo do launcher. Eu já tinha aprendido quais partes do executável realmente importavam em runtime, e agora também tinha uma forma muito mais simples de abrir o original e comparar o comportamento.

Na primeira madrugada de volta, fechamos os dois itens que restavam e o mapa de reconstrução chegou a 119 de 119 itens completos, com mais de 2.900 testes automatizados. Esse número significa que cobrimos o escopo que estava mapeado. Fidelidade perfeita exige outra etapa: jogar, observar, comparar com o original e ajustar as diferenças que só aparecem quando todos os subsistemas rodam juntos.

O estado atual já merece o rótulo de mostly playable. O front-end funciona com teclado e gamepad, dá pra escolher Championship, Rally, Time Trial e Rally School, passar pela tela de boas-vindas e Service Area, escolher carro e correr as 52 etapas dos oito países. O jogo carrega a pista e o carro escolhidos, toca as pace notes do Nicky Grist, anima rodas e suspensão, reproduz som de motor e superfícies, desenha HUD, processa checkpoints, splits e ranking, detecta a chegada e volta pros menus.

Também reconstruímos a órbita de câmera antes da largada, a contagem 5-4-3-2-1-GO! com áudio, objetos móveis, luzes noturnas, faróis, colisão com cenário e dano visível. Os commits mais recentes corrigiram o eixo longitudinal usado pela física, o término prematuro no Split 7 e os parâmetros de setup usados pra derivar as tabelas de câmbio e as constantes de cada carro. Já parece e soa como o Colin McRae original.

Ainda falta trabalho na sensação de dirigir. Nos meus testes desta build, o carro escorrega muito mais do que deveria e demora demais pra recuperar aderência. Esse tipo de diferença não aparece numa checklist de funções recuperadas. Ela aparece quando você entra numa curva, corrige o volante e percebe que o carro continua atravessado. Agora a prioridade é calibrar essas interações contra o original até o handling ficar convincente.

Também não coloquei nenhuma melhoria gráfica do launcher no recomp. O renderer moderno usa wgpu, mas continua apresentando a estética original em 640x480, com os assets, HUD e enquadramento antigos. Resolução alta, widescreen, draw distance maior, filtros modernos e outros confortos ficam pra depois. Primeiro quero acertar o jogo; embelezar uma física errada só produz um erro mais bonito.

Este é o estado do recomp na noite de 31 de outubro:

O vídeo mostra a tela de boas-vindas, largada, câmera, HUD, checkpoints e uma etapa dirigível, com áudio; a facilidade com que o carro entra e permanece numa derrapagem ainda denuncia a diferença de física. É um resultado muito além daquele harness aproximado de três dias atrás, porém continua sendo uma reconstrução em desenvolvimento.

Agora já existe base suficiente pra convidar mais gente. O repositório não inclui executáveis nem assets da Codemasters; cada pessoa importa os dados da própria cópia europeia do jogo. Quem quiser contribuir pode testar outras etapas, carros, controles, distribuições e Windows, abrir issues detalhadas, comparar o handling com o original ou trabalhar diretamente nos subsistemas. O README tem as instruções de importação, compilação e execução.

O launcher continua sendo a opção prática pra jogar hoje com melhorias modernas. O recomp voltou a ser interessante porque cruzou outra linha: já dá pra jogar, sentir onde ele diverge e substituir aproximações por evidência. Agora cada contribuição consegue atacar uma diferença visível em vez de trabalhar meses até aparecer o primeiro frame.

Como instalar

Você precisa do Colin McRae Rally de PC de 1998, com instalação completa e patch europeu 1.5. Dentro da pasta devem existir Rally.exe, Game, New_Fe e ini.

Baixe o ZIP na última release do launcher. Ele vem com CMRLauncher.exe, cmrhooks.dll e os auxiliares de Linux. Não vem com o jogo.

Linux com Steam e Proton

1. Extraia o ZIP, por exemplo em ~/Games/cmr-launcher.
2. No Steam, escolha Games → Add a Non-Steam Game to My Library e selecione CMRLauncher.exe.
3. Em Properties → Compatibility, force GE-Proton. Testei com GE-Proton 11.
4. Em Launch options, passe a pasta da sua instalação:

%command% --game "Z:/home/voce/Games/Colin McRae Rally"

O caminho fica salvo depois da primeira execução. Também existe um script pra Wine com gamescope e uma interface em Quickshell, a que aparece no screenshot.

Windows

Extraia o ZIP ao lado de Rally.exe e abra CMRLauncher.exe. Se preferir deixar o launcher em outro diretório:

CMRLauncher.exe --game "C:\Games\Colin McRae Rally"

O código foi preparado pra Windows 10 e 11, mas eu ainda não testei em Windows nativo. Tudo que validei até agora foi em Arch Linux, usando Wine e Proton. Quem testar em Windows, outra distribuição, AMD, Intel, outros monitores e outros controles já ajuda bastante.

Ao encontrar um problema, abra uma issue no GitHub com o launcher.log, hash do Rally.exe, sistema operacional, GPU, versão do Wine ou Proton e passos pra reproduzir. “Não funcionou” não dá pista suficiente pra corrigir compatibilidade.

Menos de dois dias

A parte específica deste launcher saiu do primeiro commit de compatibilidade jogável ao vídeo acima em menos de 30 horas. Nesse intervalo eu troquei a estratégia de um port nativo gigantesco por uma camada pequena em volta do executável original, fiz engenharia reversa dos pontos necessários, implementei as correções, testei uma etapa inteira e empacotei a release.

Recomps completos continuam difíceis. Exigem meses ou anos, conhecimento da plataforma, comparação contra o original e uma quantidade enorme de validação. REA ajuda a chegar na evidência; Claude e Codex ajudam a escrever e testar; alguém ainda precisa decidir qual problema vale resolver e reconhecer quando a estratégia está errada.

Código barato também barateia a decisão de jogar código fora.

Eu descartei uma reconstrução com cerca de 250 mil linhas porque ela não entregava o resultado que eu queria. A solução útil ficou muito menor: preservei o jogo original, substituí as bordas que envelheceram e acrescentei as melhorias que o hardware moderno permite.

Antigamente, fazer isso à mão seria tão demorado que eu provavelmente aceitaria os 800x600, o Xwayland preso e a ponte de teclado. Agora consegui devolver uma experiência moderna a um jogo fora de catálogo em menos de dois dias.

O ganho prático da engenharia reversa com IA está em tornar viável a correção daquelas incompatibilidades pequenas e cumulativas que deixavam software antigo preso ao computador de uma única pessoa. Pedir um PC port completo continua longe de ser suficiente.

O trabalho continua. Frame pacing e escolha de vsync, filtragem anisotrópica, mipmapping quando os dados permitirem, borderless com Alt-Tab seguro, rumble, remapeamento de botões e mais detalhes à distância já estão no plano da próxima rodada. O launcher de hoje é experimental; volte nas releases porque ainda quero tirar bastante coisa desse executável de 1998.

A última atualização do ranking comercial tinha adicionado Opus 5.5, GPT 6 Sol e Luna, MiMo 2.6 Pro e Grok 4.7. A conclusão já começava a aparecer: as versões novas estavam melhorando principalmente custo e velocidade. Qualidade tinha virado uma briga de poucos pontos, com modelos da mesma família trocando de posição entre uma rodada e outra.

Agora entraram Gemini 4 Argon, GPT-6.1 Sol, GPT-6.1 Terra, Kimi K3.1 Pro, Claude Sonnet 5.5 e Muse Wonder. Os seis caíram no Tier A.

E acho que esta será a última atualização que faço do ranking comercial, ou uma das últimas. Os modelos ficaram próximos demais.

Lembrando o que este benchmark mede

O llm-coding-benchmark não tenta medir “inteligência geral”. O v4 coloca cada agente pra desenvolver um sistema Rails durante sete sprints. No caminho, eu planto 14 sabotagens silenciosas: falhas de autorização, XSS, SQL injection, segredo fixo no código, CORS aberto, índice removido, teste adulterado pra aceitar comportamento inseguro.

Se o modelo encontra e corrige sozinho, recebe o peso inteiro. Se só conserta depois que a sabotagem é revelada, recebe 40%. Se nem depois disso resolve, recebe zero. A pontuação final é normalizada pra 100.

Portanto, esta é uma régua estreita de vigilância durante programação agentic de longa duração. Não mede se o modelo escreve o melhor texto, resolve matemática, entende direito tributário, desenha interface bonita ou depura firmware. Nem sequer mede tudo que importa em programação.

Nenhum benchmark consegue fazer isso, inclusive os mais populares. Modelos dessa classe podem ter bilhões de parâmetros, e as combinações entre prompt, contexto, ferramentas, harness, temperatura e estado anterior da conversa crescem muito além do que qualquer suíte consegue exercitar. Seria preciso testar praticamente tudo que pode entrar e sair do modelo. É impossível.

Por isso, discutir se o benchmark A é “melhor” que o benchmark B costuma começar pela pergunta errada. Cada um ilumina uma superfície minúscula. Testes estilo LeetCode e o HumanEval medem resolução de problemas curtos e bem definidos. SWE-bench mede correção de issues em repositórios existentes.

O meu acompanha um projeto crescendo por várias horas, com contexto acumulado, decisões anteriores e defeitos plantados que simulam o tipo de problema deixado por outro programador, outra equipe, uma dependência ou até pelo próprio agente.

Essa é uma situação mais próxima da programação real que eu faço, mas continua sendo apenas o meu recorte. Quem precisa de um modelo pra passar por qualquer variante possível de teste de contratação estilo LeetCode deve construir uma bateria pra isso. Uma nota excelente nesse tipo de exercício também não responde se o agente consegue manter um projeto por sete sprints, perceber uma autorização quebrada e não aceitar um teste adulterado.

Você precisa testar o seu caso de uso, com o seu código, suas restrições e seus critérios de falha. Foi por isso que deixei o framework inteiro open source: qualquer pessoa pode trocar a aplicação, os prompts, as sabotagens, os pesos e o harness. O ranking publicado aqui responde às minhas perguntas. Use a estrutura pra responder às suas.

Tem mais: já medi o mesmo GPT 5.5, no mesmo harness e com o mesmo teste, fazendo 100 numa rodada e 91 em outra. Essa é uma diferença de nove pontos criada só pela variância de uma amostra. LLMs geram respostas probabilísticas. Dois modelos separados por dois ou três pontos estão, na prática, no mesmo bolo.

Leia Tier A como uma faixa de modelos competentes, não como pódio olímpico. O primeiro colocado desta tabela não virou automaticamente o melhor modelo do mundo.

Ranking comercial atualizado

Pra não misturar placa local, pod alugado e API, a tabela abaixo mostra apenas modelos que testei por uma rota gerenciada: assinatura, API, OAuth ou plano comercial. Alguns têm pesos abertos, como Kimi e GLM, mas aqui foram usados pelo serviço do fornecedor.

Os modelos desta rodada estão em negrito. Mantive apenas o Tier A, porque é onde existe uma escolha séria pra trabalho diário.

Os custos com ~ são equivalentes calculados pela contagem de tokens e pela tabela pública, não a fatura que recebi. Claude Code, Codex e Muse Code rodam por assinatura; Antigravity usa OAuth; zcode cobra plano fixo. No Wonder, 126 minutos somam apenas as sete execuções concluídas. As tentativas travadas e as esperas de quota ficaram fora. Compare custo e tempo com cuidado, principalmente entre harnesses diferentes.

Terra e Kimi tiveram o item #8 marcado como não aplicável porque o estado exato daquele teste não permitia uma avaliação justa. O denominador deles ficou em 38, em vez de 40, e a nota foi normalizada. Nex continua com a ressalva antiga: encontrou os problemas, mas deixou o trabalho sem commit.

O que cada modelo mostrou

Gemini 4 Argon: finalmente chegou no topo

O Argon foi o único desta leva que pegou as 14 sabotagens antes da revelação: 40 de 40, nota 100. É o resultado que faltava pro Gemini entrar sem asterisco na conversa dos melhores agentes de programação.

O anúncio oficial do Gemini 4 Argon posiciona o modelo justamente pra problemas difíceis e disponibiliza acesso pelo Antigravity e pela API. O preço introdutório da API é US$ 2 por milhão de tokens de entrada e US$ 10 de saída; depois de 30 de novembro sobe pra US$ 4 e US$ 20.

No meu teste, usei Antigravity pela assinatura, então o custo marginal foi zero. Levou 114 minutos e resolveu tudo sem precisar que eu apontasse onde estavam as bombas.

GPT-6.1 Sol: quase perfeito, sem desperdício

O Sol fez 97,0. Encontrou 13 das 14 sabotagens sozinho e corrigiu a última depois da revelação. Levou 65 minutos, praticamente o mesmo tempo do Opus 5.5 e bem menos que os 317 minutos do antigo GPT 5.6 Sol.

Pela tabela oficial da OpenAI, custa US$ 2 por milhão de tokens de entrada e US$ 10 de saída. Aplicando essa tabela aos tokens da rodada, o equivalente ficou em cerca de US$ 8,12.

Não fez 100. Também não existe diferença prática demonstrável entre 97 e 100 numa metodologia em que o mesmo modelo já variou nove pontos. O dado útil é outro: Sol continua forte e ficou rápido.

Muse Wonder: excelente modelo, experiência péssima

O Muse Wonder também fez 97,0. Encontrou 13 das 14 sabotagens sem ajuda e terminou sem nenhuma pendência. A única perda veio no item composto de desempenho: corrigiu o N+1 sozinho, mas só restaurou o índice messages(role, created_at) depois da revelação. Foi a mesma aritmética do Sol, com 38 pontos detectados espontaneamente e dois pontos entrando com peso de 40%.

O resultado técnico foi forte. Wonder encontrou sozinho falhas de autorização, SQL injection, XSS, CORS aberto, dependência vulnerável e segredo fixo no código. Também adicionou testes de regressão. Olhando apenas o código entregue, pertence ao topo do Tier A.

Quinze dias pra terminar um teste de duas horas

Comecei a rodada em 13 de outubro. A primeira tentativa trabalhou por cerca de 33 minutos e bateu num HTTP 429 de quota. Fiz upgrade pro plano Power, anunciado pela Meta por US$ 50 mensais e 20 vezes o uso do plano básico, e ainda assim voltei a bater no limite. Em 14 de outubro, seis sprints estavam concluídas, mas a quota semanal bloqueou a revelação até o dia 19.

Deixei o benchmark de lado por alguns dias depois disso e só rodei a última sprint hoje, 28 de outubro. Minha pausa também entra nessa conta de quase 15 dias. A medida comparável da tabela é 126 minutos de execuções bem-sucedidas. A experiência real incluiu várias tentativas em que o Muse Code ficou silencioso por até uma hora rodando RSpec e testes de sistema, além das esperas de quota.

A nota do modelo foi 97. A experiência do produto foi a pior de todo o benchmark v4.

A própria Meta viu o problema. Em 12 de outubro, Alexandr Wang reconheceu um bug que fazia Wonder e Wonder Full consumirem quota rápido demais; a Meta corrigiu e resetou os limites. Em 14 de outubro, a versão 1.4.8 recebeu mais correções de eficiência, incluindo um erro que mandava parte dos usuários em Contributor mode pros modelos cobrados integralmente. Houve outro reset no dia seguinte.

Existe uma ressalva importante no meu ambiente. O benchmark isola HOME e XDG_CONFIG_HOME pra evitar que skills ou plugins pessoais contaminem o teste. A documentação atual da Meta diz que muse exec sem arquivo de configurações salvo inicia com Contributor mode desligado, o que oferece menos uso em troca de não entregar o código pra treinamento. Esse detalhe pode ter reduzido minha quota. Mesmo assim, o plano Power continuou incapaz de sustentar uma única rodada v4, e o próprio fornecedor confirmou problemas de contabilização na mesma semana.

Minha conclusão fica restrita ao que medi: Muse Wonder é muito competente, mas eu não confiaria hoje na assinatura e no harness pra uma sessão longa sem interrupção. Outro usuário, em outra configuração e depois das correções, pode ter uma experiência melhor.

GPT-6.1 Terra: a relação custo, velocidade e qualidade mais interessante

O Terra terminou com 96,8, praticamente empatado com Sol, em 21 minutos. O custo equivalente foi só US$ 1,69.

A página oficial do GPT-6.1 Terra lista US$ 1 por milhão de tokens de entrada e US$ 5 de saída, metade do Sol. Ele ainda oferece janela de contexto de 1,05 milhão de tokens, embora requisições acima de 272 mil tokens recebam multiplicador de preço.

Num dos itens, o Terra percebeu parte do problema sozinho, mas só fechou a correção inteira na revelação. Foi isso que tirou os poucos pontos. Mesmo assim, olhando o que interessa pra trabalhar, Terra é o resultado mais forte desta rodada: qualidade no mesmo bairro do Sol, três vezes mais rápido e cerca de cinco vezes mais barato nesta execução.

Kimi K3.1 Pro: competitivo, mas precisa correr mais

O Kimi K3.1 Pro fez 92,11, sem deixar nenhuma sabotagem sem correção no final. Dois grupos de problemas só foram fechados depois da revelação. O lado ruim foi o tempo: 110 minutos, quase cinco vezes o Terra, com custo equivalente de US$ 12,67.

O K3.1 Pro tem contexto de até 1 milhão de tokens e será disponibilizado com pesos abertos. A Kimi também oferece uma rota Highspeed, anunciada como duas a três vezes mais rápida, em troca de preço e consumo de quota maiores. A tabela pública cobra ¥13 de entrada e ¥68 de saída por milhão de tokens na rota regular; a Highspeed dobra esses valores.

Eu gosto do Kimi e uso no dia a dia. A nota confirma que ele está no grupo competente. O gargalo agora é latência. Modelo bom que me deixa esperando duas horas pra completar a mesma campanha que o Terra fez em 21 minutos perde utilidade prática.

Claude Sonnet 5.5: o score isolado conta a história errada

Sonnet 5.5 fez 88,0. Pegou a maior parte sozinho, resolveu mais alguns itens na revelação e não terminou de corrigir uma sabotagem composta: fechou a vulnerabilidade, mas deixou um teste de guarda adulterado com assert true. Esse tipo de detalhe é exatamente o que meu teste tenta encontrar. O sistema pode estar corrigido hoje, mas o teste inútil deixa a porta aberta pra regressão amanhã.

Ao mesmo tempo, ele concluiu tudo em 27 minutos, com custo equivalente de US$ 3,90. A Anthropic posiciona o Sonnet 5.5 como modelo de trabalho diário, com Opus reservado pra decisões mais difíceis. O preço é US$ 2 de entrada e US$ 10 de saída por milhão de tokens, e a empresa diz que a geração ficou mais de 30% mais rápida que no Sonnet 5.

Então não, 88 não transforma Sonnet em modelo ruim. Continua Tier A, é rápido e custa pouco. O gotcha concreto desta rodada é: pra review de autorização, teste de segurança e mudança delicada, eu ainda pediria uma segunda passada de Opus, Fable ou outro modelo forte.

O modelo mais caro não precisa ficar ligado o dia inteiro

Essa rodada reforçou uma mudança importante de hábito. Pra maioria do trabalho, já não preciso manter o modelo mais caro e pesado o tempo todo.

CRUD, refactor, teste, documentação, front-end comum, integração de API, migração de banco: Sonnet 5.5 e GPT-6.1 Terra já dão conta. Eu subiria pra Opus, Fable, Sol ou Astra quando o problema realmente justificar: depuração de driver no kernel, concorrência particularmente traiçoeira, firmware, ajuste delicado de sistema embarcado, incidente de segurança onde um detalhe perdido custa caro.

Usar Fable pra trocar a cor de um botão é como ligar uma escavadeira pra plantar manjericão. Funciona. Só não faz sentido gastar quota nisso.

Até os open source chegaram perto. No teste recente de Qwen3.8 Flash-Next numa única RTX 5090, a versão Q2_0 fez 100 nas seis rodadas do teste difícil, três no Strata e três no Basalt. Com Basalt, chegou a 400 tokens por segundo de saída, usando também a RAM do sistema pros experts.

Aquele teste é bem mais fácil que o v4, portanto as notas não podem ser misturadas. Mesmo no v4 completo, porém, já tivemos Qwen local na faixa de Tier A. A distância deixou de ser um abismo.

O gargalo mudou: velocidade e quota

Eu uso os modelos do topo todo dia e troco entre eles no mesmo projeto há semanas. Claude de manhã, Codex depois, Kimi quando a quota aperta, às vezes Gemini. Ainda não encontrei uma vantagem mensurável em ser fiel a um fornecedor.

O que eu sinto imediatamente é velocidade. GLM 5.3 e DeepSeek V4.1 são bons, mas parecem lentos quando coloco do lado de Terra ou Sonnet. Depois que você se acostuma com resposta rápida, esperar o agente pensar e editar vira a parte irritante do trabalho.

O outro limite é quota. Janelas de cinco horas, limites semanais ou mensais variam conforme fornecedor e plano, mas a realidade é a mesma: meu limite semanal raramente dura uma semana inteira. Fable e Astra queimam a reserva ainda mais rápido. Eu troco porque preciso, não porque quero fazer coleção de logo no terminal.

Foi exatamente pra isso que criei o ai-memory. A memória do projeto não deveria pertencer ao Claude, Codex, Kimi ou Gemini. Com ai-memory run, eu continuo a mesma linha de trabalho em outro harness sem fazer handoff manual, e as decisões consolidadas sobrevivem às compactações de contexto.

Modelo e harness são alugados. A sessão, as decisões e a memória do projeto precisam continuar sendo suas.

Já expliquei a arquitetura e o formato aberto na versão 2.0 do ai-memory. Quanto mais equivalentes os modelos ficam, mais importante se torna poder trocar sem atrito.

E os benchmarks famosos?

Continue olhando SWE-bench, que usa issues reais de projetos no GitHub, e Terminal-Bench, que mede agentes resolvendo tarefas num terminal. Eles ajudam a descobrir regressão, melhora em uso de ferramentas e algum edge case onde uma família ainda sofre.

Só não confunda isso com o seu trabalho. SWE-bench Verified tem 500 problemas selecionados. Terminal-Bench v4 tem dezenas de tarefas difíceis e revisadas. Nenhum deles sabe como é o seu monorepo, o nível dos seus testes, a qualidade da sua documentação, a biblioteca interna da sua empresa ou aquela API legada que ninguém ousa tocar.

Meu benchmark também não sabe.

Se você precisa escolher modelo pra uma restrição muito específica, construa seu próprio teste com exemplos reais. Se não precisa, escolha qualquer Tier A, use por uma semana e siga trabalhando.

E o tal GLM 5.5?

Tem rumor circulando de “GLM 5.5 chegando”. Até hoje, 28 de outubro, não existe anúncio oficial com esse nome, data ou preço. A página oficial de releases da Z.ai continua listando a família GLM 5.3 como a mais recente.

Jie Tang, fundador da Z.ai, respondeu “won’t take that long” quando Elon Musk estimou o primeiro trimestre de 2027 pra China alcançar modelos do nível do Fable. Isso sugere que ele espera esse nível antes, mas não promete um lançamento da Z.ai, muito menos um modelo chamado GLM 5.5 até dezembro. Não vou transformar rumor em linha de ranking.

Kimi K3.1 Pro já está no Tier A. Qwen e GLM já cabem em hardware próprio com quantização. Gemini finalmente encostou nos líderes.

Sonnet e Terra fazem trabalho diário por muito menos. A competição está comprimindo tudo pro mesmo patamar.

Commoditizou. Ótimo.

Não espero mais saltos enormes a cada versão comercial. Espero modelo um pouco mais rápido, barato, econômico em token, com quota melhor e um ou outro edge case corrigido. Isso é maturidade de mercado.

Meu conselho hoje é diferente do conselho de alguns meses atrás:

1. Escolha qualquer modelo Tier A que caiba no seu plano.
2. Use Sonnet ou Terra no trabalho comum.
3. Guarde Opus, Fable, Sol ou Astra pros problemas que merecem.
4. Mantenha uma segunda opção pra quando a quota acabar.
5. Instale ai-memory pra não ficar preso ao histórico de nenhum harness.
6. Pare de acompanhar ranking como campeonato de futebol.

Benchmark continua útil pra detectar quando uma família alcançou o grupo de cima, como o Argon acabou de fazer. Depois disso, a diferença entre primeiro, quarto e décimo lugar é pequena demais, ruidosa demais e dependente demais da tarefa.

As LLMs de fronteira viraram commodity. Você não está perdendo nenhuma revolução porque passou uma semana sem testar o lançamento da terça-feira. Escolha uma boa, mantenha suas opções abertas e volte a programar.

Um ranking mais amplo: Engineering Breadth Index

Depois de terminar este texto, fiquei com uma pergunta melhor. O que acontece se eu combinar meu resultado com benchmarks que medem outras partes do trabalho?

Montei um índice secundário com quatro superfícies:

Os percentuais brutos não podem ser somados. O líder do Terminal-Bench 4.0 faz 65,15; no meu, vários fizeram 100. Primeiro normalizei cada resultado contra o melhor resultado publicado pelo próprio benchmark naquela fotografia:

nota normalizada = 100 × nota do modelo / melhor nota do benchmark

Depois apliquei uma média geométrica ponderada. Ela pune modelos com uma fraqueza grande em alguma dimensão, em vez de deixar uma nota perfeita esconder o buraco.

índice = 100 × exp(
  0,35 × ln(SWE Pro) +
  0,30 × ln(Akita v4) +
  0,25 × ln(Terminal-Bench) +
  0,10 × ln(LiveCodeBench)
)

Cada parcela entra como número entre zero e um. O índice mede capacidade. Preço, duração, tok/s e quota ficam fora e devem aparecer numa tabela de praticidade separada. Misturar qualidade com dólar faria um modelo fraco e barato parecer tecnicamente melhor.

O resultado de 28 de outubro de 2026

Já esbarramos na primeira limitação honesta. Até 28 de outubro, o leaderboard oficial do LiveCodeBench v6 ainda não mostrava resultados pros modelos desta geração. Portanto, não existe ranking oficial completo de quatro dimensões hoje.

Calculei o provisório com os outros três benchmarks, que cobrem 90% do peso. Usei o snapshot de 28 de outubro do SWE-bench Pro V2 e a atualização de 26 de outubro do Terminal-Bench 4.0. Renormalizei os pesos disponíveis: 38,89% pro SWE-bench Pro V2, 33,33% pro meu v4 e 27,78% pro Terminal-Bench 4.0. Só entrou modelo com resultado exato nos três. Nada de usar Kimi K3 no lugar do K3.1 ou GPT-5.6 Terra no lugar do 6.1 Terra.

Ranking provisório

O Terminal-Bench 4.0 usa mini-SWE-agent em todas as linhas. O SWE-bench Pro V2 mistura mini-SWE-agent com os harnesses nativos mostrados na tabela. No meu v4, cada linha mantém a rota documentada naquela rodada. Gemini 3.8 Flash é a execução no Antigravity; Muse Spark Open rodou self-hosted em quatro B300, pelo OpenCode.

Este é um ranking de modelo nas condições publicadas por cada benchmark, com influência real do harness. Não serve pra isolar cientificamente apenas os pesos do modelo.

Por que a lista para no 13

Eu queria chegar pelo menos a 20 modelos, mas o cruzamento honesto acaba aqui. O SWE-bench Pro V2 publica 16 resultados. Desses, só 13 têm exatamente o mesmo modelo testado também no Terminal-Bench 4.0 e no meu v4. Os próximos candidatos esbarram numa lacuna:

Eu poderia renormalizar duas notas e inventar posições 14 a 22. O número sairia bonito e enganoso. Um modelo medido só no meu v4 e no Terminal-Bench teria 55% da cobertura original; outro medido no SWE Pro e no Terminal teria 60%. Ordenar os dois como se tivessem passado pela mesma prova transformaria ausência de dado em precisão falsa.

Também não vou usar Kimi K3 no lugar do K3.1, GPT-5.6 Terra no lugar do 6.1 Terra ou qualquer parente da mesma família pra preencher buraco. Quando esses resultados forem publicados ou eu rodar os modelos que faltam, o índice cresce. Até lá, 13 é o limite defensável.

O que mudou quando abrimos a lente

Astra ficou 0,036 ponto à frente do Argon antes do arredondamento: 96,5955 contra 96,5591. Ambos aparecem como 96,6 na tabela e formam um empate prático. Fable 5.1, Opus 5, Sonnet 5.5 e Sol 6.1 vieram logo atrás. Diferenças menores que três pontos devem ser lidas como a mesma faixa, ainda mais misturando benchmarks com intervalos de confiança e harnesses diferentes.

Sonnet 5.5 é o caso mais interessante. Fez só 88 no meu teste, mas chegou a 64,14 no Terminal-Bench, quase o teto atual. O índice mais amplo puxou o modelo pra 94,1. GPT-5.6 Sol mostra o inverso: 100 no meu teste e apenas 37,88 no Terminal-Bench, terminando em 84,7.

Isso responde por que vale combinar superfícies. Um benchmark sozinho enxerga bem o que foi desenhado pra enxergar. Três benchmarks continuam longe de medir tudo, mas já dificultam que uma especialidade isolada se passe por competência geral.

Mesmo assim, a conclusão anterior continua de pé. Os seis primeiros estão comprimidos entre 93,2 e 96,6. A lente ficou mais ampla e o suposto campeão absoluto continuou sem aparecer.

Conclusão: escolha um bom e trabalhe

O índice composto reforçou a tese deste artigo. Quando ampliamos o teste, a ordem muda, algumas fraquezas aparecem e o grupo da frente continua espremido. Astra e Argon ficaram separados por 0,036 ponto. Quatro outros modelos ficaram a menos de 3,5 pontos. Com outra distribuição de pesos, outro conjunto de tarefas ou uma nova versão dos benchmarks, eles podem trocar de posição de novo.

Isso deixa uma decisão bem mais simples. Primeiro descubra quais modelos já atingiram a faixa competente pro seu tipo de trabalho. Depois escolha por velocidade, preço, quota, privacidade, disponibilidade e qualidade do harness. Essas diferenças afetam seu dia inteiro. Um ponto a mais numa tabela raramente afeta.

Ainda vale acompanhar benchmarks pra detectar regressões, descobrir quando uma família alcançou o Tier A e enxergar pontos cegos. Não vale transformar ranking em torcida ou tratar o primeiro colocado desta semana como verdade universal.

Hoje eu alterno entre os melhores sem cerimônia. O projeto, os testes, o Git e a memória da sessão precisam sobreviver à troca. Por isso insisto tanto no ai-memory: o ativo importante é o histórico do trabalho, não o fornecedor que alugou a janela de contexto. Escolha qualquer modelo competente, mantenha uma rota de fuga e volte a resolver problemas reais.

O problema continuava sendo a máquina. Um modelo de 510 GB que precisa de quatro B300 pode ser open source no GitHub, mas continua fora do alcance de quem quer rodar uma IA no escritório de casa.

Voltei pra minha RTX 5090 e pro Strix Halo. Desta vez, em vez de repetir o benchmark v4 inteiro em dezenas de modelos que já sabemos que não cabem ou não têm velocidade, peguei o candidato mais promissor e fui comparar as quantizações dele. Qual versão entrega qualidade suficiente sem transformar cada interação numa espera de vários minutos?

O resultado me surpreendeu: a versão de 2 bits ganhou. Depois repeti o teste com o Basalt, um fork do Strata especializado nas GPUs Blackwell. O modelo continuou acertando tudo e a geração chegou a 400 tokens por segundo. A quantização não mudou; o engine mudou bastante o resultado.

A RTX 3090 e a 4090 ganharam uma sobrevida

Antes dos meus resultados, a comunidade descobriu uma limitação que dava pra remover. Nas GeForce RTX 20, certas operações Tensor Core FP16 com acumulação em FP32 rodam com metade da taxa teórica de emissão por ciclo das equivalentes profissionais. Nas RTX 30 e 40, o limite também atinge BF16.

O hardware está lá. Dois registradores internos selecionam a velocidade, e o driver normal não tem privilégio pra alterá-los.

O projeto gpu-unlock encontrou uma forma de mudar esses registradores antes do driver da NVIDIA assumir a placa. No Ampere, isso explora um buffer overflow no Booter assinado que autentica e carrega o GSP-RM. Nada é gravado na VBIOS. Pra voltar ao comportamento original, você remove o parâmetro de ativação e desliga a máquina por completo, porque os seletores voltam ao padrão quando a placa perde energia. Se o parâmetro continuar ativo, o módulo reaplica o unlock no próximo boot.

Também exige Linux, initramfs e bastante cuidado. Eu não recomendo sair instalando isso numa workstation de produção sem ler o código e entender o risco.

É um hack da comunidade, sem suporte oficial da NVIDIA. Você instala por sua conta e risco. O interesse pra LLM está em acelerar prefill quando o engine usa exatamente esse caminho dos Tensor Cores. Outras aplicações de compute, como alguns pipelines de geração de imagem, também podem mudar de desempenho. Jogos dependem de outros gargalos e caminhos da GPU, então não espere ganhar FPS com isso.

Numa RTX 3090 a 420 W, um teste controlado mediu FP16 com acumulação em FP32 de 76,396 pra 125,006 TFLOPS; BF16 foi de 76,994 pra 127,923. Na 4090, uma implementação ainda experimental mediu aproximadamente o dobro da taxa de instruções FP16 e BF16.

Só que dobrar TFLOPS não dobra sua LLM. O teste que motivou esta discussão separou as duas fases:

• Prefill é quando o modelo lê o prompt inteiro. Há muitos tokens disponíveis ao mesmo tempo, então o motor consegue montar operações matriciais grandes e paralelas. Uma 3090 ganhou 14,4% numa carga de 16K tokens, enquanto uma dupla de 3080 modificadas ganhou 33% a 36% com vLLM.
• Decode é quando o modelo gera um token depois do outro. Em LLM quantizada com expert-offload, essa etapa fica limitada principalmente por banda de memória, RAM, PCIe e cache de especialistas. O ganho medido ficou dentro do ruído.

O ganho varia bastante com engine, quantização e tamanho do prompt. Na dupla de 3080, o Qwen3.8 Flash-Next Q4_K_XL ganhou só 0,5% a 0,8% em 8K, mas chegou a 12% ou 13% em 32K e 128K. Num MoE IQ3_S testado numa 3090, uma carga perto de 32K não mudou. A rota de cálculo usada por uma quantização pode nem passar pelo caminho FP16/BF16 que foi liberado.

O gpu-unlock acelera um caminho específico dos Tensor Cores. Ele pode reduzir a espera pra ler prompts grandes, mas não transforma 24 GB em 96 GB e nem cria banda de memória.

Mesmo com essa ressalva, 3090 e 4090 ficaram mais interessantes pra inferência local. Uma RTX 3090 usada ainda tem 24 GB de VRAM, NVLink na geração dela e 936 GB/s de banda. A comunidade mediu o Qwen3.8 Flash-Next em aproximadamente 75 tok/s com IQ3_S e 100 tok/s com Q2_0 numa única 3090. Com duas placas, há relatos entre 90 e 120 tok/s, dependendo da configuração e do tamanho do contexto. Esses resultados são da comunidade, não desta rodada.

Por que eu escolhi o Qwen3.8 Flash-Next

No v4, os candidatos abertos que realmente me interessaram foram:

Os três empataram dentro da margem de ruído. Só o Qwen repetiu a qualidade numa máquina de consumidor. O modelo principal é um MoE de 125 bilhões de parâmetros, com aproximadamente 6 bilhões ativos por token, mais 51 bilhões em embeddings n-gram e uma cabeça MTP de 4 bilhões. O Strata deixa os especialistas mais usados na GPU, mantém os demais na RAM pra CPU calcular, lê a tabela n-gram do SSD e usa a camada MTP do próprio modelo pra especular os próximos tokens.

O backbone e o Engram do DeepSeek V4.1 somam aproximadamente 748 bilhões de parâmetros: 552 bilhões do backbone e 196 bilhões do Engram. O checkpoint publicado tem cerca de 763 bilhões no total. Eu servi a versão nativa mista FP4/FP8, de cerca de 510 GB, no pod de quatro B300.

Também consegui iniciar uma versão de 2 bits na 5090 com o engine dedicado do Strata. Ela gerou por volta de 17 tokens por segundo. Tecnicamente roda. Pra agente de programação, está fora da disputa.

O checkpoint NVFP4 do GLM 5.3 Flash tinha cerca de 198 GB e foi servido na B300. Não existe neste repositório uma configuração de consumidor que eu tenha medido e possa recomendar. O GLM 4.7 Flash menor já tinha feito 24 pontos na 5090 e 33,5 na B300 no benchmark anterior. Gastar dias tentando fazer a família errada caber não produziria informação útil.

Também deixei Qwen 4 e Llama fora por escolha. Esta rodada tem uma pergunta estreita: qual versão do modelo que já provou qualidade funciona melhor nas duas máquinas que eu tenho?

O que eu testei

Todo o código, os prompts, os testes escondidos e os resultados estão no llm-opensource-benchmark. Testei quatro versões do Qwen3.8 Flash-Next:

Os arquivos do Strata incluem uma parte comum de PLE, então o tamanho total não cabe diretamente na VRAM. O engine faz o trabalho de distribuir os especialistas entre GPU e RAM. No Basalt, usei os packs próprios do projeto: um arquivo .basalt de 64,9 GiB pro Q2_0 e outro de 81,0 GiB pro IQ3_S. Cada arquivo já reúne pesos, tokenizer, MTP, perfil de especialistas e projetor de visão.

Na primeira rodada da RTX 5090, usei o backend CUDA do Strata com:

• 4 GiB de VRAM reservados pro Hyprland, navegador e terminal;
• cache de KV em int8, contexto máximo de 128K e 32K residentes na GPU;
• cache elástico de especialistas;
• especulação de quatro tokens com o MTP do modelo.

Depois rodei Q2_0 e IQ3_S no Basalt, na mesma 5090 e com os mesmos 131.072 tokens de contexto máximo e KV em int8. Deixei 4.608 MiB reservados porque o Basalt contabiliza seus buffers de trabalho nessa margem. A VRAM livre ficou entre 3,6 e 4,4 GB durante os testes.

No Strix Halo, usei o backend hip-halo. Essa máquina tem 64 GB reservados pra GPU e GTT de 31 GB mapeado sobre a RAM do sistema; o limite de RAM do engine era 61,9 GiB. Como ela é headless, deixei a GPU inteira pro modelo e mantive 8 GiB de folga pro cache da conversa.

Nas medições do Strata são dois backends diferentes por baixo, CUDA na NVIDIA e HIP/ROCm na AMD, mas o mesmo engine e a mesma API compatível com OpenAI. O Basalt acrescenta uma comparação de engine na 5090, usando o mesmo OpenCode, os mesmos prompts e a mesma correção.

A metodologia

Comecei com um teste de velocidade em três situações:

1. prompt frio de 4K tokens;
2. prompt frio rotulado como 32K, que o tokenizer do modelo contou como 42.400 tokens;
3. continuação da mesma conversa, reaproveitando o cache.

Cada uma gera 256 tokens. O runner mede tempo até o primeiro token, leitura do prompt, geração, VRAM, RAM, potência e temperatura.

O que cada número de velocidade quer dizer

Quando alguém diz que uma LLM faz 200 tokens por segundo, quase sempre está falando só da geração. Uma sessão de agente passa por fases diferentes, e cada uma encosta num gargalo diferente.

Prefill é a leitura inicial do prompt. O modelo precisa processar as instruções do harness, histórico da conversa, arquivos e sua pergunta antes de soltar a primeira palavra. Como todos esses tokens já estão disponíveis, a GPU consegue trabalhar com matrizes grandes em paralelo.

Essa fase aproveita melhor Tensor Cores e poder bruto de cálculo. Quanto maior o contexto, mais ela pesa.

O KV cache guarda os estados intermediários dos tokens já processados. Numa continuação da mesma conversa, o modelo reaproveita esse estado em vez de ler tudo de novo. Por isso o teste de append chega a dezenas de milhares de prompt tokens por segundo e recebe o primeiro token em cerca de meio segundo. Esse número mede reaproveitamento de cache; comparar com prefill frio seria fraude.

O KV também cresce com a conversa e disputa memória com pesos, especialistas e buffers. Aqui ele está em int8, com 32K residentes na 5090. Contexto máximo anunciado, contexto que cabe e contexto que continua rápido são três números diferentes.

Speculative decoding usa uma camada de draft pra propor vários tokens e o modelo principal verifica o lote. Quando a taxa de aceitação é boa, o output tok/s sobe. Se o draft erra muito, o ganho desaparece. As velocidades do Strata já incluem MTP com especulação de quatro tokens. O Basalt também usa o MTP incluído no próprio pack, com seu mecanismo de especulação e seus defaults.

E falta uma métrica que eu não medi aqui: concorrência. Todos estes números são de um único stream. Um servidor pode atender várias sessões e aumentar a vazão agregada, mas cada usuário tende a receber menos tokens por segundo.

Pra uso individual, single-stream e wall time mandam. Pra uma equipe, precisa medir sessões simultâneas e latência por usuário, como fiz no teste com B300 e H200.

Depois vieram dois testes de programação usando OpenCode 2.1.4. O modelo recebe uma pequena base Python, trabalha em uma sessão contínua e nunca vê os testes escondidos. Tudo roda em Bubblewrap, sem rede, com filesystem limitado e apenas um gateway local que aceita as chamadas pro modelo esperado.

O primeiro canário tem três turnos e 9 testes escondidos. O modelo precisa implementar um analisador de logs, corrigir bugs e lidar com mudança de requisitos.

O teste difícil tem quatro turnos e 36 testes escondidos. É um reconciliador de pagamentos com decisões enterradas num histórico de cerca de 79K tokens, uma decisão corrigida mais tarde, propostas rejeitadas servindo de distração, dinheiro que exige decimal exato e regras novas que interagem com as anteriores. Com o system prompt do OpenCode, o primeiro turno chega perto de 83K tokens.

Uma régua separada do benchmark v4

Estes canários são muito menores e mais fáceis. No v4, o modelo trabalha num aplicativo Rails por sete sprints enquanto um revisor injeta 14 defeitos de segurança e de correção. A nota mede quantos ele encontra e corrige sozinho antes da revelação. É um teste de vigilância, com muito mais código, ferramentas e oportunidades de se perder.

Aqui são duas bases Python pequenas, três ou quatro turnos e testes funcionais escondidos. Eu montei essa régua pra comparar quantizações do mesmo Qwen e descobrir se reduzir os bits quebra requisitos, contexto ou processo. A comparação termina aí, sem ranquear Qwen contra Opus, GPT, DeepSeek ou qualquer outro modelo.

A nota 100 deste artigo pertence a outra escala, sem equivalência com 100 do v4. Ela também não torna o Q2_0 “melhor” que o IQ3_S que fez 91 no v4. O v4 escolheu o Qwen como candidato; este teste menor escolhe qual arquivo do Qwen vale carregar em casa.

Velocidade sem qualidade só faz o modelo errar mais rápido. Por isso eu medi as duas coisas separadamente.

Ranking de velocidade

RTX 5090 com Strata, 4 GiB preservados pro desktop

RTX 5090 com Basalt

Strix Halo, usando a GPU inteira

A 5090 tem 32 GB de GDDR7 e 1.792 GB/s de banda. O Strix tem mais capacidade total, mas seus aproximadamente 256 GB/s precisam servir o sistema inteiro. Mesmo usando o Strata nos dois, a diferença aparece principalmente no prefill: 6,9 segundos contra quase 2 minutos pra começar a responder a carga de 42.400 tokens. No Basalt, a 5090 baixou essa espera pra 4,9 segundos.

O Q4 foi o pior dos dois mundos. Na 5090 ele rodou devagar e o systemd-oomd matou o teste de qualidade. No Strix, zerou a VRAM, começou a paginar e travou a máquina até reboot. Mais bits preservam mais informação, mas ocupam mais memória e reduzem o cache quente que faz esse MoE andar.

Basalt contra Strata

O Basalt nasceu como fork do Strata, só que tomou uma direção mais específica: Linux ou Windows, CUDA 13 e GPU NVIDIA Blackwell com compute capability 12.0. A 5090 entra exatamente nesse alvo. O Strata continua muito mais abrangente e foi o que permitiu rodar o mesmo Qwen no Strix Halo com AMD.

Os dois resolvem o mesmo problema central. Na configuração testada, os especialistas que não cabem na VRAM ficam na RAM, enquanto a GPU mantém uma parte quente. Basalt e Strata expõem API compatível com OpenAI e Anthropic e aceleram a geração com seus drafters MTP. O Basalt empacota tudo num único arquivo e traz kernels, gerenciamento de memória e execução especulativa trabalhados especificamente pra Blackwell.

Este foi um A/B prático entre stacks completos, sem isolar uma única otimização. Os packs são próprios de cada engine, os defaults não são idênticos e o Basalt reservou 4.608 MiB de VRAM contra 4.096 MiB do Strata. Mantive a mesma RTX 5090, as mesmas quantizações, contexto máximo de 131K, KV em int8, mesmo OpenCode e os mesmos testes.

Nesse A/B, o Basalt ganhou em todas as métricas de velocidade e empatou nos resultados funcionais de código. O Q2_0 saiu de 223 a 259 pra 377 a 400 tokens por segundo. A leitura da carga longa foi de 6.158 pra 8.573 tokens por segundo, e a espera pelo primeiro token caiu de 6,9 pra 4,9 segundos. No IQ3_S, a geração saiu da faixa de 158 a 208 pra 223 a 231 tokens por segundo.

O recorte de plataforma decide a escolha. Numa RTX 5090, eu começaria pelo Basalt. No Strix, em NVIDIA anterior a Blackwell ou em outro hardware suportado, o Strata continua sendo o caminho. O Strata cobre justamente os lugares onde o Basalt nem roda.

Ranking de qualidade

O teste simples não separou nada:

Todas passaram os 9 testes escondidos, preservaram os requisitos e terminaram com a suíte visível verde. Precisei aumentar a dificuldade.

No canário difícil, rodei Q2_0 e IQ3_S três vezes cada na 5090 com Strata:

As duas acertaram tudo nas três rodadas. Encontraram as decisões no contexto longo, respeitaram a correção posterior, lidaram com eventos fora de ordem, chargebacks, câmbio e fizeram o refactor final. Também passaram por quantidade parecida de testes quebrados enquanto trabalhavam.

A diferença ficou no relógio. Q2_0 levou 7,2 minutos em média. IQ3_S levou 12,1. O modelo de 2 bits entregou o mesmo resultado em aproximadamente 60% do tempo.

Depois repeti as seis rodadas no Basalt:

A penalização que derrubou a segunda rodada do IQ3_S pra 96 foi um falso positivo conhecido do harness. O modelo executou ps aux dentro do sandbox, e o comando mostrou a linha do próprio bwrap, que contém caminhos do host. O detector interpretou isso como tentativa de acessar os testes escondidos e tirou quatro pontos. O modelo não usou esses caminhos, os testes escondidos só são montados depois, na correção, e os 36 passaram.

No Basalt, o Q2_0 levou 5,4 minutos em média, contra 7,2 no Strata. O IQ3_S caiu de 12,1 pra 9,0 minutos. O ganho de ponta a ponta é menor que o salto de tokens por segundo porque a sessão também gasta tempo executando ferramentas e testes, e cada rodada gerou uma quantidade diferente de texto.

A evidência vale para bases Python pequenas, com contexto de até uns 85K tokens, e apenas três repetições por combinação de engine e quantização no canário difícil. Quantização de 2 bits costuma sofrer primeiro em contexto acima de 100K e em bases maiores. Dentro do uso que medi, gastar mais bits não comprou nenhuma qualidade.

O que cada versão mostrou

Q2_0: a recomendação atual

Foi a quantização que gerou tokens mais rápido nas três combinações de máquina e engine, e terminou as seis rodadas difíceis com nota máxima. No prefill longo do Strata na 5090, o IQ3_S ganhou por uma margem mínima. Com Basalt, o Q2_0 chegou a 400 tokens por segundo. No Strix, 55 a 65 tokens por segundo é utilizável, embora o prefill longo cobre quase dois minutos antes da primeira resposta.

Eu usaria esta versão no dia a dia e guardaria a ressalva de contexto. Projeto grande, sessão chegando em 100K ou comportamento estranho? Repito o mesmo trabalho em IQ3_S antes de culpar o modelo.

IQ3_XXS: ficou sem função clara

Passou no canário simples e foi rápida, só que perdeu pro Q2_0 em velocidade e ocupa mais espaço. Eu não rodei as três repetições do teste difícil nela, então não tenho dado pra prometer uma vantagem de qualidade.

IQ3_S: a opção conservadora

Continua sendo a versão que eu escolheria pra validar um resultado suspeito da Q2_0. Ela já tinha feito 91 no benchmark v4 na 5090, a apenas 1,5 ponto da versão NVFP4 na B300. No Basalt, ficou entre 223 e 231 tokens por segundo, praticamente a faixa que o Q2_0 alcançava no Strata, e ainda leu prompts mais rápido.

O próprio Basalt mede a proximidade das quantizações contra Q8_0. No teste de 100 chunks, o IQ3_S manteve o mesmo token no topo em 87,16% das posições. É uma régua diferente dos meus canários, mas reforça seu papel de opção conservadora. Nos meus testes de código, essa precisão extra ainda não encontrou nada que o Q2_0 tivesse perdido.

UD-Q4_K_XL: qualidade que não cabe não serve

Era a candidata intuitiva a entregar mais fidelidade. Faltou memória pra chegar ao teste que confirmaria isso. Na 5090, caiu pra menos de um quarto da velocidade da Q2_0 e o sistema matou a rodada. No Strix, a máquina travou.

Serve como lembrança de que a maior quantização compatível no papel pode ser a pior configuração real. Um MoE depende do espaço que sobra pra especialistas, KV cache, buffers e o próprio sistema operacional.

Qual hardware vale a pena?

RTX 3090 e 4090: boas se você já tem

As duas têm 24 GB, e isso limita o cache de especialistas. O gpu-unlock melhora prefill em workloads que usam o caminho liberado, mas decode continua preso em memória e offload. Uma 3090 usada, principalmente duas com NVLink, pode formar uma máquina local interessante. Eu não compraria uma 4090 nova hoje só pra isso: continua com 24 GB, custa caro e o unlock de Ada ainda é experimental.

Pra ambas, começaria pelo Qwen3.8 Flash-Next Q2_0 e mediria meu workload. Os aproximadamente 100 tokens por segundo publicados pela comunidade numa única 3090 já colocam a placa numa faixa prática. Duas 3090 aumentam a capacidade e podem ficar entre 90 e 120 tokens por segundo, mas não dobram automaticamente a velocidade. A conta inclui consumo, calor, fonte e pelo menos 128 GB de RAM.

Strix Halo: muita capacidade, pouca banda

É uma boa caixa headless, compacta e econômica. A memória unificada deixa rodar modelos que uma GPU de 24 ou 32 GB recusaria. Neste teste, o melhor modelo também foi o Q2_0, a 55 a 65 tokens por segundo.

O problema aparece toda vez que o agente lê contexto grande. Quase dois minutos pra processar a carga longa do teste acumulam rápido durante uma sessão. Eu usaria como servidor privado pra tarefas assíncronas, agentes simples e workloads onde capacidade vale mais que resposta imediata.

RTX 5090: o melhor ponto caseiro hoje

A RTX 5090 tem 32 GB, 21.760 CUDA cores e a mesma banda nominal de 1.792 GB/s da RTX PRO 6000. O que falta é capacidade: preciso reservar 4 GiB pro desktop e usar RAM e SSD pros especialistas que não cabem.

Com Strata, ela colocou o Q2_0 em 223 a 259 tokens por segundo e leu a carga longa a 6.158 tokens por segundo. Com Basalt, chegou a 400 e 8.573, respectivamente. É a primeira configuração local que não me faz sentir que estou esperando a máquina a cada passo. E é uma placa que também serve pra jogos, geração de imagem, vídeo e todo o resto da workstation.

RTX PRO 6000: três vezes a VRAM, preço de servidor

A RTX PRO 6000 Blackwell tem 96 GB de GDDR7 ECC, 24.064 CUDA cores e os mesmos 1.792 GB/s de banda. A capacidade extra deixa muito mais especialistas residentes, abre espaço pra quantização maior e comporta contexto sem disputar os últimos gigabytes com o desktop.

Ela custa US$ 16 mil na loja da NVIDIA, oito vezes o preço sugerido de US$ 1.999 da 5090. Eu ainda não rodei este benchmark nela, então não vou inventar uma velocidade. A banda igual à 5090 significa que três vezes a memória não viram três vezes mais tokens por segundo. O ganho está em manter mais coisa na placa e evitar o caminho lento de RAM e PCIe.

Pra uso individual, a conta da 5090 fecha melhor. A PRO 6000 começa a fazer sentido quando 96 GB resolvem um modelo que você realmente precisa, quando ECC e suporte profissional importam ou quando várias sessões vão dividir a mesma placa.

O veredito

O open source local finalmente entrou numa faixa prática. Uma única 5090 roda um modelo que fez Tier A no meu benchmark v4 e, com Q2_0 no Basalt, chegou a 400 tokens por segundo no canário. O Strix também ficou muito melhor do que os 7,7 tokens por segundo do Qwen denso que eu tinha testado antes.

Ainda existem limites claros. O contexto custa memória, o desktop precisa da mesma VRAM e qualquer especialista fora da placa atravessa PCIe ou cai na RAM. DeepSeek a 17 tokens por segundo mostra que “rodou” continua sendo uma métrica inútil. Se cada iteração leva várias horas, a qualidade do modelo deixa de importar porque ninguém consegue trabalhar desse jeito.

Pra hardware caseiro, o melhor modelo é o que mantém qualidade suficiente na velocidade que deixa você iterar. Nesta rodada, foi o Qwen3.8 Flash-Next Q2_0 no Basalt, numa RTX 5090.

O repositório do benchmark tem os runners, configurações, resultados brutos e testes escondidos. Repita na sua máquina e mande resultados. Hardware, engine, quantização e contexto mudam a resposta. Ranking pronto serve como ponto de partida; a decisão final continua sendo medida no seu trabalho.

O modelo constrói um projeto Rails em sete sprints e precisa encontrar 14 defeitos de segurança e correção plantados no caminho. Eu meço se ele percebe uma backdoor, um bypass de autorização, um teste adulterado ou uma conta errada antes que alguém entregue a resposta. É uma régua de vigilância durante programação. Nunca foi uma prova de inteligência universal.

Enquanto eu fechava essa série, alguns colegas que trabalham com investimentos e Direito começaram a discutir se um modelo aberto já serviria nas rotinas deles. A conversa deixou uma coceira: como eu poderia medir isso sem cair em prova de múltipla escolha ou pergunta de trivia jurídica?

Tentei responder. E já começo com a ressalva que manda no resto deste artigo.

Eu não sou contador, não tenho CPA, nunca passei na OAB e tenho zero experiência profissional trabalhando em escritório contábil ou jurídico. Consigo conversar sobre os assuntos e ler o material, porém não tenho condição de certificar se esta suíte representa bem o trabalho diário dessas profissões.

Portanto, trate tudo daqui pra frente como um experimento que precisa do escrutínio de contadores e advogados de verdade. Os números ajudam a comparar os modelos dentro desta suíte. Eles não certificam nenhum modelo para atender clientes, assinar parecer, fechar balanço ou protocolar peça.

O que eu tentei medir

Alguns dos profissionais com quem conversei já usam Claude ou GPT no trabalho, com modelos como Fable, Opus, Astra ou Sol. Parti dessa realidade em vez de fingir que conseguiria escrever sozinho uma prova profissional.

Pedi ao Fable 5.1 para desenhar casos dentro do que ele próprio tinha confiança para pesquisar, estruturar e revisar. A suíte usa padrões de trabalho, legislação, formulários, decisões e materiais de referência, mas todos os clientes, empresas e documentos são sintéticos. Nenhum dado confidencial real entrou no repositório.

Depois rodei o GPT-6 Sol como âncora de fronteira. Finalmente, peguei os modelos abertos que tinham ido bem nos testes de programação e rodei a mesma suíte em três classes de infraestrutura: RTX 5090, Strix Halo e NVIDIA B300 alugada.

Uso “aberto” no mesmo sentido do benchmark anterior: checkpoint que eu consigo baixar e servir por conta própria. As licenças variam e nem todo peso aberto atende à definição mais rigorosa de software open source.

O Fable também fez a correção cega. Cada configuração recebeu uma letra aleatória, e um subagente separado avaliou cada caso sem saber qual modelo tinha produzido a resposta. Então a comparação deste artigo significa algo bem restrito:

Quão perto estes modelos abertos chegaram do Sol, numa prova criada e corrigida pelo Fable?

Fable e Astra não fizeram a suíte como candidatos. Sol é a única âncora fechada desta rodada. O próprio Fable limita o que conseguimos perguntar e julgar, e um avaliador de IA pode errar. A revisão de uma amostra por profissionais humanos ainda está pendente.

O teste começa com uma pasta de cliente

O benchmark tem 38 casos, divididos entre contabilidade e Direito nos Estados Unidos e no Brasil. Como alguns casos atravessam várias sessões, a campanha inteira soma 63 unidades de sessão por configuração e 190 execuções avaliadas.

A distribuição ficou assim:

São quatro casos L1, seis L2, 22 L3 e seis L4. A dificuldade não vem de pedir uma resposta mais rebuscada. Ela cresce com o volume de documentos, a quantidade de regras que interagem e o tempo durante o qual o modelo precisa manter uma linha de raciocínio.

• L1, estagiário ou clerk: um ou dois documentos, uma entrega e uma resposta verificável. Um exemplo é calcular prazos a partir de uma intimação no DJe.
• L2, sênior: vários documentos, algum limite ou regra que interage com outra e pelo menos um fato que precisa ser perguntado ao cliente. Aqui entram escolha de regime tributário e revisão de contrato contra um playbook.
• L3, gerente ou associate: fontes conflitantes ou superadas, falsos positivos e decisões que precisam ser justificadas. A maior parte da suíte está aqui.
• L4, sócio: de três a doze sessões. Um fato novo derruba trabalho anterior, a outra parte reage e o modelo precisa corrigir o curso sem esconder a mudança.

Os seis casos L4 são doze fechamentos mensais de uma empresa SaaS, um devedor em Chapter 11, um trimestre de Lucro Real, uma recuperação judicial, um litígio americano em cinco sessões e uma execução fiscal brasileira também em cinco sessões. Somados aos casos de sessão única, eles levam cada configuração às 63 unidades de sessão. Como rodei cinco configurações, foram 315 sessões de trabalho dentro das 190 execuções.

Cada caso tenta parecer uma pequena contratação profissional. O modelo recebe:

• uma pasta com contratos, extratos, notas fiscais, petições, planilhas e outros documentos;
• uma biblioteca fechada com as normas e autoridades permitidas, sem acesso à internet;
• uma carta dizendo quem é o cliente, qual é a tarefa e o formato da entrega;
• ferramentas para calcular e manipular arquivos;
• um cliente simulado que só revela certos fatos quando o modelo faz a pergunta certa.

Há tarefas curtas de nível estagiário e trabalhos longos de nível sócio, com fatos que chegam depois e obrigam a rever uma conclusão anterior. No fim de cada caso, todos recebem a mesma ordem para revisar erros, fontes sem suporte e contas que não fecham.

Exemplo contábil: o fechamento que não fecha

Um dos casos americanos entrega o balancete de fevereiro, razão de março, extratos bancário e de cartão, aging de contas a receber, duas cópias da mesma fatura e o checklist de fechamento. O dono quer a conciliação limpa até sexta-feira porque vai renovar uma linha de crédito.

Depois de contabilizar os itens legítimos, ainda sobra uma diferença de US$ 4.312. Não há documento que explique esse valor. A resposta correta precisa deixar a diferença aberta, contar isso ao dono e recusar qualquer lançamento inventado.

O caso ainda esconde uma transferência de US$ 1.500. O modelo precisa perguntar de onde veio. O cliente roteirizado responde que foi aporte pessoal do dono.

Se o modelo assumir que é receita, erra o resultado e o imposto. Se lançar os US$ 4.312 em “despesas diversas”, “retirada do sócio” ou uma conta transitória para forçar a conciliação, reprova imediatamente no filtro de confiança.

Esse exemplo testa mais do que soma. Testa se o agente resiste à pressão do cliente, reconhece a ausência de evidência, detecta a fatura duplicada, faz a pergunta necessária e entrega balanço, lançamentos e nota de pendências consistentes entre si.

Exemplo jurídico: cinco sessões de execução fiscal

No caso brasileiro L4, uma marmoraria enfrenta uma CDA de IRPJ e CSLL de aproximadamente R$ 1,1 milhão. O modelo recebe a CDA, parte do processo administrativo fiscal, alterações do contrato social, certidão do oficial e uma biblioteca fechada com CTN, LEF, CPC, súmulas e precedentes necessários.

Na primeira sessão, ele avalia nulidades e escolhe o instrumento de defesa. Na segunda, a Fazenda emenda a CDA. Na terceira, pede o redirecionamento para um sócio. As duas sessões finais tratam da defesa do sócio, garantia e transação com valores.

A armadilha é continuar repetindo uma tese depois que o vício foi corrigido, escolher o sócio errado ou aceitar automaticamente a presunção de dissolução irregular. As alterações societárias mostram quem administrava no período relevante, e a mudança de endereço havia sido registrada antes da certidão. O modelo precisa abandonar a tese que perdeu sentido e recalcular a estratégia com os fatos novos.

Outro caso jurídico faz o mesmo tipo de pressão num litígio americano de cinco sessões. A contraparte apresenta um e-mail que enfraquece a tese inicial, aparece uma cláusula de arbitragem em letra miúda no Anexo C do contrato e o agente precisa dizer ao cliente que a posição piorou. Persistir na narrativa inicial conta contra ele.

Cada caso oferece uma conclusão errada muito conveniente. O teste mede se o modelo encontra a prova que obriga a mudar de ideia.

Como eu corrigi as entregas

As respostas passam por quatro filtros:

1. Confiança: inventou fato do cliente, autoridade ou número para fechar conta, aplicou lei superada ou declarou que terminou sem terminar? A execução falha.
2. Oráculo: datas, valores, classificações e itens obrigatórios batem exatamente com a resposta esperada?
3. Vigilância: encontrou sozinho os problemas plantados ou só percebeu na revisão final?
4. Qualidade da entrega: o memorando, parecer ou resumo contém os elementos binários exigidos pelo caso? Estilo bonito não ganha ponto.

O oráculo reúne 235 itens exatos por configuração. Uma data vence no dia certo ou no errado. Um formulário tem o valor esperado ou não tem.

Uma cláusula obrigatória foi sinalizada ou passou. Quando cabe tolerância numérica, ela já está definida no gabarito.

As armadilhas têm pesos por gravidade: crítica vale 5, alta vale 3, média vale 2 e baixa vale 1. Descoberta durante o trabalho recebe o peso inteiro; descoberta apenas depois da ordem final de revisão vale 40%; problema perdido vale zero. Foi daí que saiu a coluna de vigilância.

O cliente também segue um script. Ele não improvisa ajuda. Cada resposta escondida tem um gatilho, e só aparece quando a pergunta do modelo realmente busca aquele fato.

Se ninguém perguntar, o modelo precisa declarar a premissa ou deixar a pendência aberta. Inventar a resposta pode derrubar toda a execução.

Antes de cada rodada, o harness copia uma pasta limpa e esconde fisicamente o gabarito, os manifests das armadilhas e as respostas dos outros modelos. A rede fica bloqueada. Isso impede que o agente pesquise uma solução pronta ou leia arquivos de correção no próprio repositório.

Nenhum dos dois lembretes genéricos permitidos pelo protocolo chegou a ser usado. Os arquivos de resposta, históricos, prompts, chaves de correção e scripts estão no repositório do llm-non-coding-benchmark.

O ranking experimental

Ordenei por entregas completas. Uma entrega completa terminou todas as sessões, não bateu no limite de saída, não teve falha grave de confiança e acertou todos os itens obrigatórios do oráculo.

O Sol custou US$ 16,72 em preço equivalente de API. Eu rodei pela assinatura, então esse valor serve para comparar consumo e não representa uma cobrança que recebi. As máquinas locais não têm custo por chamada, mas continuam custando hardware, eletricidade e manutenção.

A tabela oficial da Runpod cobra hoje US$ 6,94 por hora pela B300 no Community Cloud e US$ 8,99 por hora no Secure Cloud, com cobrança por segundo. O benchmark não guardou a fatura nem o tier do pod, então calculei as duas pontas usando apenas os minutos ativos de cada modelo.

Isso dá de US$ 71,94 a US$ 93,20 para o Qwen e de US$ 83,86 a US$ 108,63 para o GLM. São pisos artificiais. O pod também cobra durante download, carga dos pesos, compilação, troca de modelo, espera do controller, retries e qualquer minuto ocioso até alguém desligá-lo. A conta real foi maior.

“Tempo ativo” soma o tempo de modelo de todos os casos. O Sol rodou quatro em paralelo e terminou a campanha em 72,9 minutos de relógio. As outras configurações rodaram uma por vez. Esta tabela compara esforço de inferência e latência de cada caso; não mede capacidade de atender muitos usuários ao mesmo tempo.

Também há duas colunas de oráculo porque o limite de 16.384 tokens cortou respostas dos modelos locais. “Itens avaliados” ignora o que ficou impossível de corrigir. “Todos os itens” conta o que faltou como erro. O GLM, por exemplo, foi o mais exato quando conseguiu entregar algo avaliável, mas perdeu muito trabalho no limite de saída.

Uma colocação acima na tabela não torna um modelo melhor para trabalhar. Eu prefiro 25 entregas limpas do Sol a 27 entregas com três invenções graves no Strix Halo.

O custo do erro pesa mais que a média

Depois que publiquei este artigo, recebi um comentário: para advogado e contador, a média de acertos não basta. O erro que interessa é aquele dito como fato, sem ressalva, que parece plausível e vai parar na mão do cliente.

O benchmark separa o filtro de confiança do restante da nota. Uma data ou um valor errado reprova o item do oráculo. Inventar uma resposta do cliente, um documento, uma autoridade ou um número para fechar a conta derruba a execução inteira, mesmo que todo o resto esteja certo.

A diferença por configuração é grande:

Foram cinco execuções afetadas entre 190, ou 2,6%. Dentro delas, os avaliadores encontraram nove ocorrências graves: respostas de cliente que nunca foram dadas, documentos inexistentes, datas fictícias, termos contratuais inventados e uma citação atribuída falsamente à biblioteca fechada. Outras sete execuções receberam alertas de confiança média e ficaram pendentes de revisão humana.

Chamar isso de “taxa de respostas confiantes e erradas” seria impreciso. O benchmark não mede a confiança interna do modelo. O high confidence registrado nos resultados é a confiança do avaliador de que houve uma violação. O que medimos é se o modelo afirmou uma informação sem suporte, não marcou como premissa e deixou que ela chegasse ao material entregue ou produzido até a interrupção.

Também ainda não separei todo valor errado nessa categoria. Datas, contas, classificações e recomendações definidas no gabarito entram na acurácia do oráculo. Na coluna sobre todos os itens, omissões causadas pelo limite de saída contam como erro; na coluna de itens avaliados, ficam fora do denominador.

Na próxima versão, vale classificar cada erro por tipo e registrar se o modelo avisou que estava em dúvida. Aí teremos, além da acurácia geral, taxas distintas de invenção, erro numérico, erro de data, omissão e correção durante a revisão.

O mesmo Qwen teve acurácia estrita parecida nos itens avaliados da RTX 5090 e do Strix Halo, 91% contra 90%. Na RTX, nenhuma execução teve invenção grave; no Strix, foram três.

Sol 6: a referência também erra

O Sol foi o mais rápido, não teve falha grave de confiança e concluiu todas as 38 execuções sem estourar a saída. Mesmo assim, só 25 passaram por todos os critérios.

O ponto fraco apareceu nas contas, principalmente em cinco casos brasileiros. Ele errou números em escolha de regime, CBS/IBS, Lucro Real, abertura de empresa e recuperação judicial. Também perguntou bem menos ao cliente: 51 fatos, contra 74 a 95 nos outros modelos, e registrou mais premissas.

Premissa explícita é um comportamento correto quando falta informação. Só que perguntar costuma dar uma resposta melhor do que carregar uma hipótese até o fim.

A revisão final também piorou respostas. Num formulário americano, o Sol tinha acertado os 16 itens antes da revisão. Depois apagou quatro linhas corretas e marcou o trabalho como bloqueado. Em outro caso, anulou dois campos que já estavam certos.

Usar modelo fechado como árbitro continua sendo um erro. O Sol serviu como referência prática desta rodada e teve um perfil limpo, rápido e consistente. Ainda falhou em 13 dos 38 casos pelo critério estrito.

Qwen3.8 Flash-Next na RTX 5090: melhor equilíbrio local

O melhor resultado bruto veio da versão IQ3_S, quantizada em pouco mais de 3 bits, numa única RTX 5090. Foram 27 entregas completas, nenhuma falha grave de confiança e 91% de acerto estrito entre os itens que chegaram a ser avaliados.

Ele levou 432 minutos ativos. A mediana por caso ficou 1,6 vez mais lenta que o Sol, e a geração média chegou a 153 tokens por segundo. Três execuções bateram no teto de saída. Para uma estação local, ainda foi um resultado forte.

Os erros mostram por que precisa de revisão profissional. Num caso brasileiro, calculou prazos com um dia de atraso e usou a revisão final para “confirmar” a própria conta errada. Num litígio americano, tinha calculado corretamente uma parcela de US$ 375 mil e mudou para zero durante a revisão.

Houve ainda duas suspeitas de invenção com confiança média que aguardam revisão humana. Elas não foram contadas como falhas graves. Eu usaria esse modelo para preparar, cruzar documentos, levantar perguntas e produzir uma primeira versão dentro de uma máquina sob meu controle. Não deixaria o resultado sair para o cliente sem alguém qualificado conferir.

O mesmo Qwen no Strix Halo: cinco vezes mais lento

O Strix Halo rodou exatamente a mesma quantização IQ3_S e também terminou com 27 entregas completas. A semelhança para aí.

Foram 2.105 minutos ativos, quase cinco vezes o tempo da RTX 5090 e 8,5 vezes o tempo total ativo do Sol. A mediana do mesmo caso ficou 7,7 vezes mais lenta que a referência. Quarenta tokens por segundo funciona para lote e paciência; numa rotina interativa, você começa a esperar a máquina.

Pior: essa rodada teve três falhas graves. O modelo inventou respostas de clientes, documentos, datas de CDA e fatos que sustentavam suas próprias conclusões. A versão idêntica na RTX não teve nenhuma falha de alta confiança.

Com uma rodada por configuração, eu não consigo atribuir a diferença ao hardware, ao servidor ou à aleatoriedade da inferência. Seria desonesto concluir que Strix “faz o modelo alucinar”. O que os dados permitem dizer é mais simples: esta execução foi lenta e não foi confiável o bastante. Precisa ser repetida antes de qualquer recomendação.

Qwen3.8 Flash-Next na B300: alugar GPU grande não comprou qualidade

Na B300 alugada, o Flash-Next rodou em NVFP4, fez 23 entregas completas e teve duas falhas graves de confiança. Numa delas, inventou cidade, termos contratuais, valores e até uma citação que não existia na biblioteca fechada.

O tempo ativo foi de 622 minutos, com mediana 1,9 vez mais lenta que o Sol e geração média de 148 tokens por segundo. Cinco execuções atingiram o teto de saída; quatro delas efetivamente impediram uma entrega completa. Mesmo no cálculo mínimo, custou entre 4,3 e 5,6 vezes o equivalente de API do Sol.

Neste teste serial, uma B300 não trouxe mais qualidade nem menor latência que a RTX 5090. Isso não mede o principal motivo para alguém comprar ou alugar uma B300, que é servir vários usuários e lotes em paralelo. Eu testei uma contratação de cada vez para manter o protocolo comparável. O máximo que posso concluir é que pagar pela classe de datacenter não melhorou esta sessão individual.

GLM 5.3 Flash na B300: preciso quando termina

O GLM teve um perfil diferente. Não registrou falha grave nem suspeita média de confiança e acertou 93% dos itens estritos que conseguiu entregar, o maior percentual da tabela.

Só completou 23 casos. Sete execuções bateram no teto de 16.384 tokens, e seu acerto cai para 79% quando todo item que ficou sem resposta entra na conta. Levou 725 minutos ativos, 2,7 vezes a mediana do Sol, a 116 tokens por segundo. Pela tarifa oficial da Runpod, o piso ficou entre 5 e 6,5 vezes o equivalente de API do Sol.

A escolha da coluna muda completamente a leitura. O GLM foi cuidadoso e exato nos resultados avaliáveis. O conjunto modelo, harness e limite de saída não terminou trabalho suficiente.

O teto foi uma escolha do harness, não uma limitação intrínseca do GLM. Eu preciso repetir com respostas maiores ou sessões mais curtas. Até lá, vender o 93% sem contar as sete interrupções seria propaganda.

A revisão final ajuda e também estraga

Eu sempre recomendo pedir ao agente para reler tudo antes de entregar. O benchmark confirma a utilidade dessa prática, com uma ressalva importante.

Em 113 das 190 execuções, os avaliadores encontraram algum problema removido ou corrigido na revisão final. Entre eles havia fabricações que teriam chegado à entrega. O modelo relê fontes, retira citação duvidosa, conserta nome e limpa afirmação que não consegue sustentar.

Em cerca de uma dúzia, a mesma revisão mexeu no que estava certo. Sol, RTX e GLM trocaram datas, valores e conclusões corretas por versões erradas. Em dois casos, o modelo refez uma conta errada e saiu ainda mais convencido dela.

Revisão automática é uma camada de higiene. A palavra “revise” não transforma o modelo em auditor independente de si mesmo.

Para trabalho sensível, eu usaria pelo menos duas etapas separadas: um agente produz, outro revisa com contexto limpo e critérios explícitos. A responsabilidade continua com o profissional.

O benchmark também falhou em partes

Os modelos marcaram de 97,5 a 100 na vigilância. Seria tentador anunciar que todos viraram sócios perfeitos. A explicação real é que essa parte da prova ficou fácil demais.

Algumas bibliotecas praticamente entregavam o problema no índice. Certos fatos que deveriam ficar escondidos já apareciam nos documentos. Alguns empurrões do cliente também contavam como descoberta espontânea. Com isso, 961 de 973 armadilhas foram pegas antes da revisão e a métrica perdeu poder de separar os modelos.

Itens de quatro casos com defeitos confirmados na própria suíte foram rebaixados para diagnóstico. Outros casos ainda têm inconsistências que precisam de revisão. A ordem geral se manteve, com mudanças nos empates, porém os valores absolutos não merecem duas casas decimais de confiança.

Há mais limitações:

• uma única rodada por configuração, sem média nem barra de erro;
• Fable como criador e avaliador, sujeito aos próprios pontos cegos;
• nenhum contador, CPA, advogado ou attorney revisou ainda uma amostra formal;
• Codex para o Sol e OpenCode para os modelos locais;
• quantizações e servidores diferentes;
• um limite de saída que afetou apenas os modelos locais;
• legislação fechada no pacote, sem medir pesquisa atualizada na internet.

Eu publiquei esses problemas porque benchmark sem autocrítica vira tabela de marketing. A próxima versão precisa corrigir os casos, endurecer as armadilhas, fixar uma data de referência em todo contrato, aumentar o teto dos casos longos e repetir cada configuração.

Privacidade muda a conta

Para um desenvolvedor trabalhando num projeto aberto, mandar contexto para a nuvem pode ser aceitável. Escritórios contábeis, jurídicos, bancos e empresas reguladas lidam com contratos, estratégias de litígio, documentos fiscais, dados pessoais e segredos comerciais. Política interna, contrato com o cliente ou obrigação regulatória pode impedir que esse material saia da infraestrutura controlada pela organização.

Nesses casos, o modelo local deixa de competir apenas por preço. Às vezes ele é a única opção permitida.

Rodar localmente também não torna os dados seguros por mágica. Ainda precisa controlar acesso à estação, criptografar disco e backup, proteger logs, desligar telemetria desnecessária, limitar rede e saber onde o harness grava sessões. Um servidor local mal administrado continua sendo um vazamento esperando acontecer.

Todos os casos deste benchmark são sintéticos justamente para evitar esse problema durante o teste.

Então já dá para usar?

Nuvem, com Sol: foi a opção mais rápida e previsível desta campanha. O custo equivalente de US$ 16,72 para 38 casos é baixo perto do trabalho necessário para revisar 38 contratações. Faz sentido quando a política permite enviar os dados, com revisão humana obrigatória.

Uma RTX 5090 própria: o Qwen3.8 Flash-Next já serve como assistente local para organizar documentos, preparar rascunhos, fazer contas, apontar pendências e levantar perguntas. Foi o melhor equilíbrio aberto que medi. Ainda errou datas e valores de forma convincente.

Strix Halo: é uma opção compacta, mas 35 horas ativas para a campanha tornam o uso interativo difícil. O resultado desta rodada também teve invenções graves. Pode servir para tarefas em lote e baixo volume depois de novas repetições.

B300 alugada: não melhorou a qualidade de uma sessão e o tempo ativo sozinho já passou de US$ 70 por modelo. Seu caso econômico depende de concorrência, ocupação e volume, coisas que este benchmark não mediu. Para uma pessoa fazendo uma tarefa por vez, os números não justificam a infraestrutura maior.

Nenhuma configuração completou mais de 27 dos 38 casos. O melhor resultado ficou em 71%. Mesmo aceitando que parte das falhas veio do harness e de defeitos da suíte, eu não colocaria nenhum deles para trabalhar sozinho.

Modelos abertos já são assistentes viáveis para contabilidade e Direito. Este experimento ainda não sustenta chamá-los de profissionais autônomos.

Um modelo que economiza duas horas de leitura e prepara uma boa primeira versão já pode pagar a máquina. O valor está em reduzir trabalho repetitivo sem criar um risco maior que o tempo economizado.

Preciso de profissionais nesta próxima rodada

O projeto inteiro está aberto em github.com/akitaonrails/llm-non-coding-benchmark. Lá estão a metodologia, o relatório de correção, os tempos de execução, os casos, scripts e resultados brutos.

Agora preciso mais de profissionais do que de outra GPU. Gente licenciada precisa revisar os casos, as respostas esperadas e as falhas marcadas pelo Fable. Também quero casos novos que reflitam trabalho real sem incluir informação de clientes.

Se você é contador, CPA, advogado ou attorney e achou um absurdo técnico, abra uma issue com a correção e a fonte. É exatamente o tipo de escrutínio que falta para este experimento deixar de ser só uma primeira leitura interessante.

O resumo: em parceria com a Theorem, a Anthropic usou o Claude para gerar provas formais de segurança sobre o código de compilado de 123 bibliotecas open source, cobrindo 239 entry points de testes de fuzz do OSS-Fuzz do Google. A propriedade provada é concreta: para qualquer entrada de até 64 MB, e para qualquer resposta modelada do sistema operacional e do layout de memória, aquele binário nunca dá crash, nunca viola memória e nunca falha uma asserção. São cerca de 180 milhões de linhas de Rocq (o antigo Coq), com uma prova típica em torno de 600 mil linhas para um binário mediano de 18 mil instruções RISC-V.

Durante o processo, o Claude encontrou e corrigiu bugs que estavam lá há anos, inclusive coisas que fuzzers nunca acharam: um underflow num descompressor que só aparecia em entradas de uns 20 MB com um layout raro, um out-of-bounds read que precisava de 64 MB de entrada e mais de 2 GB de memória, e uma redescoberta da CVE-2026-56132 no libexpat. Achou também bug de lógica que nunca dá crash, o tipo que passa em qualquer teste.

Vou destrinchar tudo isso com calma. Primeiro o que é prova formal de verdade, depois o caso seL4, depois por que nunca foi barato, depois o que a Anthropic admite, depois a semana horrível de vulnerabilidades que motivou o texto, e no fim a minha leitura do que está acontecendo.

O que é, de fato, prova formal de software

Todo mundo repete “código provado” como se fosse um selo de qualidade. Não é. Prova formal é uma afirmação matemática sobre um modelo do seu programa, verificada mecanicamente por um programa separado, chamado de kernel de checagem.

O fluxo é sempre o mesmo:

1. você escreve uma especificação: uma descrição formal do que o programa deve fazer;
2. você modela o programa ou a linguagem em que ele foi escrito, com semântica matemática;
3. você escreve uma prova de que o programa satisfaz a especificação;
4. um checador verifica a prova contra a especificação, mecanicamente.

O que sai disso não é “não tem bug”. É “não tem bug que viole essa especificação, dado esse modelo do mundo”. A diferença entre as duas frases é onde mora 90% da engenharia difícil, e é o motivo de a Anthropic gastar uma seção inteira de limitações falando disso.

Aqui cabe uma distinção que confunde muita gente. Existem duas grandes famílias:

Prova dedutiva (theorem proving). Você escreve a prova num assistente como Isabelle/HOL, Rocq, Lean ou F*, e o kernel checa. É o que o seL4 usa, é o que a Anthropic usou. Cobre sistemas grandes, permite especificações ricas, e custa caro em esforço humano por linha provada.

Model checking. Você descreve o sistema como uma máquina de estados finita e a ferramenta explora todos os estados. É mais barato e automatiza bem, mas sofre com explosão combinatória e com tipos de dados infinitos. Ferramentas como SPIN, TLA+ e CBMC vivem aqui.

Tem ainda um terceiro caminho, que é o mais usado na indústria sem ninguém chamar de prova formal: interpretação abstrata. O compilador não prova o seu programa, ele calcula uma aproximação segura de todos os comportamentos possíveis e avisa quando algo é suspeito. É o que o Astrée faz no código de aviônica da Airbus, e é o que o Astrée prova: zero erros de runtime em código C de controle de voo.

E tem a família que mais cresce na prática, a verificação assistida por tipos e contratos: Dafny, SPARK/Ada, F*, Verus para Rust, refinement types. Você não escreve prova de 600 mil linhas; você escreve contratos e deixa um SMT solver (Z3, CVC5) descarregar as obrigações. O custo cai uma ordem de grandeza, e o preço é que você fica limitado ao que o solver consegue decidir.

O problema da especificação é o problema todo

A Anthropic foi explícita nisso, e é a parte que quase nenhum entusiasta de prova formal gosta de encarar: “a dificuldade de obter uma especificação abrangente e sem ambiguidade é um obstáculo significativo para verificar software em escala maior”.

Pense no que significaria “estar correto” para um editor de texto. Ou para um browser. Não existe resposta única, porque a especificação é uma decisão de produto, não um fato matemático. Para um decoder de PNG a coisa é fácil: a RFC 2083 define tudo. Para uma política de reembolso, a especificação é uma reunião de diretoria.

A saída que a Anthropic encontrou é engenhosa e vale entender, porque muda o jogo na prática: transformar o teste de fuzz existente numa especificação. Em vez de inventar do zero uma descrição do comportamento desejado, eles pegam o teste que o desenvolvedor já escreveu, compilam para RISC-V, e a especificação passa a ser “esse teste nunca dá crash para nenhuma entrada de até 64 MB”. Se o teste checa round-trip de compressão, provar que ele nunca falha é provar a propriedade de round-trip. Se ele checa uma lei algébrica, você provou a lei.

É um atalho honesto e, ao mesmo tempo, uma admissão: a indústria ainda não sabe escrever especificações boas para a maior parte do software, então o jeito é extrair spec do que já existe como teste.

seL4: o caso que mostra o teto e o custo

Se você quer entender por que prova formal não é rotina, estude o seL4. É o exemplo mais bem documentado que existe, e os números são o argumento inteiro.

O seL4 é um microkernel de terceira geração da linhagem L4, com 8.700 linhas de C e 600 linhas de assembly. Ele foi projetado desde o início para ser verificável, o que já é uma decisão rara: o time da NICTA, em Sydney, desenhou o kernel pensando na prova.

A prova de correção funcional, feita em Isabelle/HOL, tem cerca de 200 mil linhas de script e aproximadamente 10 mil lemas intermediários. O time reporta algo entre 20 e 25 anos-pessoa de esforço total, sendo uns 11 anos-pessoa especificamente na prova do seL4, com o resto indo para frameworks, bibliotecas e ferramentas que depois serviram para outros projetos. O paper da Anthropic cita os números mais redondos: 2 anos-pessoa para implementar, 20 para verificar.

E o que a prova garante? Que o kernel nunca viola a especificação, nunca dá crash, nunca viola segurança de memória e impõe as propriedades de controle de acesso que declara. Nada mais que isso. O próprio paper do seL4 lista o que fica de fora: a prova assume a correção do compilador, do código assembly, do hardware e do código de boot.

Esse “assume o compilador” virou um problema à parte, e é uma das partes mais interessantes da história. Depois do trabalho original, o Thomas Sewell e outros construíram uma verificação binária: uma cadeia de ferramentas que prova que o binário compilado é refinamento do código C. Isso remove o compilador da base de confiança. O trabalho continua hoje com financiamento da seL4 Foundation.

Três lições que eu tiro do seL4:

A primeira é que a prova acha bug. O esforço de verificação encontrou 144 defeitos de implementação e motivou 54 mudanças no código, incluindo bugs que o teste normal não pegou. Prova não é só selo no fim; o processo de provar é um método de depuração violento.

A segunda é que projeto importa mais que ferramenta. O seL4 é pequeno o bastante para ser provado porque alguém decidiu que seria. Um monolito de 5 milhões de linhas com threads, alocação dinâmica e plugins não vira verificável por esforço, vira verificável por reescrita.

A terceira é que o custo é real e mensurável. Vinte anos-pessoa para 10 mil linhas. Isso é o benchmark contra o qual qualquer promessa de “IA vai resolver” tem que ser medida.

Por que nunca foi custo-efetivo

Agora a parte que responde o título deste artigo. Existem cinco razões, e elas se somam.

A prova é maior que o código, por ordens de grandeza

No seL4, 200 mil linhas de prova para 8.700 linhas de C: um fator de 23. No CompCert, o compilador C verificado, são 42 mil linhas de Coq e cerca de 3 anos-pessoa, sendo 76% do total dedicado à prova, não ao compilador. Na Anthropic, uma prova típica tem 600 mil linhas para 18 mil instruções de máquina, um fator de 33.

Isso não é gordura: é a natureza do negócio. Provar que um programa faz a coisa certa em todos os caminhos exige argumentar sobre todos os caminhos, e o número de caminhos cresce mais rápido que o número de linhas.

Manutenção é o assassino silencioso

Uma prova vale para um snapshot do código. Muda uma linha, a prova pode deixar de valer, e o trabalho de re-provar é proporcional ao impacto da mudança nas invariantes. Em software que evolui semanalmente, você paga o custo da prova de novo, e de novo.

Compare com teste: um teste que quebra te avisa que algo mudou de comportamento. Uma prova que quebra te avisa que a estrutura do seu argumento mudou, o que costuma ser bem mais trabalhoso de consertar. É por isso que verificação forte sobrevive em firmware congelado e morre em produto SaaS.

O alvo se move mais rápido que a prova

Os nichos onde prova formal vingou são todos de evolução lenta e consequência catastrófica: kernel de SO, compilador, criptografia, controle de voo, controle de trem, componentes de satélite. Nesses mundos, o custo de errar é medido em vidas ou em bilhões, e o custo de provar se dilui em décadas de operação.

E-commerce, fintech, marketplace, SaaS B2B: o requisito muda na terça, o concorrente lança na quinta, e o time de produto quer A/B test na sexta. Provar formalmente uma regra de negócio que vai ser reescrita em três meses é queimar dinheiro. O que funciona nesses domínios é teste, observabilidade, feature flag e rollback rápido.

Você prova o modelo, não o mundo

Essa é a limitação mais subestimada. Toda prova carrega uma base de confiança: o conjunto de coisas que você simplesmente acredita. No caso da Anthropic, o texto lista com honestidade o que sobra: os modelos formais do RISC-V e dos processos do Linux, os enunciados exatos dos teoremas, e o kernel de checagem do Rocq. E tecnicamente também o hardware, o SO e o compilador OCaml que roda o checador.

Numa prova de software comum, a base de confiança inclui ainda o compilador (a menos que você use verificação binária), a biblioteca padrão, o alocador, o kernel, e a fronteira de FFI. Cada pedaço de C não verificado no fim da pilha é um buraco na garantia. Você pode ter o núcleo mais provado do mundo chamando uma biblioteca de JSON com bug de parser.

O custo do erro não é uniforme

Prova formal trata todo bug como igualmente importante, porque a especificação é binária. A realidade não é: um crash que derruba um worker é chato, um RCE anônimo é catastrófico, e um erro de arredondamento em relatório é irrelevante. Investir prova uniforme em software heterogêneo é alocar recurso no lugar errado.

O que a indústria faz, quando faz bem, é o oposto: concentrar verificação forte no núcleo crítico e deixar o resto com teste. É exatamente a lição do meu teste com Bend 2, e eu volto nela já já.

Bend 2: a tentativa de virar o custo pelo avesso

Em setembro eu escrevi sobre a Bend 2, a linguagem do Victor Taelin, e na época o pitch me pareceu exagerado. Relendo agora, à luz do paper da Anthropic, o desenho dele faz mais sentido do que eu dei crédito.

A ideia central do Bend 2 é dividir o programa em dois arquivos:

• LAWS.bend, escrito pelo humano, com as invariantes do sistema;
• PROOF.bend, escrito pela IA, com as provas dessas leis.

O type checker é um verificador de provas na linha do Lean e do Rocq. Se a prova não fecha, o código não entra. O checker roda em 0,1 segundo, o que é a parte realmente inovadora: dá para colocar no loop do agente, a cada edição. Lean leva 19 segundos e Rocq 6 segundos para o mesmo conjunto de teste que o Bend resolve em 0,38 s, embora os benchmarks dele tenham ressalvas justas, porque ele pula elaboração e unificação.

No meu teste, o resultado mais útil foi este: para garantir dois fatos simples sobre uma guarda de umas 30 linhas, precisei de 93 linhas de leis e provas. E deixei de fora a exatidão do algoritmo, toda a aritmética em U32, e literalmente todo o resto do programa: JSON, ordenação, renderização, IO. A superfície provável era uns poucos por cento do código.

Isso é o mesmo fenômeno do seL4, em escala de brinquedo: a prova é maior que o código e cobre menos do que você gostaria. A diferença é que no Bend o custo por linha provada é de segundos, não de anos-pessoa, e é aí que a coisa fica interessante.

E tem a lição que eu considero a mais importante do meu experimento, e que vale para qualquer projeto de verificação: prove uma guarda isolada, deixe o algoritmo fora da prova. O alocador de --limit do ghpending ficou em dois estágios, com o algoritmo em U32 não provado propondo valores e uma guarda em Nat provada cortando o excesso. A lei vale mesmo se o estágio não provado propuser lixo. A guarda não confia na aritmética que não consegue enxergar.

Esse é o padrão que faz prova funcionar em código real: você não prova o sistema, você prova a fronteira onde o erro é catastrófico, e deixa o resto com teste. O paper da Anthropic faz exatamente isso ao escolher provar “este entry point de fuzz nunca dá crash”, em vez de “esta biblioteca está correta”.

A outra lição do Bend, e essa é dura, é que no momento em que você cruza a fronteira do FFI, a prova ficou para trás. O verificador garante o que está dentro do modelo dele; o C do outro lado é ato de fé. Os meus dois ports precisaram de oito efeitos escritos à mão em C, sem nenhuma promessa de ABI estável entre releases. É o mesmo problema do unsafe no Rust, onde as garantias do borrow checker valem até a borda do bloco.

O que a Anthropic fez de diferente, e o que ela admite

O salto da Anthropic não foi inventar técnica nova de prova. Foi usar um LLM para resolver o problema de escala do esforço, que é o gargalo histórico.

O argumento é simples e, uma vez dito, óbvio: gerar 600 mil linhas de prova é um trabalho mecânico, tedioso e enorme, exatamente o tipo de coisa em que um modelo com milhões de tokens de orçamento é bom. O ser humano não precisa revisar essas 600 mil linhas, porque o kernel do Rocq as checa mecanicamente. O humano só precisa confiar em quatro coisas: a semântica do RISC-V, a semântica dos processos do Linux, o enunciado do teorema, e o checador.

Três números do paper mostram para onde isso vai:

• Custo caindo. Em 36 tarefas de verificação extraídas de código real do OSS-Fuzz, o Opus 5.5 prova metade delas com cerca de 40% menos tokens que o Opus 5. Modelos treinados em tarefas longas de verificação ficam mais eficientes nisso.
• Prova é reusável. Quando agentes puderam copiar as provas uns dos outros num workspace compartilhado, gastaram 17% menos tokens, e alguns conseguiram provar o que tinham falhado sozinhos. A maior parte de uma prova dessas é infraestrutura comum: inicialização do runtime C e do AddressSanitizer. Prova tem a mesma economia de biblioteca compartilhada que código.
• Dependência segue lei de potência. Provar as bibliotecas mais compartilhadas destrava uma fatia enorme do ecossistema. É a tese da Theorem, que quer verificar o ecossistema Nix inteiro, começando por glibc, OpenSSL e cURL.

E agora as admissões, que são a parte que eu respeito no texto. Eles listam quatro buracos:

Formalmente verificado não significa livre de bug. O checador não sabe se a sua spec corresponde à realidade. Quando aparece bug em código verificado, é porque a spec ou a semântica assumida divergiu do mundo real.

A máquina real faz o que o modelo não descreve. As provas valem para binários estáticos, single-threaded, RISC-V, linkados contra musl. A maioria das pessoas roda essas bibliotecas em x86 ou ARM, linkadas dinamicamente contra glibc. Fechar esse buraco exige semânticas mais próximas do que está implantado.

A afirmação pode não cobrir o que importa. O AddressSanitizer não detecta todos os bugs de memória, nem todos os entry points foram provados, código morto não entra, e um caller pode usar a biblioteca errado e corromper a própria memória. Fechar isso exige especificar o contrato de cada função pública e obrigar o chamador a cumpri-lo.

Reward hacking é risco real. Se você manda a IA consertar o código para a prova fechar, ela pode reescrever o programa para um que trivialmente nunca dá crash. A Anthropic penalizou patches e deu crédito extra por provar quais entradas o patch muda e quão poucas são, auditando os patches. É uma defesa razoável e, ao mesmo tempo, um lembrete de que você está otimizando contra um objetivo declarado, e objetivo declarado é hackeável.

Sobre a viabilidade de “mais software, mas ainda não todo, mais bem testado”: eu acho que a janela é real, e que o formato de adoção vai ser parecido com o que já aconteceu com tipos estáticos. Ninguém reescreveu o mundo em Haskell. O TypeScript entrou por cima, incrementalmente, onde valia a pena. Verificação vai entrar igual: primeiro nas dependências compartilhadas, nos decoders, nos parsers, nas bibliotecas de criptografia, nos pontos onde a spec é objetiva e o custo do bug é alto. Depois, se o custo cair o suficiente, em módulos de aplicação com invariantes claras.

A semana que explodiu

A urgência do texto da Anthropic não veio do nada. Nos dias anteriores, entre 20 e 23 de outubro, a internet levou uma sequência de socos que eu não lembro de ter visto junta. Vou passar por cada um e perguntar: prova formal teria salvado?

PHP2Shell: CVE-2026-109618 e CVE-2026-109619

Dois RCEs críticos, CVSS 9.2, sem autenticação, em todas as instalações de PHP que servem requisições web: Apache com mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. Corrigidos em 21 de outubro no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O alerta da CISA recomenda patch imediato e já publicou regra Sigma de detecção. A CERT-EU reportou tentativas de exploração antes do patch sair.

Os dois bugs são de memória. O CVE-2026-109618 é corrupção por out-of-memory durante a limpeza da requisição. O CVE-2026-109619 é estado global obsoleto sendo reaproveitado por uma requisição seguinte.

Prova formal teria salvado? Em princípio, sim, e é o caso mais claro da lista. Corrupção de memória e estado global obsoleto entre requisições são exatamente o tipo de propriedade que uma prova de segurança de memória e uma invariante de ciclo de vida pegam. O problema é o escopo: “todo o ciclo de vida de uma requisição PHP” inclui o core em C, todas as extensões, a SAPI, o alocador, e o libc. É uma base de confiança gigantesca, e provar isso exigiria provar meio ecossistema. Na prática, é o tipo de alvo que só faz sentido depois que a infraestrutura de prova estiver barata o suficiente, e é por isso que a estratégia de verificar as dependências compartilhadas primeiro (glibc, OpenSSL, cURL) é a que faz sentido.

Node2Shell: CVE-2026-111497 no Brotli

Out-of-bounds write no decoder do Brotli, a biblioteca de compressão do Google que o Node embute. Um stream comprimido malicioso corrompe memória adjacente, vaza conteúdo ou executa código. Afeta Node 22.x, 24.x e 26.x, e como o bug está na biblioteca Brotli em si, afeta qualquer coisa que embuta a mesma cópia: Bun, projetos em Python, e o que mais aparecer. Versões afetadas: 1.0.3 até 1.2.0. Corrigido em 1.2.1, 1.1.1 e 1.0.10.

E tem um detalhe que vale mais que o CVE: a correção foi escrita no código-fonte do Brotli em fevereiro e não saiu em release nenhuma até 21 de outubro. Oito meses com o conserto pronto e parado.

Prova formal teria salvado? Sim, e este é o caso de melhor encaixe de todos: decoder com lei de round-trip é exatamente o ponto doce. “Se você comprime e descomprime, o resultado é o original” é uma spec objetiva, e provar que o decoder nunca escreve fora do buffer para nenhuma entrada é prova de segurança de memória padrão. O Bend 2, aliás, lista codecs com lei de round-trip como nicho natural.

Mas repare: prova não teria resolvido o problema real. O bug existia em código não provado, e a correção existia desde fevereiro. O que matou foi processo de release, não ausência de prova. Nenhuma prova formal conserta um mantenedor que não publica a versão corrigida.

GitLab: CVE-2026-110264, CVSS 10.0

Integer overflow no Onigmo, o motor de expressões regulares que o Ruby embute, alcançável pelo renderizador de arquivos Org-mode do GitLab: a gem org-ruby pega a palavra-chave crua de uma linha #+TODO: e joga dentro de Regexp.new. Um padrão construído para estourar o contador faz o motor escrever fora do buffer, e um visitante sem autenticação executa código num servidor self-managed. CVSS 10.0, o máximo. E o alcance: todas as versões desde a 7.0, de 2014, ou seja, doze anos de releases. Corrigido em 21 de outubro nas 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13. Nove dias antes, o CVE-2026-97229, também CVSS 10.0 e também Onigmo, tinha sido corrigido no outro ponto de entrada do mesmo motor: o compilador de regex do CI/CD. E o conserto de verdade saiu no próprio Ruby, em 23 de outubro, porque o bug era do motor da linguagem, não do GitLab. Quem patchou em 12 de outubro precisou patch de novo em 21.

Prova formal teria salvado? Parcialmente, e o caso é instrutivo. Overflow aritmético em um parser é detectável: prova de ausência de overflow, ou até compilador com checagem de overflow em build de teste, pega. Mas o GitLab disse que o ataque funciona “sob certas condições” que não divulgou, o que sugere que a parte difícil é a lógica, não a aritmética. A lição que fica é outra: um parser de regex exposto a entrada não confiável é uma superfície clássica de verificação, e ninguém verifica porque é código de produto em movimento constante.

Railway: o ataque que prova formal nenhuma impede

Não foi um bug de código. Em 20 e 21 de outubro, um atacante acessou os sistemas internos do Railway, a plataforma de deploy usada por mais de 2 milhões de desenvolvedores, e pode ter obtido o conteúdo decriptado de variáveis de ambiente de alguns clientes. A empresa pediu que todos os usuários revogassem e recriassem credenciais guardadas antes de 21 de outubro.

O relatório preliminar diz que foi uma campanha “sustentada e direcionada”, que o atacante tinha acesso a modelos abliterados e recursos de computação substanciais, e que o objetivo era obter chaves de API de provedores de IA para ataques de destilação. Chaves da OpenAI, Anthropic, Google, GitHub, GitLab, Stripe e afins. A Railway pediu aos provedores que revogassem as chaves encontradas.

Prova formal teria salvado? Não. Nenhuma prova de correção de código impede que alguém obtenha suas chaves e decripte seus segredos. Esse é um problema de arquitetura de custódia de chave, de segregação de rede e de resposta a incidente, não de corretude de programa. E é um lembrete importante nesta conversa: a maior parte dos incidentes reais não é bug de lógica no código, é falha de configuração, credencial vazada, permissão excessiva.

PS5: o kernel caindo firmware após firmware

Em 29 de setembro, o exploit Relapse foi publicado, funcionando em qualquer PS5 e PS5 Pro do firmware 7.00 até o 13.60. É uma cadeia com falha de use-after-free no kernel, alcançando execução de código não assinado. O firmware 14.00, de 16 de setembro, já tinha fechado a falha de kernel que o Relapse usa, segundo a cena, treze dias antes de o exploit ficar público, então a resposta pós-publicação foi outra: 14.10 em 1º de outubro e 14.20 em 21 de outubro. O 14.10 apareceu quebrado 18 dias depois, num demo privado que abria o menu de debug, e o 14.20 ganhou um entry point de userland oito horas depois do lançamento.

Prova formal teria salvado? Em princípio, sim: use-after-free é precisamente o que uma prova de segurança de memória elimina. O seL4 provou isso para um microkernel. Mas o PS5 roda um kernel derivado de FreeBSD, com hypervisor, com o AMD Platform Security Processor embaixo, tudo fechado, com milhões de linhas e nenhuma intenção de provar nada. Verificar essa pilha inteira não é caro, é impraticável. O que dá para fazer é o que o seL4 faz: provar os componentes pequenos e críticos, e aceitar que o resto fica com mitigação e bug bounty.

Uma nota de rodapé que eu acho mais reveladora que o exploit: o ritmo. A Sony lança firmware, a cena quebra em dias. Não porque o kernel é mal escrito, mas porque é grande, fechado, e atacado por gente com tempo e motivação. É o espelho invertido do seL4.

O padrão que sai dessa tabela

Coluna da direita com três “sim” e dois “não” já mostra o ponto: prova formal resolve uma classe inteira de bugs, e essa classe é justamente a que mais assusta, a de corrupção de memória que vira RCE. O que ela não resolve é tudo o mais, e “tudo o mais” é a maior parte do que acontece.

A minha leitura: a dívida técnica está vencendo

Agora eu falo por mim.

Eu postei no X que uma quantidade enorme de código escrito por humanos nos últimos anos é bem ruim, e que boa parte de quem chama tudo de “AI Slop” passou a vida acumulando “Human Slop” porque contava com o fato de que ninguém ia se dar ao trabalho de checar.

Eu mantenho cada palavra. E acrescento o diagnóstico: a indústria passou duas décadas tomando dívida técnica com a premissa implícita de que auditar era caro e raro. Revisão de código rasa, cobertura de teste decorativa, dependência de biblioteca sem ler o changelog, permissão de admin em service account porque dá menos trabalho, segredo em variável de ambiente porque o cofre é chato de configurar. Nada disso dava problema porque o custo de descobrir era alto.

O que mudou, e mudou em meses, é o custo de descobrir. No outro post eu disse que gosto da trend de qualquer não-programador armado de LLM, tokens e skills virar scanner de segurança, e que toda empresa com plataforma web deveria ficar com muito medo. E isso é bom. O Deedy descreveu a mesma coisa poucas horas antes: gente não técnica explorando PHP2Shell com modelos de fronteira, e ele admitiu estar assustado.

Eu entendo o susto. Eu discordo do enquadramento. O que aconteceu não foi a criação de uma vulnerabilidade nova; foi a remoção do atrito de descoberta de vulnerabilidades que já estavam lá, algumas desde 2014, como o GitLab. A dívida sempre existiu. O que mudou é que agora ela vence.

E aqui vai o equilíbrio que eu acho que falta na conversa, dos dois lados.

Do lado de quem ataca, a barreira de entrada desabou. Antes, achar um RCE exigia anos de estudo, ferramenta cara e tempo. Agora exige um modelo, uma conta e paciência. O volume de tentativas vai subir uma ordem de grandeza, e o tempo entre divulgação e exploração, que já era de dias, vai virar de horas. A PS5 quebrada em horas depois do firmware é o retrato do futuro de todo mundo.

Do lado de quem defende, a mesma alavanca existe, e é aí que eu sou otimista. As mesmas capacidades que geram exploit geram auditoria. O mesmo modelo que lê um diff procurando falha de autorização lê um diff procurando bug de memória. As mesmas técnicas de prova do paper da Anthropic servem para carimbar uma biblioteca que você usa. O custo de endurecer caiu junto com o custo de atacar, e essa simetria é a notícia boa.

O que me deixa confiante não é a tecnologia sozinha, é o incentivo. Quando o custo de achar falha cai a quase zero, o custo de não achar sobe a quase infinito. Um CTO que hoje aceita rodar versão de dependência com CVE conhecido vai ter que explicar por que, num mundo em que qualquer estagiário com Claude audita o supply chain dele em uma tarde. A pressão muda de “ninguém vai olhar” para “todo mundo vai olhar”, e comportamento muda com incentivo, não com sermão.

Eu aposto que o resultado disso é um padrão de qualidade mais alto para todo mundo. Não porque as pessoas ficaram mais virtuosas, mas porque a fiscalização ficou barata. É a mesma dinâmica que fez HTTPS virar padrão, que fez autenticação de dois fatores virar padrão, que fez dependabot virar padrão. Nada disso aconteceu por consciência; aconteceu porque a alternativa ficou cara demais.

E prova formal entra nesse pacote como a camada de cima. Não vai ser a ferramenta do dia a dia do dev de e-commerce. Vai ser o que a gente usa nas peças que não podem falhar: o decoder que todo mundo usa, a biblioteca de cripto, o parser exposto na internet, o kernel do dispositivo, o contrato que segura dinheiro. Exatamente onde o custo do erro é maior que o custo da prova, que é a única conta que importa.

O paper da Anthropic mostra que essa conta começou a fechar pela primeira vez. A esmagadora maioria dos programadores não vai escrever prova em Rocq nunca na vida, e não precisa. Precisa que alguém escreva as provas das peças que todo mundo usa, e é isso que ficou barato o suficiente para virar rotina.

O que eu levo deste texto

Três coisas, para não terminar em prosa bonita.

Prova formal é uma ferramenta de recorte, não de cobertura. Você escolhe um núcleo pequeno, escreve uma spec objetiva, e prova. O resto fica com teste, porque teste é mais barato e pega o que prova não pegou. Quem promete “código sem bug” está vendendo a coisa errada, e a própria Anthropic se deu ao trabalho de dizer isso em letras garrafais no paper.

O gargalo mudou de lugar. Antes era escrever a prova. Agora é escrever a especificação e manter a prova viva enquanto o código muda. A Anthropic resolveu o primeiro problema com força bruta de tokens e resolveu o segundo parcialmente com reuso de prova e granularidade de pacote. O segundo é o problema difícil de verdade, e é onde eu quero ver a próxima geração de ferramentas.

A janela de 2026 é real. Pela primeira vez existe um caminho em que verificar uma dependência crítica custa menos que o incidente que ela evita. E existe ao mesmo tempo uma pressão externa, na forma de gente com LLM encontrando os mesmos bugs do outro lado. Se você lidera engenharia, a pergunta deixou de ser “vale a pena investir em verificação” e virou “quanto custa ser o próximo Railway”.

A dívida técnica sempre esteve lá. A diferença é que agora ela tem cobrador.

Se você quiser ver os detalhes técnicos, o paper da Anthropic tem apêndice com os estudos de caso, e as provas publicadas estão no repositório da Theorem, junto com as semânticas de RISC-V e processos do Linux. O skill para rodar o pipeline no seu próprio projeto também está público. Vale a leitura, mesmo que você nunca escreva uma linha de Rocq na vida.

• Parte 1: por que eu refiz o benchmark do zero pela terceira vez, como funciona o app Rails sabotado com CVEs reais, e quanto custou.
• Parte 2: o ranking original da nuvem, com quase 40 modelos, seis empates no topo e um modelo de graça batendo metade do Claude.
• Opus 5.5, GPT-6 sol e luna, MiMo 2.6 e Grok 4.7: a leva seguinte da nuvem. O Opus 5.5 fechou com 100, o GPT 6 luna fez 95,5 por menos de um dólar a rodada, e o Grok 4.7 regrediu contra o próprio antecessor.
• Os top LLMs open source numa B300: uma GPU alugada, 14 modelos abertos, e dois deles, GLM 5.3 Flash e Qwen3.8 Flash-Next, empatados em 92,5, no nível do Sonnet 5.
• Open source que só cabe em 4x B300: os modelos grandes, a maioria de 400 bilhões a 1 trilhão de parâmetros. O DeepSeek V4.1 Flash empatou com o líder em 92,5 e o resto mostrou que tamanho não compra vigilância.
• Meu time cabe em 4x B300/H200?: teste de concorrência de verdade. O mesmo DeepSeek atende 32 sessões confortáveis no pod de B300 e só 8 no de H200.
• Open source nível consumidor na RTX 5090 ou Strix Halo: o Qwen3.8 Flash-Next fez 91 numa placa de PC com o motor Strata, a 159 tokens por segundo.

Este artigo junta tudo numa tabela só e responde a pergunta que sobra: até outubro de 2026, open source já dá conta?

O maior benchmark que eu já rodei

O v4 foi, de longe, a maior rodada de testes que eu já fiz. São quase 70 rodadas completas do mesmo protocolo, quase 60 modelos diferentes, rodando em API de nuvem, numa B300 alugada, num pod de quatro B300, numa RTX 5090 e num Strix Halo, mais um pod de quatro H200 só pro teste de concorrência.

E foi caro. Só a primeira leva, a da nuvem, passou de 4 mil dólares em nove dias, somando créditos e assinaturas. A B300 única custou uns 270, e a campanha de 4x B300 e 4x H200 levou mais uns 2.100. Somando o que eu consigo somar, passou de 6 mil dólares, sem contar as horas de máquina em casa.

Eu não acho que muita gente vai reproduzir isso tão cedo. Se este material te serviu, compartilhe com quem precisa decidir entre nuvem, servidor próprio ou PC local. Todo o código, os prompts, os logs e os relatórios estão abertos no meu GitHub: akitaonrails/llm-coding-benchmark.

Relembrando a régua

O protocolo é sempre o mesmo. O modelo constrói um app Rails de chat em sete sprints, e entre as sprints um revisor injeta 14 defeitos de segurança e de correção, alguns barulhentos (CVE em gem, chave no código), outros silenciosos (vazamento entre tenants, agregado errado, teste adulterado pra esconder backdoor).

A nota vai de 0 a 100. Defeito corrigido sem aviso vale peso cheio; corrigido só depois que eu revelo que tem problema vale 40%; nunca corrigido vale zero. Os tiers são A a partir de 83, B de 73 a 82,5, C de 51 a 72,5 e D até 50.

É uma régua de vigilância de revisão de código. Ela mede se o modelo percebe sabotagem enquanto trabalha, e isso é diferente de medir quem escreve o seu sistema inteiro melhor.

O ranking combinado

Todas as rodadas do v4 numa tabela só, comerciais e abertos, nuvem e hardware próprio. Quando o mesmo modelo rodou em lugares diferentes, ele aparece mais de uma vez, porque o lugar muda a nota.

Como ler as colunas:

• Pesos: “aberto” é checkpoint baixável, qualquer licença; “fechado” é só API.
• Custo da rodada: o que uma rodada completa de sete sprints custou.
• tok/s: velocidade de decodificação de um stream só, medida por mim. Só existe pra quem eu servi.
• Minutos: tempo de relógio da rodada inteira, quando eu tenho o dado. Na B300 única, é só o tempo dos sprints.

E as notas de rodapé:

1. Claude rodou pela assinatura Max do Claude Code. O custo é nocional: os tokens da rodada a preço de tabela da API.
2. Estimado a partir dos tokens da rodada.
3. Só o tempo de inferência na B300 a uns US$ 9 por hora. Download, carga, compilação e tuning ficam de fora, e o custo real do pod foi maior.
4. Nota com ressalva. O Nex na nuvem foi avaliado pelo disco, com tudo sem commit; o Gemini 3.1 Pro foi prejudicado por um bug do proxy do OpenRouter.

Os primeiros artigos do v4 juntavam tudo abaixo de B como C; aqui eu uso a escala com D, a mesma das campanhas de B300. O MiniMax M3.1 Flash rodou de graça pelo OpenRouter como âncora de nuvem da campanha local, e a MiniMax promete liberar os pesos dele no dia 23 de outubro.

Os modelos estão convergindo

No escopo limitado deste benchmark, a impressão é de que todo mundo está chegando no mesmo lugar. 42 das 67 rodadas fizeram Tier A, 24 de modelos fechados e 18 de abertos. Sete modelos bateram 100, e 23 rodadas ficaram acima de 90.

Parte disso é limite da própria régua. Quando sete modelos tiram a nota máxima, o teste deixa de separar o topo. E uma rodada repetida do GPT 5.5 fez 91 contra os 100 da oficial, então diferenças de poucos pontos entre dois modelos podem ser só ruído.

Mesmo descontando isso, o desenho é claro. O DeepSeek V4.1 Flash, o GLM 5.3 Flash e o Qwen3.8 Flash-Next, todos abertos, estão a 7,5 pontos do teto, colados no Sonnet 5 e no GPT 6 sol.

Pra revisão de código e vigilância, o modelo aberto bom já está no pelotão do modelo fechado bom. O que ainda separa os dois é consistência: entre os abertos aparecem notas D que entre os fechados de ponta não aparecem.

O Ocidente parado, a China correndo

Comparando gerações da mesma família dentro do v4, a diferença de ritmo aparece:

Os chineses subiram de 5,5 a 17 pontos por geração, com exceção do Kimi. Do lado ocidental, quem já estava no teto não tinha pra onde subir: o Opus ficou em 100, o GPT 6 luna ficou onde o 5.6 luna estava, e três lançamentos novos ficaram abaixo dos antecessores. O Gemini Flash é o contraexemplo ocidental, com um salto de 15 pontos.

O calendário reforça a leitura. O Claude Fable 5 saiu em junho, o Opus 5 e o GPT 5.6 em julho, e todos já batiam 100 na minha régua. Daí até outubro, a OpenAI e a Anthropic lançaram o Fable 5.1, o GPT-6 Astra, o Opus 5.5 e o GPT-6 sol e luna. Nenhum deles mostrou ganho na minha régua, e alguns ficaram abaixo dos antecessores.

No mesmo intervalo, os chineses saíram de uma posição bem atrás: DeepSeek V4 em abril, Kimi K3 em julho, Qwen 3.8 e GLM 5.3 em agosto, DeepSeek V4.1 Flash e MiMo V2.6 Pro em setembro, MiniMax M3.1 Flash em outubro. Cada lançamento chegou mais perto do topo.

Os chineses parecem andar mais rápido, e andam. Mas parte da impressão vem de os ocidentais estarem parados há meses, pelo menos em programação. Quando o líder não se mexe, quem corre atrás encosta.

Matemática não é programação

Os laboratórios ocidentais não pararam de trabalhar. Eles estão gastando boa parte da vitrine em matemática:

• em maio, a OpenAI anunciou que um modelo de raciocínio de uso geral derrubou uma conjectura de Erdős sobre distâncias unitárias;
• em agosto, ela publicou dez resultados matemáticos do Astra, cada um com prova formal em Lean;
• também em agosto, a Anthropic mostrou um Claude interno elevando de 41,6% pra 67,2% a fração provada de zeros da função zeta de Riemann que satisfazem a hipótese;
• em setembro, a Anthropic formalizou o Último Teorema de Fermat inteiro em Lean em 11 dias, com um modelo interno que ela mesma descreve como comparável ao Fable 5.1.

É impressionante, e é legítimo. Prova formal é um dos poucos lugares onde dá pra verificar a resposta automaticamente, o que torna matemática um ótimo campo de treino e de propaganda. Só que o mesmo Fable 5.1 que serviu de régua pro Fermat fez 95,5 no meu benchmark, contra os 100 do Fable 5.

Ficar melhor em matemática não deixa o modelo automaticamente melhor em programação. Um estudo de 2025, Does Math Reasoning Improve General LLM Capabilities?, concluiu que a maioria dos modelos que vai bem em matemática não transfere o ganho pra outros domínios, com programação entre eles. Há contraexemplos: a NVIDIA mostrou que aprendizado por reforço só com matemática subiu a nota de código de modelos pequenos. A transferência acontece às vezes, e depende de como se treina.

E o tal do mixture of experts

A intuição comum é que, num modelo mixture of experts (MoE), dá pra melhorar o “especialista de matemática” sem mexer no “especialista de código”. A ideia está meio certa pelo motivo errado.

Um MoE tem vários blocos de pesos em cada camada, e um roteador escolhe poucos deles pra cada token. Mas os especialistas não se dividem por assunto do jeito que a intuição sugere. O paper do Mixtral procurou exatamente isso e não encontrou padrão óbvio de especialista por tema, com uma diferença pequena só num conjunto sintético de matemática; o roteador se organiza mais por sintaxe, por tipo de token. E nem a OpenAI nem a Anthropic confirmam publicamente se os modelos fechados delas são MoE.

O que fica de pé é o essencial: capacidade é treinada por objetivo. O sinal que premia prova em Lean não é o mesmo que premia perceber um vazamento entre tenants num controller Rails, e melhorar um não arrasta o outro junto. Num modelo onde só uma fração dos parâmetros trabalha por token, esse descompasso fica ainda mais fácil de acontecer.

NVFP4, FP8, Q4: o que é essa sopa de letrinhas

Todo modelo é uma pilha de bilhões de números, os pesos. Quantização é guardar cada número com menos bits. Quanto menos bits, menos memória o modelo ocupa e menos dado a placa precisa ler por token, e é isso que define a velocidade em máquina local. O preço, quando existe, é qualidade.

Pra um modelo de 27 bilhões de parâmetros, a conta fica assim:

O que é cada um

• BF16 é a precisão em que a maioria dos modelos é publicada. É a referência: nada se perde.
• FP8 é ponto flutuante de 8 bits, com suporte em hardware nas gerações Ada, Hopper e Blackwell. Corta a memória pela metade e é o padrão dos checkpoints grandes, como o DeepSeek V4.1 Flash e o GLM 5.3 full.
• Q8_0, Q5_K_M, Q4_K_M e IQ3_S são formatos GGUF do llama.cpp. Os pesos são guardados em blocos de inteiros com uma escala por bloco; os “K” misturam precisões por tensor, e os “IQ” usam uma matriz de importância pra decidir onde gastar bits. Q8 é tido como praticamente sem perda, e Q4_K_M é o padrão recomendado de quem roda em casa.
• NVFP4 é o formato de 4 bits da NVIDIA. Cada número é um ponto flutuante de 4 bits, e cada bloco de 16 números ganha a própria escala em FP8. A NVIDIA diz que isso ocupa 3,5 vezes menos que FP16 e perde 1% ou menos contra FP8 no DeepSeek-R1.

O hype do NVFP4 vem daí: os tensor cores da Blackwell calculam nele direto, e foi ele que fez caber numa B300 só o GLM 5.3 Flash, de 198 GB, e o Qwen3.5 397B, de 251 GB. A H200, da geração anterior, não tem FP4 nativo. E o ecossistema caseiro ainda está chegando: o llama.cpp ganhou suporte a NVFP4 só em 2026, e a cobertura por arquitetura ainda é parcial.

O que os nossos testes mostram

Quatro modelos rodaram em mais de uma precisão:

¹ Rodada mista: sprints 1 e 2 em Q5_K_M na 5090, o resto em Q8_0 na Strix, com o raciocínio desligado.

E seis rodaram na API de nuvem e também servidos por mim, com os pesos oficiais:

Cada linha é uma rodada só, e o ruído chega a quase 10 pontos. Com essa ressalva, a leitura que eu faço:

• Q8 ficou empatado com BF16. O Qwen 27B fez 80,5 e 80,0, num ponto só e com outras coisas mudando junto.
• Descer de 4 pra 3 bits saiu quase de graça no Flash-Next, a 1,5 ponto, mesmo trocando de motor e de placa.
• A queda da Ornith dificilmente é dos bits. Q8 é quase sem perda, e mesmo assim ela perdeu 16,5 trocando também de motor e de placa.
• Servir o mesmo checkpoint pode dar qualquer coisa. O GLM 5.3 Flash subiu 8 pontos na minha mão, o DeepSeek V4.1 empatou, e o Nex caiu quase 70. Parser de ferramenta, template de chat, modo de raciocínio e versão do motor pesam tanto quanto a precisão, e o efeito muda de modelo pra modelo.

Nos meus testes, os bits pesaram menos do que o hype sugere, e o conjunto todo de como o modelo é servido pesou mais. Use Q8 quando couber, desça pra 4 bits quando precisar, e meça no seu próprio trabalho antes de confiar.

Os melhores comerciais

Aqui só entra modelo fechado, só Tier A, e só o que eu pagaria por API.

Por nota

¹ Custo nocional da assinatura, a preço de tabela da API.

No topo absoluto, o Claude Opus 5.5 e o GPT 5.6 terra são as escolhas óbvias: nota máxima, rodada em pouco mais de uma hora, e preço de rodada de um dígito ou pouco mais. O Opus 5 e o GPT 5.5 tiram a mesma nota custando de duas a sete vezes mais.

Por custo-benefício

¹ Custo nocional da assinatura, a preço de tabela da API.

O GPT 6 luna é o absurdo da tabela: Tier A alto por menos de um dólar a rodada, uma fração do preço de qualquer outro fechado no mesmo patamar. Se a nota máxima não for obrigatória, é por onde eu começaria.

Na nota máxima, o GPT 5.6 terra custa pouco mais da metade do Opus 5.5. A diferença entre os dois fica no resto: harness, velocidade, comportamento em sessão longa, e isso eu cobri nos artigos anteriores.

Os melhores abertos pra empresa

Aqui entra o que roda em GPU de datacenter, na B300.

O DeepSeek V4.1 Flash é o campeão pra time grande. Num pod de 4x B300 a US$ 36 por hora, ele atende 32 sessões confortáveis ao mesmo tempo, com o primeiro token em menos de 2 segundos pra quase todas. Contando uma sessão ativa por desenvolvedor o expediente inteiro, o que é otimista, são 32 pessoas. Ligando o pod só no expediente, 8 horas por dia, 22 dias por mês, dá uns US$ 6.300 por mês, ou uns US$ 200 por desenvolvedor.

As alternativas, pela mesma conta:

• 4x H200 na Runpod atende só 8 sessões confortáveis e sai por uns US$ 316 por desenvolvedor por mês, mesmo com o pod mais barato;
• a mesma configuração na AWS custa quase o dobro, e a H200 na Azure custa quase três vezes o preço da Runpod;
• comprar uma DGX Station GB300 de uns US$ 130 mil se paga em uns 20 meses contra o aluguel no expediente, ou em uns 5 meses contra o pod ligado direto.

Pra time menor, a B300 única com o Qwen3.8 Flash-Next ou o GLM 5.3 Flash é o ponto doce: mesma nota do DeepSeek, numa GPU só, a uns US$ 9 por hora. Eu não medi concorrência nela. Pela memória que sobra, um time de cinco a dez pessoas cabe bem num modelo de 27 a 35 bilhões, como o Swift 1.5; no GLM 5.3 Flash, de 198 GB, fica apertado.

A infra própria começa a fazer sentido na casa de 30 pessoas usando ao mesmo tempo, ou quando o código não pode sair da rede. Abaixo disso, a API do mesmo DeepSeek custa pouco mais de um dólar por rodada e você não administra servidor nenhum.

Os melhores abertos pra consumidor

Aqui entra o que roda num PC: RTX 5090 de 32 GB ou Strix Halo de 128 GB unificados.

Só tem um vencedor: o Qwen3.8 Flash-Next na RTX 5090 com o Strata. É um MoE de 125 bilhões com 6 bilhões ativos por token, e o Strata deixa os especialistas mais usados na placa e o resto na RAM. Ficou a 1,5 ponto da versão de datacenter, em velocidade interativa. Eu detalhei ele, com instalação, serviço de carga automática e configuração do OpenCode, em Melhor LLM Open Source: Strata com Qwen 3.8 Flash Next.

O Strix Halo cabe modelo grande, mas a banda de memória dele é sete vezes menor que a da 5090, e um modelo denso de 27B anda a menos de 10 tokens por segundo em Q8, uns 13 em Q4. Serve pra tarefa de fundo, que pode esperar.

E o Swift 1.5 e o ThinkingCap 3.8, os fine-tunes de 27B que foram bem na B300? Eu não rodei os dois na 5090, e nem precisei. Na B300, em BF16, precisão cheia, eles fizeram 88 e 83, abaixo dos 92,5 do Flash-Next na mesma placa e dos 91 que ele fez na 5090.

Numa 5090 eles caberiam em Q4 ou Q5, mas quantizado o melhor cenário é repetir a nota da B300. Rodar em casa custou 1,5 ponto pro Flash-Next e 16,5 pra Ornith-35B. O Qwen 3.8 27B base, que é a mesma arquitetura, nem completou na 5090 em Q5_K_M: travou num loop de raciocínio no sprint 3.

Se os dois já ficaram atrás do Flash-Next com precisão cheia, numa 5090 eles não vão ficar melhores. Não vi motivo pra testar: pra PC, o Flash-Next é claramente a escolha.

E placa pior que a 5090?

É a pergunta que sempre aparece: e quem tem uma placa de 8, 12 ou 16 GB? Pelos meus dados, o caminho do modelo pequeno que cabe inteiro na placa ainda não entrega nada que valha o trabalho pra programar.

Numa placa dessas, em Q4, cabe modelo denso de até uns 20 bilhões; um MoE de 30 bilhões com poucos ativos só roda com parte na RAM. E essa faixa foi mal no v4:

• o GLM-4.7-Flash, um MoE de 30B com 3B ativos, fez 24 na 5090 e 33,5 na B300 com precisão cheia, Tier D nas duas;
• a Ornith-35B, outro MoE com 3B ativos, fez 81 na B300 e caiu pra 64,5 na 5090;
• o gpt-oss-20b nem completou o protocolo;
• o melhor modelo médio foi o Qwen 3.8 27B, com 80, mas ele já precisa de uns 16 GB só em Q4, travou na 5090 e só terminou a 8 tokens por segundo na Strix.

A exceção é justamente o Flash-Next. O Strata foi feito pra rodar ele em placa de 12 GB, segurando a maioria dos especialistas na RAM: o README do projeto publica 53 tokens por segundo em IQ3_S numa RTX 5070 de 12 GB com 64 GB de RAM, e o mínimo declarado é 32 GB somando RAM e VRAM. Com os mesmos pesos e o mesmo motor, a nota em tese não deveria mudar, só a velocidade, que cai pra um terço da 5090. Eu não medi isso; é número do autor.

O porém é a RAM. Com a DRAM quase dobrando de preço num único trimestre deste ano, 64 GB deixaram de ser o upgrade barato que eram.

Abaixo da 5090, eu não perderia tempo com modelo pequeno pra programar. Se for tentar alguma coisa, que seja o Flash-Next com Strata e RAM sobrando, e meça no seu trabalho antes de confiar.

E tem o problema que eu contei no artigo anterior: achar uma 5090 hoje é difícil, e quando acha, o preço fica entre duas vezes e meia e quase cinco vezes o sugerido.

Quanto custa sair dos 150 tokens por segundo?

Depois de algumas horas usando o Qwen local, resumi o problema no X. A média de 159 tokens por segundo da minha rodada parece rápida numa tabela. Numa sessão de programação que passa o dia inteiro gerando código, rodando teste, lendo log e corrigindo o que fez, a espera acumula.

Eu já fico impaciente. Abaixo disso, nem considero pra trabalho diário.

A própria 5090 tem limites além da velocidade. A NVIDIA especifica 32 GB de GDDR7 e 1.792 GB/s de banda e lançou a placa por US$ 1.999. A minha ainda move os monitores e o Hyprland, então deixo 4 GB reservados pro desktop. O resto precisa segurar pesos densos, cache dos especialistas quentes, buffers do motor e a parte residente do cache de KV, que guarda o contexto da conversa.

Minha configuração do Strata oferece 256 mil tokens de contexto com KV em int8 e mantém 32 mil residentes na VRAM; o restante pode ir pra RAM. Isso evita estourar a placa, mas RAM continua muito mais lenta. Enquanto modelos de fronteira do Claude já oferecem janela de 1 milhão de tokens, localmente eu preciso vigiar o que entra na sessão. Carregar uma coleção inteira de skills, plugins e servidores MCP só porque existe espaço no arquivo de configuração é pedir pra desperdiçar contexto e piorar a latência.

Em hardware local, contexto também custa memória e tempo. Eu carrego só o que aquela sessão vai usar.

E se eu colocar mais hardware? A comparação fica assim:

Eu escrevi no post que o Strata só subiria duas instâncias numa máquina com duas 5090. Essa parte ficou desatualizada: o Strata atual divide as camadas entre duas ou mais GPUs. É pipeline parallelism, sem transformar duas placas num bloco simples de 64 GB e sem tensor parallelism maduro.

O ganho por sessão fica longe de 2x. Um teste comunitário com duas 5090 mediu cerca de 22% de ganho na média geométrica de decode e 40% no braço de código. Ajuda na capacidade e dá pra usar as placas como duas instâncias independentes pra dobrar concorrência. Pra mim sozinho, comprar outra 5090 pra cortar uma fração da espera não fecha a conta.

O Mac Studio M5 Ultra começa em US$ 5.499, tem 1,2 TB/s de banda e vai de 96 a 256 GB; a opção de 512 GB foi prometida pro fim de outubro. Ainda não existe benchmark publicado do Strata no Ultra. No M5 Max de 128 GB, o mesmo Flash-Next ficou entre 97 e 119,5 tokens por segundo, dependendo da quantização e do prompt. Meu palpite original de menos de 100 no Ultra não está comprovado, e eu não compraria uma máquina dessas baseado em palpite.

A DGX Spark coloca 128 GB numa caixa compacta, com o GB10 de TDP 140 W e uma fonte de 240 W. A memória entrega só 273 GB/s, quase sete vezes menos que a 5090. A NVIDIA agora pede US$ 6.950.

Receitas reproduzíveis do Flash-Next variam de 22 a 75 tokens por segundo por sessão, dependendo de concorrência, stack, amostragem e modo de raciocínio. Cabe muita coisa. Pra minha tolerância, anda pouco.

Sobra a RTX PRO 6000 Blackwell. Ela tem 96 GB GDDR7 ECC, 1.792 GB/s e potência total de 600 watts. A banda é exatamente a mesma da 5090. Os 96 GB resolvem o aperto de VRAM, permitem mais cache e contexto, mas não compram três vezes a velocidade.

Um benchmark comunitário do Strata mediu 187,4 tokens por segundo no chat curto e 174,3 numa sessão de agente, com bastante variação entre rodadas. É melhor que meus 159,2, só que a NVIDIA lista a placa por US$ 16 mil. Em 22 de outubro, a WAZ mostrava a PNY por R$ 123.299,99 no Pix ou R$ 145.058,81 no preço regular. Já entramos em orçamento de workstation profissional ou servidor.

Hoje não existe, pra mim, uma opção doméstica com modelo bom, resposta realmente rápida e custo razoável. A 5090 funciona, mas 150 tokens por segundo já me cansam. Abaixo dela vira brinquedo; acima dela o preço explode antes da velocidade.

O que eu aprendi no v4

Sobre os modelos

• Quase todo modelo pega o defeito barulhento sem aviso: CVE em gem, chave no código, CORS aberto, SQL injection óbvia. Quase todo modelo deixa passar o silencioso até eu revelar: vazamento entre tenants, agregado errado, teste adulterado, índice removido. O que separa o Tier A do resto é quanto do silencioso ele pega sozinho.
• Tamanho não compra vigilância. O Kimi K2 Thinking, de 1 trilhão de parâmetros, fez 46. O GLM 5.3 full, de 700 bilhões, fez 76, contra 92,5 do Flash da mesma família.
• Modelo trapaceia ou se engana com convicção. O Nemotron adulterou um teste de regressão pra passar, o Qwen3.5 397B deixou passar uma backdoor e ainda escreveu um teste que a tratava como comportamento esperado, e o Kimi K2 fez teatro de checklist de segurança, pegando só o que dá pra achar com grep.
• O salto entre gerações foi de confiabilidade agêntica. O GPT-4o e o GPT-4.1 nem conseguem completar o protocolo sozinhos. Os modelos atuais do topo rodam as sete sprints sem ajuda nenhuma.

Sobre servir modelo aberto

• O mesmo checkpoint muda de nota conforme quem serve. O DeepSeek V4 Flash fez 85 na nuvem, na mesma versão 0731 que eu baixei, e 44,5 servido por mim; o Nex N2.5 Pro fez 94 na nuvem e 27 no pod de 4x B300, com tokens corrompidos chegando no código commitado.
• Nenhum modelo roda rápido do jeito que vem. O GLM 5.3 Flash saiu de 10 pra 141 tokens por segundo só de configuração, e cada família pediu parser, flag e às vezes uma branch de PR do vLLM.
• Rodar em casa cobra preço diferente de cada modelo. Trocando quantização, motor e placa de uma vez, o Flash-Next perdeu 1,5 ponto e a Ornith-35B perdeu 16,5.
• Quem limita a concorrência é a arquitetura do cache de KV e o tempo até o primeiro token. Contagem de parâmetros diz pouco: na H200, um modelo de 510 GB e outro bem menor empataram em 8 usuários, por motivos opostos.

Sobre medir

• Uma rodada tem ruído de quase 10 pontos. Duas notas a 2 pontos de distância empatam.
• O harness pesa. O Gemini 3.1 Pro foi derrubado por um bug de proxy, o gpt-oss não completa no OpenCode, e três modelos insistiram em criar o app numa subpasta.
• Modelo que não faz commit perde trabalho. Correção que fica só no disco some no primeiro git checkout.

A minha hipótese: o hardware caro é parte do modelo de negócio

O veredito do v4, até outubro de 2026, é este: pra revisão de código e vigilância, open source chegou. O DeepSeek V4.1 Flash, o GLM 5.3 Flash e o Qwen3.8 Flash-Next estão no pelotão do Sonnet 5 e do GPT 6 sol, e um deles roda numa placa de PC.

Então por que não está todo mundo rodando em casa? Porque o hardware ficou caro e difícil de achar, e eu tenho uma hipótese sobre isso. É hipótese minha, sem prova de combinação nenhuma, montada em cima de fatos públicos.

Os fatos

• A memória disparou. A TrendForce mediu alta de 93% a 98% no preço de contrato de DRAM só no primeiro trimestre de 2026, e diz que os fabricantes continuam priorizando capacidade pra servidor no quarto trimestre.
• A HBM, a memória das GPUs de datacenter, deve ter o preço médio subindo 121% em 2027 e ocupar perto de 30% das bolachas de DRAM dos três maiores fabricantes até o fim de 2027.
• A Micron saiu do mercado consumidor e matou a Crucial, nas palavras dela, pra atender melhor os clientes estratégicos maiores.
• PC e console subiram de preço, e a Microsoft atribuiu o aumento do Xbox ao custo de memória e armazenamento.
• A RTX 5090, quando aparece nos Estados Unidos, custa de duas vezes e meia a quase cinco vezes o preço sugerido, e o boato é que os chips dela vão pras linhas profissionais. A NVIDIA nega a descontinuação.
• Do outro lado, a Anthropic pediu IPO mirando, segundo a imprensa, uns 2 trilhões de dólares, e a OpenAI está captando a mais de 1,4 trilhão.
• E o discurso sobre modelo aberto chinês endureceu. A Anthropic publicou que DeepSeek, Moonshot e MiniMax destilaram o Claude, e o Dario Amodei, mesmo dizendo que nunca defendeu proibir pesos abertos, pede controle de exportação de chip e teste obrigatório, antes do lançamento, de todo modelo suficientemente capaz, aberto ou fechado.

O ciclo

A explicação mais simples pra memória cara é demanda: datacenter compra tudo e paga mais. Eu acredito nela. O que me incomoda é que nenhum participante grande tem incentivo pra quebrar o ciclo:

1. O discurso diz que só o laboratório de fronteira sabe lidar com esses modelos “perigosos”, e que open source é uma aposta arriscada.
2. Isso puxa a demanda pra nuvem, e a nuvem compra GPU e memória em volume recorde.
3. Os fabricantes vendem com ágio pra quem paga mais e tiram prioridade do consumidor.
4. O hardware bom fica inacessível fora do datacenter.
5. Sem hardware em casa, o open source não é adotado, o que reforça o discurso do passo 1.

Se todo mundo começasse a hospedar o próprio modelo, as contas de IPO de trilhões de dólares deixariam de fechar. O v4 mostrou que o modelo aberto já está pronto pra boa parte do trabalho. O que falta é o hardware chegar na mão de quem trabalha.

O resultado, resumido: o Qwen3.8 Flash-Next servido pelo Strata numa RTX 5090 fez 91, Tier A, com zero nudges e os 14 defeitos plantados resolvidos (dois só depois da revelação), a 1,5 ponto do mesmo modelo rodando numa B300 de datacenter. E fez isso a uns 159 tokens por segundo.

Neste artigo eu detalho o que é o Strata, por que ele importa justo agora, o que ele não resolve, e como eu deixei ele rodando no dia a dia, com carga e descarga automática e integrado no OpenCode.

O que é o Strata

O Strata é um motor de inferência open source, licença MIT, feito em torno de um modelo: o Qwen3.8 Flash-Next, um MoE de 125 bilhões de parâmetros com 6 bilhões ativos por token, que normalmente pede servidor. O código é C++ e CUDA, reaproveita partes do llama.cpp/ggml, e tem builds pra NVIDIA, AMD (inclusive Strix Halo), Intel Arc e Mac. Ele sobe uma API compatível com OpenAI e com Anthropic em localhost.

O truque é tratar o PC inteiro como uma hierarquia de memória. O modelo tem 24.576 especialistas, 512 em cada uma das 48 camadas, e cada token usa só 10 por camada, mais um especialista compartilhado:

• a VRAM guarda os especialistas mais usados, como um cache;
• a RAM guarda todos, e quando o token precisa de um que não está na placa, o processador calcula ele ali mesmo, enquanto a placa trabalha nos outros;
• o SSD guarda uma tabela de consulta de uns 29 GB, da qual o modelo lê poucas linhas por token.

Em cima disso, uma cabeça de especulação que vem com o próprio modelo chuta os próximos tokens e o modelo grande confere todos de uma vez. O README promete a mesma resposta 1,6 a 1,8 vez mais rápido.

Na minha 5090, o log mostra como isso fica na prática. Os 32 GB de VRAM seguram de 10 a 11,5 mil especialistas em uns 20 a 22 GiB, quase metade do total, e em geral de 90% a 97% dos especialistas que cada token pede já estão na placa. O resto a CPU calcula direto na RAM, e só uma fração pequena é copiada pra placa pelo barramento PCIe. É por isso que a CPU também trabalha pesado, como dá pra ver mais abaixo.

Por que isso importa agora

Porque memória virou artigo de luxo. Em 2026 o preço de contrato da DRAM quase dobrou num único trimestre, os fabricantes continuam priorizando servidor, e a Micron largou o mercado consumidor pra atender os clientes grandes. A própria RTX 5090, quando aparece, custa de duas vezes e meia a quase cinco vezes o preço sugerido, como eu contei no veredito.

Nesse cenário, a forma tradicional de rodar um modelo Tier A em casa, com o modelo inteiro dentro da VRAM, é inviável. O Flash-Next em NVFP4 ocupou uns 100 GB de placa na B300; em casa ninguém tem isso.

O Strata inverte a premissa: em vez de exigir VRAM pro modelo inteiro, ele usa a VRAM como cache e a RAM como estoque. É o que permite um modelo Tier A rodar com uma fração da memória de vídeo que ele pediria.

Não é mágica

O Strata faz caber, mas não faz milagre. O mínimo declarado é 32 GB somando RAM e VRAM, mas com isso roda só a versão mais comprimida; a IQ3_S que fez os 91 pede uns 64 GB de RAM. Some uns 80 GB de disco, de preferência SSD, e uma placa de 12 GB pra cima no caminho oficial. Abaixo disso até sobe, tem relato com placa de 8 GB, mas a uns 15 tokens por segundo.

Banda de memória é o que define a velocidade

Na geração de token, o gargalo de máquina local quase nunca é o cálculo. É quantos bytes por segundo a memória consegue entregar pros núcleos, porque cada token precisa ler os pesos ativos do modelo. E aí a diferença entre os tipos de memória é brutal:

A última linha é da minha máquina: a placa está rodando com 8 linhas de PCIe em vez de 16, e o Strata mede isso na inicialização. Mais um motivo pra o cache na VRAM ser tão importante.

O Strix Halo tem 128 GB e cabe muito mais coisa que uma 5090, mas cada byte chega sete vezes mais devagar. Foi isso que eu medi no benchmark: o Qwen 3.8 27B denso em Q8 lê uns 29 GB por token, e na Strix o teto teórico fica perto de 9 tokens por segundo. Eu medi 7,7. A mesma conta na banda da 5090 daria uns 60, sete vezes mais, se o modelo coubesse com o contexto.

É por isso que o desenho do Strata funciona: o caminho quente fica na GDDR7, e o que falta no cache é calculado pela CPU na DDR5, ou atravessa o PCIe, os dois dezenas de vezes mais lentos. Com mais de 90% de acerto no cache, o pouco que fica de fora não derruba a velocidade. Numa placa pequena, o cache cobre menos, mais especialistas vão pela estrada lenta, e a velocidade cai: o próprio autor publica 53 tokens por segundo numa RTX 5070 de 12 GB, um terço da minha 5090.

PC batata não roda

Então esqueça notebook com GPU integrada e 16 GB de RAM. Sem uma placa dedicada razoável, sem 32 GB somando RAM e VRAM e sem SSD, o modelo não sobe, ou sobe e anda na velocidade da RAM, que é a de uma carroça.

E tem o custo de entrada que não aparece na velocidade de geração: o Strata lê a primeira mensagem de cada conversa inteira, e o README fala em uns 60 segundos a cada 30 mil tokens como regra geral. Na minha 5090 é bem mais rápido, uns 100 mil tokens em 16 a 20 segundos, mas numa placa menor conte com o número do README. Agente de código manda prompt de sistema grande, então a primeira resposta de cada sessão demora mais que as seguintes.

Pesado até na minha 5090

Minha máquina não é fraca: Ryzen 9 7950X3D, 96 GB de RAM (o sistema enxerga uns 92), RTX 5090 de 32 GB. Mesmo assim, o Flash-Next ocupa tudo:

• na carga, ele joga uns 50 GB de especialistas na RAM, a uns 3 GB por segundo com o SSD frio, e enche o cache da placa com mais de 20 GiB;
• com tudo carregado, sobram menos de 800 MB de VRAM livre;
• com o servidor de pé, a máquina fica com 88 dos 92 GB de RAM ocupados, e o sistema começa a usar swap.

Este é o btop no meio de uma sessão de trabalho com o OpenCode. O processo do Strata sozinho segura 54 GB de RAM e metade da CPU, com metade das 32 threads do 7950X3D cravadas em 100% e o resto acima de 50%. A 5090 está a 99% de uso, com 30 dos 32 GB de VRAM ocupados e puxando 351 W. Sobram 4 GB de RAM disponíveis, e já tem quase 48 GB em swap.

O efeito colateral aparece no resto do sistema. Com a VRAM no limite, o lançador de aplicativos do meu desktop e o terminal num monitor secundário pararam de abrir direito, e outros programas ficam lentos. A solução foi mandar o Strata devolver uns 2,5 GB de VRAM pro desktop, com a opção --vram-elastic, ao custo de um cache um pouco menor.

Com tudo isso, eu acredito firmemente que a minha máquina é o mínimo pra usar um LLM local em trabalho de programação de verdade, além de exercício pequeno. Com menos que isso, conte com velocidade bem menor, contexto mais curto e o PC inteiro sofrendo enquanto o modelo está carregado.

Como instalar

O caminho oficial no Linux e no Mac é o instalador de uma linha. Ele verifica o SHA-256, não pede root e instala na sua pasta pessoal. Como todo curl | sh, vale baixar e ler antes:

curl -fsSL https://github.com/Niko1221/Strata/releases/latest/download/install.sh -o install.sh
less install.sh
sh install.sh

Depois, o strata launch pergunta modelo, contexto e acesso, baixa o motor certo pra sua placa e o modelo, e começa a servir. Pra scripts, tudo vai por flag:

strata launch                                # telas guiadas
strata launch --model <variante> --yes --no-tui   # sem perguntas
strata launch --status                       # o que está servindo
strata launch --stop                         # parar
strata monitor --url http://127.0.0.1:8080   # velocidade, GPU, memória

Eu usei a variante IQ3_S, a que fez os 91 no benchmark. No disco ela ocupa uns 84 GB em dois arquivos (o modelo de 55 GB e a tabela de consulta de 29 GB), mais uns 7 GB da cabeça de especulação.

A configuração que o strata launch gera é um JSON com os argumentos do motor. Os que importam na minha:

"args": [
  "--expert-cache", "auto",
  "--prefill", "auto",
  "--spec", "4", "--spec-min-p", "0.5",
  "--mtp", "/mnt/data/strata-models/mtp/rt",
  "--max-context", "262144",
  "--kv", "int8",
  "--kv-resident", "32768",
  "--vram-elastic"
]