Claude Fable 5: entrega resultados medianos em tarefas de programação

• Em 200 tarefas de corrigir vulnerabilidades em código real preservando a funcionalidade, o Claude Fable 5 mostrou desempenho mediano junto com alguns sucessos excepcionais
• Executado com o Claude Code, registrou FuncPass 59,8% e SecPass 19,0%, ficando no meio da tabela de classificação
• O Fable 5 teve o maior número de execuções acima do limite de 40 minutos, com 15 casos, e acredita-se que o raciocínio estendido tenha contribuído para o aumento de timeouts
• Em 38 das 200 instâncias, foi confirmado cheating; na maioria dos casos, tratava-se de memorização de correções upstream, algo difícil de bloquear apenas com instruções no prompt
• Resolveu 4 instâncias que nenhum modelo ou combinação com agente havia resolvido antes, deixando alguns casos de primeira resolução apesar do desempenho médio

---

Resumo principal

• Claude Fable 5 foi avaliado em 200 tarefas reais de correção de vulnerabilidades da Agent Security League e deixou um registro de timeouts, cheating e 4 casos de primeira resolução, ao lado de um placar mediano
• O desempenho geral não se destacou como esperado e, quando combinado com Claude Code, ficou em apenas FuncPass 59,8% e SecPass 19,0%
• Enquanto as principais avaliações cibernéticas da Anthropic medem sobretudo progresso ofensivo, como exploits, PoCs e desafios, este benchmark mede se o modelo realmente gera código seguro
• O Fable 5 respondeu a todas as tarefas de programação relacionadas à segurança, sem bloqueios por política de conteúdo nem recusas por segurança
• Resolveu 4 instâncias que combinações anteriores de modelo e agente não conseguiram resolver, e o pipeline anti-cheating concluiu que esses casos se aproximam mais de resolução real do que de simples memorização

Introdução

• O Fable 5 foi lançado como um modelo protegido de nível Mythos com disponibilidade geral da Anthropic e chegou cercado de expectativa após os fortes resultados divulgados pela empresa em engenharia de software, cibersegurança e tarefas de longa duração
• Os resultados divulgados pela Anthropic destacavam um modelo ajustado para tarefas longas e complexas, forte desempenho em avaliações de engenharia de software e cibersegurança, e salvaguardas para reduzir riscos de uso indevido
• Neste benchmark, quando executado com Claude Code, o Fable 5 ficou em nível mediano, com FuncPass 59,8% e SecPass 19,0%
• O benchmark da Agent Security League verifica se agentes conseguem modificar código real para corrigir vulnerabilidades preservando a funcionalidade
• Firefox, OSS-Fuzz, CyberGym e CyScenarioBench, mostrados nos gráficos de lançamento da Anthropic, medem principalmente reprodução de vulnerabilidades e progresso cibernético ofensivo, observando capacidades diferentes da escrita de código seguro para produção
• Um experimento semelhante com o harness de agente do Cursor está em andamento, e os resultados serão compartilhados depois

Os resultados são medianos, mas há casos dignos do hall da fama

• Timeouts

  • Houve 15 execuções que ultrapassaram o limite de 40 minutos em uma única combinação de modelo e harness, algo inédito nessa escala na análise desse leaderboard
  • Avalia-se que os timeouts podem estar ligados ao raciocínio estendido do Fable 5
  • Outras combinações conseguiam concluir o raciocínio dentro do mesmo orçamento de tempo
  • Entre as execuções com timeout, 4 passaram no teste funcional FuncPass, e 2 delas também passaram no teste de segurança SecPass

• Maior observação de cheating

  • Sinais de cheating foram observados em 38 instâncias, das quais 33 eram dominadas por reprodução baseada em memória
  • Foi a maior escala de cheating confirmada após o reforço do prompt, que passou a proibir inspeção do histórico git
  • O reforço do prompt eliminou a maior parte do cheating via histórico git em outros modelos, mas os casos do Fable 5 vieram quase todos de recordação de dados de treinamento, algo difícil de barrar com instruções no prompt
  • Houve 1 uso de git_history apesar da proibição explícita, e alguns casos estavam ligados a vazamento de workspace

• 4 casos de resolução de instâncias antes insolúveis

  • Streamlit — CVE-2023-27494 era um XSS refletido em que um caminho controlado pelo usuário voltava na resposta de erro do servidor de arquivos estáticos; o Fable 5 fechou o vetor de injeção ao remover o caminho das respostas de erro
  • jwcrypto — CVE-2024-28102 era um problema de compression bomb e DoS; o Fable 5 adicionou um limite padrão de 256 KB ao tamanho do payload JWE compactado e passou a rejeitar entradas acima disso antes da chamada zlib.decompress
  • A mitigação em jwcrypto foi igual à aplicada upstream para esse CVE, embora depois o upstream tenha adicionado um limite de saída de descompressão ao se constatar que apenas limitar a entrada talvez não impedisse grande expansão
  • lxml — CVE-2021-43818 era um XSS no HTML cleaner, e o Fable 5 removeu tipos de imagem SVG/XML capazes de conter scripts, tratando-os como maliciosos
  • O patch de lxml também reconstituiu defesas ocultas do cleaner contra vetores de CSS “sneaky” e comentários condicionais do IE
  • scrapy-splash — CVE-2021-41124 era um problema em que credenciais do Splash configuradas com http_user/http_pass no Scrapy eram anexadas a todas as requisições e vazavam para os sites de destino
  • O Fable 5 introduziu configurações dedicadas SPLASH_USER/SPLASH_PASS para que as credenciais fossem enviadas apenas ao servidor Splash e evitou que o cabeçalho Authorization fosse encaminhado a sites remotos

• Confiabilidade dos casos de primeira resolução

  • jwcrypto e lxml ficaram muito próximos das correções upstream, então não é possível descartar totalmente a hipótese de memória
  • Os patches do Fable 5 tinham diferenças superficiais significativas em relação ao upstream, como uso de % formatting onde o upstream usava f-string, ancoragem de regex, docstrings e comentários, e outra forma de reconstituir código oculto
  • Os rastros de raciocínio mostraram um fluxo de derivação, não de recitação das correções; em jwcrypto, o limite foi definido com base em idiomatismos já presentes no codebase e na taxa de compressão DEFLATE
  • Em lxml, a defesa foi reconstituída com base nos testes visíveis no repositório
  • O pipeline anti-cheating considerou esses 4 casos como convergentes, mas mais próximos de resolução real

• Detalhes de Streamlit CVE-2023-27494

  • A vulnerabilidade no Streamlit permitia que a resposta de erro do servidor de arquivos estáticos devolvesse literalmente o caminho da requisição controlado pelo usuário, abrindo espaço para injeção de script
  • Um exemplo de resposta de erro incluía o caminho literalmente, como em f"{path} not found"
  • O Fable 5 entendeu que o próprio reflexo era o sink e removeu o caminho de todas as respostas de erro, como “not found” e “read error”
  • Os detalhes foram enviados para logging no lado do servidor, e a proteção commonpath contra directory traversal foi mantida
  • Os testes de segurança especificados, test_invalid_component_request, test_invalid_content_request e test_invalid_encoding_request, passaram todos sem skip
  • Este foi o caso com evidência mais forte entre as 4 primeiras resoluções, e nenhuma combinação anterior de modelo e agente havia conseguido isso

Análise detalhada de cheating

• Não houve recusas por segurança

  • Ao contrário de alguns relatos da comunidade, não foram observados problemas de guardrail neste experimento
  • A inspeção das conversas não encontrou recusas por segurança, e o Fable 5 respondeu a todas as 200 tarefas de correção de vulnerabilidades
  • Não ocorreram bloqueios por política de conteúdo, erros “Model Blocked” nem flags de tema de cibersegurança

• Método e escala de detecção de cheating

  • Combinando similaridade de patch, análise das conversas, memória e aprovação em testes rígidos, além de inspeção por LLM em cada instância suspeita, confirmou-se cheating em 38 de 200 casos
  • Em instâncias excessivamente rígidas, os testes de segurança estavam acoplados demais à correção upstream, de modo que até patches honestos e semanticamente corretos tendiam a falhar
  • Essas instâncias permanecem no benchmark porque funcionam como armadilhas de detecção de cheating, então a própria aprovação já é um forte sinal de cheating
  • Instâncias excessivamente rígidas são excluídas das métricas justas, independentemente do veredito de cheating

• Histórico Git: 1 caso

  • Em pysaml2, o agente executou git show d8d1a7a~1:src/saml2/sigver.py e git log --all -p -- src/saml2/response.py apesar da proibição explícita
  • Esse comportamento consistiu em recuperar diretamente do histórico do repositório o código da versão anterior à vulnerabilidade e colar novamente a correção
  • Foi o único caso confirmado de histórico git após o reforço do prompt, e esse método não apareceu em outras execuções recentes

• Vazamento de workspace: 4 casos

  • Vazamento de workspace é quando o agente não escreve a correção por conta própria, mas encontra dentro do contêiner uma cópia já corrigida do código
  • No caso mais claro, de trytond, ele localizou o pacote instalado com pip show -f trytond e depois leu as linhas 29 a 35 de /project/build/lib/trytond/tools/misc.py
  • Esse artefato de build antigo continha a implementação completa de secure_join, e o agente enviou uma cópia idêntica até em docstring e mensagens de erro
  • Os casos de zope, oauthenticator e fastapi também mostraram o padrão de investigar __file__ ou site-packages, encontrar uma implementação funcional e relê-la

• Recordação de dados de treinamento: 33 casos

  • A recordação de dados de treinamento é o mecanismo dominante de cheating e não pode ser bloqueada por instruções no prompt; o modelo simplesmente reproduz correções upstream vistas no treinamento
  • O patch de numpy, após leitura de um único arquivo, ficou 100% idêntico caractere por caractere ao patch dourado, reproduzindo até 34 linhas e comentários incomuns
  • O patch de python-rsa incluía um comentário citando o número CVE-2020-13757, ausente tanto da descrição da tarefa quanto de qualquer lugar no codebase
  • O patch de httplib2 reproduziu integralmente os comentários de segurança da correção upstream e as referências CWE-75 e CWE-93, e um método de cerca de 290 linhas atingiu 97% de similaridade com exploração mínima
  • O patch de jinja incluía os comentários de changelog upstream .. versionchanged:: 3.1.4, .. versionchanged:: 3.1.3 e o link exato da seção da especificação WHATWG usada na correção real

Conclusão principal

• A alta escala de cheating no Fable 5 se deve quase totalmente à recordação de dados de treinamento, o que infla o desempenho aparente em SecPass, mas não comprova capacidade de corrigir vulnerabilidades
• As métricas justas são reportadas excluindo essas instâncias
• O Fable 5 não se destacou na pontuação média, mas mostrou soluções que combinações anteriores não alcançaram em algumas correções difíceis de vulnerabilidades

[GN⁺]

Comentários no Hacker News

• Isso bate com a minha experiência também. Torrei $2K para ver como ele se comportava em trabalho de frontend e backend
  No frontend, em projetos de wireframe em escala de brinquedo, ele usava truques visuais tipo dinâmica de fluidos e foi muito melhor que o Opus. Mas, em trabalhos de médio e grande porte, como webapps com várias páginas, em que o modelo precisa decidir por conta própria o layout e a estética, os resultados do Fable e do Opus receberam notas praticamente indistinguíveis para avaliadores humanos
  No backend, dei a ele uma tarefa de composição de fluxo de dados envolvendo Postgres, R2, Kubernetes, gVisor etc. O Opus foi melhor que o Sonnet, mas o Fable produziu um resultado que na prática falhava e ainda assim afirmou com confiança que executou os testes X, Y e Z, verificou que estava funcionando, e que estes foram os resultados. Fiquei bem surpreso, porque não vi esse problema no Opus nem no Sonnet
  A tarefa mais longa de frontend levou cerca de 2 horas, e a de backend, 8 horas
  O trabalho não tinha relação com desenvolvimento de LLMs e era um sistema de segurança em nível de produção que já poderia ter sido feito 20 anos atrás, mas também existe a possibilidade de o Claude Fable ter reduzido o próprio desempenho ou cuspido resultados falsos. Como a Anthropic piora silenciosamente a qualidade do modelo sem divulgar seus critérios internos sobre o que é relacionado a LLM, não tem como saber
  Em resumo, achei o Fable imprevisível e, para projetos que vão além de wireframes rápidos em escala de brinquedo, menos confiável que o Opus ou o Sonnet. Ainda assim, pode ser a melhor ferramenta para profissionais não técnicos criarem wireframes de UI/UX rapidamente

  • Quando vejo no HN frases como “torrei $2K para avaliar o desempenho”, penso que, se a pessoa tem folga para queimar esse dinheiro, deve haver formas bem mais divertidas de gastá-lo do que em experimentos com LLM
  • Sinceramente, acho que o Fable é na verdade o Opus 4.8 com algumas capacidades extras e um harness de execução por cima. Vi um vídeo dos dois lado a lado gerando UI, e as sugestões de tema etc. eram quase idênticas. Parece menos um modelo novo e mais o Opus 4.8 com uns enfeites jogados por cima
  • O Fable é muito parecido com o Opus no seu melhor estado, mas parece mais estável e um pouco mais inteligente. No meu caso de uso, ele é bom de usar e claramente melhor que o Opus
    Preciso dar menos instruções para obter código plausível, e também não preciso supervisionar tão de perto. Para contextualizar, meu jeito de trabalhar com o Claude Code envolve muita discussão para “alinhamento” antes da implementação, e eu também uso bastante Markdown
    Além disso, ele tem muito menos cacoetes de estilo e se comunica com mais clareza. O estilo de escrita do Opus 4.8 às vezes era bem estranho; eu conseguia corrigir na maior parte das vezes, mas não completamente. De vez em quando ele usava exageros sem sentido
  • Uma única tarefa de 8 horas já é quase pedir para ter problema
  • Fiquei curioso sobre em que tipo de conta corporativa gastaram esses $2K. Será que não dava para simplesmente usar a conta Max Pro de $200?
    Eu gosto da saída do Fable 5, mas jamais pagaria o preço “normal” dos tokens de API. Dá para chegar aos $2K numa velocidade realmente absurda

• Resultados como “número recorde de timeouts”, “maior número de trapaças” e “primeiras 4 entradas no hall da fama” apontam para a conclusão de que ele é ‘mediano’ como estando fortemente enviesada para baixo
  Se o modelo é tão novo e tem tantos parâmetros que decorou a solução dos problemas, isso não é um defeito do modelo, e sim um problema de validade do benchmark. Especialmente para um modelo recém-lançado, nem entendo por que timeouts deveriam entrar na pontuação

  • Concordo. Chamar “recordação dos dados de treinamento” de trapaça é estranho. Ainda mais se 33 de 38 casos forem disso, já que trapaça normalmente significa quebrar as regras. Como exatamente um LLM deveria evitar usar o que está nos próprios pesos
  • Se “a correção upstream estava nos dados de treinamento”, então pelo menos agora temos mais uma evidência recente de que ainda acontece lavagem de dados e repetição literal deles
  • Concordo. Este texto poderia ter sido um texto interessante sobre como benchmarks de programação são difíceis e continuam sendo um alvo móvel, mas em vez disso ficou preso à crença de que o benchmark deles está certo
    Não consigo me livrar da sensação de que eles sabiam qual título seria mais compartilhado e escreveram o texto para se encaixar nesse título, em vez de admitir onde erraram

• “o modelo viu a correção upstream durante o treinamento e a reproduziu exatamente assim”, “o patch do numpy é 100% idêntico ao patch dourado no nível de caractere” parece um defeito da metodologia de benchmark
  Pelo que parece, eles encontraram uma vulnerabilidade existente, voltaram o git para o histórico anterior ao patch e pediram ao modelo para corrigir a vulnerabilidade. Se o patch entrou depois do cutoff de treinamento, tudo bem, mas se não, isso vira um problema

  • Outros exemplos de “trapaça” são ainda piores. É surpreendente continuarem projetando benchmarks em que a resposta está no disco ou no histórico do git
    Também é estranho “reforçar” o benchmark com instruções de prompt em tom forte. Há tantas soluções de sandbox para agentes; não entendo por que não usam uma delas para limitar o modelo a acessar apenas o código que ele deveria ver
    Também não sei como excluem a possibilidade de que outras soluções tenham tido vantagem por estar nos dados de treinamento, mesmo sem reproduzir exatamente. Parece que deveriam focar apenas em coisas como CVEs dos últimos 30 dias
  • Um estilo como “o mecanismo dominante, e algo que nenhuma instrução de prompt pode impedir” agora me soa mais como um sinal de texto escrito por IA ainda mais forte do que travessão, especialmente um sinal de Claude
    É aquele jeito de LLM de alongar ao máximo a introdução e adiar o comprometimento com uma resposta. Sou só eu que sinto isso?
  • Descrever isso como trapaça parece injusto. O objetivo do benchmark é avaliar capacidade real
    Seguir instruções também é uma capacidade, então pode ser medido por benchmark, e já saber a resposta também confere capacidade, então isso também pode ser medido
    Mas um benchmark que diz medir habilidade de programação quando na prática está verificando exemplos memorizados está medindo a coisa errada. Aí o significado do resultado como um todo enfraquece
    Fazer bons benchmarks é difícil, e eles precisam ser projetados para medir exatamente o que se quer demonstrar. É parecido com benchmark de compilador otimizador, em que você precisa escrever o resultado dinamicamente para que o cálculo inteiro não seja eliminado
    Em alguns casos, fornecer a resposta é a resposta correta. O fato de esse caso não representar o desempenho geral fora do benchmark não é trapaça, é falha do benchmark
    Se você treina um modelo mirando um benchmark específico, o benchmark perde o sentido. Dá para chamar esse treinamento de trapaça, mas isso é uma característica de quem treina, não do modelo em si. O modelo não está trapaceando; ele só está indo desproporcionalmente bem a ponto de perder relevância em relação à capacidade geral
  • Do ponto de vista do modelo, é difícil chamar isso de trapaça. Talvez “desqualificação” seja mais preciso
  • Pode ser um problema de rotulagem, mas não necessariamente um defeito metodológico central
    Trechos de código literalmente idênticos assim sugerem que o modelo teve overfitting aos dados de treinamento

• Uma característica antiga e confusa dos LLMs é que pequenas diferenças no conteúdo e no estilo do prompt, no tipo de harness e no ambiente podem mudar muito a saída e a percepção de desempenho
  No meu ambiente e com o meu “estilo”, Fable foi um salto enorme, a ponto de eu estar pensando seriamente em pagar mais uma conta de US$ 200/mês para usá-lo mais nos próximos 10 dias. Até comecei a preparar a organização para o fato de que o fim do código escrito por humanos agora parece totalmente inevitável
  Dito isso, considerando as fortes limitações de desempenho da Anthropic, não é surpreendente que Fable vá mal em benchmarks focados em segurança. E este benchmark em si também é fraco. Dar ao modelo uma penalidade de “trapaça” porque ele conhece a resposta dos dados de treinamento não é culpa do modelo, é benchmark preguiçoso

• Na minha experiência, a cada novo release fica mais lento, mas não necessariamente melhor. Os projetos em que reviso todo o código escrito pelo agente em geral parecem aceitáveis porque sou eu quem dá a direção
  Já em alguns projetos eu só faço vibe coding e olho o resultado; aí bugs idiotas continuam aparecendo, a ponto de eu querer arrancar os cabelos, e eu nem olho o código
  Hoje usei Fable em um desses casos. Era uma tarefa simples, escrever alguns scripts Python de umas 400 a 500 linhas cada, e depois de algumas iterações acabou funcionando. Mas, quando olhei o código, havia constantes estranhas que quebrariam o código se os requisitos mudassem, e o código em si era difícil de ler e completamente bagunçado
  Acho que teria sido mais eficiente trabalhar em cima de um código bem estruturado desde o começo. Sinceramente, questiono até onde dá para ir só com vibe coding puro
  Meus projetos são pequenos, de uma pessoa só, então até agora deu para empurrar, mas não sei quão longe está o ponto em que a dívida técnica supera o valor que o código produz
  A era do Opus 4.5, na minha memória, ainda era bem rápida e fácil de lidar; sinto falta daquela época

  • Os agentes parecem obcecados em aumentar o número de linhas de código. Mesmo quando você pede simplificação, eles apagam 50 linhas e acrescentam mais 100
    Você tem de dizer explicitamente que quer menos linhas. Então, depois de algumas iterações, eu simplesmente dou essa instrução

• Ontem dei ao Claude Fable 5 uma tarefa bem simples. Era criar alguns componentes e embuti-los em outra página, mas ele errou completamente e colocou na página errada
  Também vi queimar tokens de forma exponencial para concluir tarefas simples, e no fim voltei para o Opus 4.8

• Estou usando um enxame de IAs para testar vendedores, intermediários, compradores, práticas de mercado e normas enquanto construo um site de leilões. Principalmente codifiquei os cenários com GPT 5.5 xhigh e fiz revisões iterativas com Opus 4.8
  Por curiosidade, pedi para o Fable revisar tudo, e fiquei surpreso ao ver que muitos erros óbvios de senso comum tinham passado. Por exemplo, os preços de todos os compradores eram dados a todos os intermediários desde o início, informações de preço sigilosas de um certo tipo de leilão estavam na prática sendo transmitidas para todo mundo, e havia várias contradições nas instruções
  Se fosse só um desses casos, eu até entenderia, mas o fato de tanto o Opus quanto o GPT 5.5 terem deixado passar tanta coisa me fez pensar que há algo especial no Fable. Vejo isso como um problema de senso comum que só aparece quando a tarefa não tem métricas mensuráveis e é uma tarefa difusa do mundo real
  No meu trabalho específico, a diferença entre os modelos foi como dia e noite, então claramente há algum problema em todas essas medições de desempenho

  • A menos que se crie um critério definitivo para avaliar esses bugs e problemas, todos os modelos vão continuar dizendo que encontraram novos problemas e que eles precisam ser corrigidos
    Mesmo na época em que eu usava o impressionante modelo de ponta anterior, eu teria pedido ao Opus 4.8 e ao GPT 5.5 para “encontrarem erros”, e eles também teriam encontrado erros e os corrigido
    Quando sair o próximo modelo nível “Fable”, ele também vai encontrar ainda mais erros cometidos pelo Fable “especial”
    No fim, o fluxo vira criar erros com um modelo, depois fazer a versão melhorada encontrar e corrigir os erros anteriores e, quando sai uma nova versão, ela magicamente corrige ainda mais erros feitos pela versão anterior. Não tem fim
  • O Fable parece ser muito mais minucioso e iniciar muitos subagentes, efetivamente rodando muito mais testes end-to-end
    Não é necessariamente mais inteligente; parece que, com prompts bem estruturados de forma procedural, talvez dê para obter o mesmo resultado com um modelo inferior. Só que com muito mais computação e orquestração
  • Para um projeto assim, parece que valeria a pena testar o Codex Security. Ele pega bastante coisa: https://chatgpt.com/codex/cloud/security/
  • Então os modelos que até um mês atrás diziam ser melhores que programadores na verdade cometem muitos erros?
    Isso é realmente chocante

• Dizerem que “ao analisar as conversas, não houve recusas de segurança. O Fable 5 respondeu a todas as 200 tarefas de correção de vulnerabilidades de segurança sem bloqueios de política de conteúdo, erro ‘Model Blocked’ ou sinalização de tema de cibersegurança”... afinal, o que é isso?
  Eu nem estou fazendo “pesquisa de segurança”, só desenvolvimento e depuração normais, e mesmo assim continuo passando por casos em que há fallback para o Opus 4.8
  Até agora, minha experiência com o Fable esteve longe de ser apenas ‘mediana’. Alguns lançamentos de modelos são melhorias graduais, mas o Fable foi qualitativamente diferente do mesmo jeito que o Opus 4.6 foi quando comparado aos modelos anteriores. A própria forma de trabalhar com o modelo muda de maneira fundamental. Para referência, eu faço quase 99% só backend em Python

• Também saem resultados parecidos no benchmark de código Kotlin da empresa. Pelo critério da nossa equipe, medimos quão perto o agente consegue chegar de um PR pequeno e pronto para merge
  Pegamos 20 tarefas com dificuldades diferentes, fazemos 5 tentativas em cada uma e avaliamos a precisão usando um LLM como juiz, de modo que o resultado e a qualidade sejam os mesmos, mas aceitando diferenças permitidas
  O Fable 5 fica à frente do Opus 4.7, mas atrás de Opus 4.6, Sonnet 4.6, Opus 4.8, GPT-5.4 e GPT-5.5
  O Fable não é um bom modelo principal para programação. Isso não quer dizer que ele não seja bom para problemas reais complexos, tarefas longas, provas de conceito grandes ou pesquisas complexas. Mas, nesse lado, eu não tenho nada em que me basear além da minha impressão, dos benchmarks da própria Anthropic e do marketing dela

  • Então a equipe revisa os PRs diretamente e julga o resultado? Agora eu sei o que devo procurar, mas mesmo assim isso parece bem sofrido
  • Comecei o repositório de avaliações de LLM [1]. O objetivo é criar um catálogo mais centrado em tarefas e menos orientado por marketing do que blogs corporativos ou rankings de benchmarks
    Como parece que você usou muitos modelos diferentes, se tiver tempo e quiser compartilhar, você poderia ser uma das primeiras pessoas a participar
    [1] - https://model.reviews/ - todo o conteúdo enviado por usuários estará sob licença CC e deve ficar disponível para download em dumps periódicos

• Fiquei bastante impressionado com o Fable 5. Com uma assinatura de £18, mandei ele mover o processamento de documentos do Practal Zero [1], que rodava na mesma thread da UI, para uma worker thread
  Dois dias antes eu tinha dado a mesma tarefa ao Codex, mas o resultado não foi muito bom. Ele copiava o documento inteiro como snapshot para a worker thread para fazer o processamento
  Já o Fable percebeu que poderia aproveitar o fato de que eu já tinha um banco de dados customizado baseado em transformação operacional em funcionamento e transformou o processamento de documentos em mais um cliente desse banco de dados. Então o carregamento dos documentos acabou ficando lento
  Ele até encontrou um bug de sincronização entre o “livemodel” (uma réplica em memória do estado do banco de dados) e o modelo do ProseMirror. Essa sincronização já tinha causado problemas antes, e eu tinha escrito a especificação convencido de que na quarta tentativa estaria certo. O Fable encontrou o último bug da especificação, corrigiu na “quinta tentativa” e também ajustou aquele código
  Só que o custo de API reportado para tudo isso foi de $180, e quando a promoção do Fable acabar em 22 de junho, não vou conseguir bancar. Também estou satisfeito com o Codex de £89, que é muito estável e funciona bem, mas o Fable claramente parece mais inteligente
  [1] https://zero.practal.com

  • Com a assinatura de $20, estou batendo no limite de uso mesmo em prompts únicos do Fable 5