Programação
Compare correção, qualidade e utilidade prática do código gerado.
Neste gênero, as capacidades mais observadas são Correção, Completude, Qualidade do código.
Diferente de system design, aqui pesa mais se o código realmente funciona do que as decisões de arquitetura em alto nível.
Uma nota alta aqui não garante melhor julgamento de produto, melhor arquitetura nem explicações mais didáticas.
Para que servem modelos fortes neste gênero
implementação, depuração, refatoração e apoio prático ao programar.
O que este gênero sozinho não consegue mostrar
se o modelo é melhor para arquitetura, documentos para stakeholders ou ideação aberta.
Programação: Claude Fable 5 estreia no topo, GPT-5 mini é a escolha mais defensável
Anthropic
OpenAI
OpenAI
Pontuação média por modelo
Como ponderamos
Claude Fable 5 chegou a este gênero e assumiu imediatamente o primeiro lugar, vencendo seu confronto de estreia com a atuação mais forte da tabela. GPT-5.6 também venceu tudo o que disputou até agora. Os dois retrospectos são ao mesmo tempo impressionantes e finos: uma estreia vitoriosa prova que o modelo pode vencer aqui, não que vai continuar vencendo. A ordem exata do topo deve ser lida como um sinal inicial.
O retrospecto mais defensável do gênero pertence ao GPT-5 mini: ele enfrentou mais tarefas de programação do que qualquer um dos líderes e não perdeu nenhuma. Para um modelo de linha leve, uma sequência invicta contra adversários de fronteira é a melhor história de valor desta tabela. O GPT-5.5, em contraste, registra uma das melhores médias do gênero, mas dividiu seus confrontos — código bom que nem sempre venceu o código do outro lado. Claude Sonnet 5 marcou uma média sólida na estreia e ainda assim a perdeu, então sua posição subestima, por ora, a qualidade do que produz.
A correção domina o julgamento aqui, com completude e qualidade de código em seguida — a classificação pune bugs sutis com mais força do que o estilo. A família Gemini ainda não converteu nenhum confronto neste gênero e também ocupa o fundo nas médias. Tudo isso reflete as tarefas e juízes específicos da Orivel: programação vai de algoritmos a design de API, e um punhado de tarefas não cobre esse espaço.
Resumo
GPT-5 mini é a escolha defensável hoje — invicto no maior número de confrontos, a custo de linha leve. Claude Fable 5 e GPT-5.6 parecem ainda mais fortes, mas com evidência inicial. Vale acompanhar se o GPT-5.5 começa a converter suas respostas de qualidade em vitórias.
Esta análise baseia-se nas pontuações de benchmark medidas pela Orivel para este gênero e é atualizada periodicamente. As pontuações são medidas dependentes das condições, não uma verdade absoluta.
Ranking de modelos fortes neste gênero
Este ranking é ordenado pela pontuação média apenas dentro deste gênero.
Última atualização: 25 Jul 2026 01:19
Taxa de vitória
Pontuação média
Taxa de vitória
Pontuação média
Taxa de vitória
Pontuação média
Taxa de vitória
Pontuação média
Taxa de vitória
Pontuação média
Taxa de vitória
Pontuação média
Taxa de vitória
Pontuação média
Taxa de vitória
Pontuação média
| Modelos no ranking | Detalhe | ||||||
|---|---|---|---|---|---|---|---|
| #1 | Claude Fable 5 | Anthropic |
100%
|
91
|
1 | 1 | Ver a avaliação e a pontuação de Claude Fable 5 |
| #2 | GPT-5.6 | OpenAI |
100%
|
86
|
2 | 2 | Ver a avaliação e a pontuação de GPT-5.6 |
| #3 | GPT-5 mini | OpenAI |
100%
|
82
|
5 | 5 | Ver a avaliação e a pontuação de GPT-5 mini |
| #4 | GPT-5.5 | OpenAI |
50%
|
89
|
1 | 2 | Ver a avaliação e a pontuação de GPT-5.5 |
| #5 | Claude Sonnet 5 NOVO | Anthropic |
0%
|
83
|
0 | 1 | Ver a avaliação e a pontuação de Claude Sonnet 5 |
| #6 | Gemini 2.5 Pro |
0%
|
74
|
0 | 5 | Ver a avaliação e a pontuação de Gemini 2.5 Pro | |
| #7 | Gemini 2.5 Flash-Lite |
0%
|
72
|
0 | 3 | Ver a avaliação e a pontuação de Gemini 2.5 Flash-Lite | |
| #8 | Gemini 2.5 Flash |
0%
|
68
|
0 | 5 | Ver a avaliação e a pontuação de Gemini 2.5 Flash |
O que é avaliado em Programação
Critérios e pesos usados neste ranking por gênero.
Correção
35.0%
Este critério foi incluído para verificar Correção na resposta. Ele recebe mais peso porque influência fortemente o resultado final deste gênero.
Completude
20.0%
Este critério foi incluído para verificar Completude na resposta. Ele tem peso relevante porque afeta a qualidade de forma visível, mesmo não sendo o único ponto importante.
Qualidade do código
20.0%
Este critério foi incluído para verificar Qualidade do código na resposta. Ele tem peso relevante porque afeta a qualidade de forma visível, mesmo não sendo o único ponto importante.
Valor prático
15.0%
Este critério foi incluído para verificar Valor prático na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas não define sozinho este gênero.
Seguimento de instruções
10.0%
Este critério foi incluído para verificar Seguimento de instruções na resposta. Ele recebe peso menor porque apoia o objetivo principal, mas não define sozinho este gênero.
Tarefas recentes
Programação
Analisador de Logs de Servidor Web
Escreva uma função Python analyze_logs(log_data) que recebe uma string de múltiplas linhas contendo entradas de logs de servidor web. A função deve analisar esses logs, executar uma análise e retornar um dicionário resumindo os resultados. Cada linha de log válida segue este formato: [TIMESTAMP] LEVEL IP_ADDRESS "REQUEST_METHOD /path" RESPONSE_CODE BYTES_SENT Exemplo de uma linha válida: [2023-10-27T10:00:00Z] INFO 192.168.1.1 "GET /index.html" 200 1543 Sua função deve: Analisar apenas as linhas de log válidas, ignorando graciosamente quaisquer linhas malformadas ou vazias. Calcular as seguintes métricas: total_requests: A contagem total de entradas de log válidas. error_rate: A porcentagem de requisições com LEVEL igual a ERROR, arredondada para duas casas decimais. top_3_ips: Uma lista de tuplas, onde cada tupla contém um endereço IP e sua contagem de requisições, para os 3 IPs mais frequentes. A lista deve estar ordenada em ordem decrescente pela contagem de requisições. busiest_hour: A hora do dia (um inteiro de 0 a 23) que teve mais requisições. O timestamp está no formato ISO 8601 (UTC). Retornar um dicionário com as chaves total_requests, error_rate, top_3_ips e busiest_hour contendo os valores calculados. Trate os seguintes casos extremos: Se a string de entrada log_data estiver vazia, retorne um dicionário com valores zerados ou vazios conforme apropriado (por exemplo, total_requests: 0, top_3_ips: []). Se houver menos de 3 endereços IP únicos, a lista top_3_ips deve conter todos os IPs únicos, ordenados por contagem. Se houver empate para a hora de maior tráfego, retornar qualquer uma das horas empatadas é aceitável.
Programação
Limitador de taxa com janela deslizante e quotas justas multi-inquilino
Implemente uma biblioteca reutilizável de limitador de taxa numa linguagem à sua escolha (Python, Go, TypeScript, Java ou Rust) que imponha quotas de requisições por cliente usando um algoritmo de janela deslizante, além de uma política de partilha justa entre múltiplos inquilinos. Requisitos funcionais: Forneça uma classe ou módulo com um método tal como allow(tenant_id, client_id, now_ms) que retorne se uma requisição é permitida e, quando negada, quantos milissegundos faltam até que a próxima requisição seja permitida (retry_after_ms). Cada cliente é limitado a um número máximo de requisições dentro de uma janela de tempo rolling (por exemplo, 100 requisições por 60.000 ms). A configuração deve ser ajustável por inquilino. Implemente uma verdadeira janela deslizante (ponderada ou baseada em log), não uma janela de baldes fixa por calendário, de modo que rajadas que atravessam os limites dos baldes sejam tratadas corretamente. Adicione um teto global por inquilino de forma que todos os clientes de um inquilino combinados não possam exceder um limite a nível de inquilino, e quando o inquilino estiver saturado a capacidade restante seja compartilhada de maneira justa entre os clientes ativos em vez de ser monopolizada por um cliente. O limitador deve ser seguro sob acesso concorrente a partir de múltiplas threads ou tarefas assíncronas. A memória não deve crescer sem limites: o estado de clientes obsoletos deve ser expurgado ou compactado ao longo do tempo. Entregáveis: A implementação completa com API pública clara e documentação inline das decisões-chave. Uma breve explicação (em comentários ou numa curta seção em prosa) do algoritmo de janela deslizante escolhido e suas compensações entre precisão/memória. Uma suíte de testes cobrindo os casos limite principais descritos abaixo. Casos limite a tratar explicitamente no código e nos testes: Requisições exatamente na fronteira da janela. Um cliente que fica ocioso e depois retorna após a janela ter expirado completamente. Requisições concorrentes competindo pelo mesmo contador de cliente. Relógio retrocedendo ou timestamps duplicados. Saturação do inquilino e redistribuição justa entre clientes concorrentes. Expurgo de estado de cliente obsoleto sem eliminar clientes ativos. Declare quaisquer suposições que fizer (single-process vs distributed, disponibilidade de relógio monotónico, etc.). Se assumir um processo único, descreva brevemente como o design se estenderia para um deployment distribuído.
Programação
Implemente um Simulador Determinístico de Livro de Ordens Limite
Escreva uma solução de arquivo único em Python 3.11 implementando a função process_events(events: list[dict]) -> dict. Não use pacotes externos. A função deve simular um pequeno livro de ordens limite de uma bolsa para um instrumento. Ela recebe uma lista de dicionários de eventos na ordem de entrada e retorna um dicionário com exatamente estas chaves: trades, rejected, book. Tipos de evento: Evento de nova ordem: Campos obrigatórios: type="new", id, side, order_type, qty. side é "buy" ou "sell". order_type é "limit" ou "market". qty é um inteiro positivo. Uma ordem limit também requer price, um número inteiro positivo de centavos. Campo opcional tif é time-in-force: "GTC", "IOC", ou "FOK". Se ausente, use "GTC" para ordens limit e "IOC" para ordens market. Ordens market não podem ter tif="GTC" e não podem ficar repousando no livro. Evento de cancelamento: Campos obrigatórios: type="cancel", id. Cancela a quantidade restante de uma ordem atualmente repousando com esse id. Regras de pareamento: O livro tem bids e asks. Ordens limit buy repousadas são bids; ordens limit sell repousadas são asks. Prioridade preço-tempo é obrigatória: melhor preço primeiro; para o mesmo preço, a ordem repousada aceita mais cedo primeiro. Uma ordem buy casa com asks repousados enquanto puder cruzar: buy market cruza qualquer ask; buy limit cruza asks com preço do ask <= preço limit do buy. Uma ordem sell casa com bids repousados enquanto puder cruzar: sell market cruza qualquer bid; sell limit cruza bids com preço do bid >= preço limit do sell. A quantidade de cada trade é min(quantidade restante do entrante, quantidade restante do repousado). O preço do trade é sempre o preço limit da ordem maker repousada, nunca o preço da ordem entrante. Um registro de trade deve ser anexado imediatamente quando ocorrer, com exatamente estas chaves: buy_id, sell_id, price, qty, taker_id, maker_id. Ordens repousadas parcialmente preenchidas mantêm sua prioridade original com a quantidade restante. Ordens totalmente preenchidas deixam o livro. Comportamento de time-in-force: Ordens limit GTC mantêm qualquer restante não preenchido no livro. Ordens IOC executam o máximo possível imediatamente e então cancelam qualquer restante. Ordens FOK devem ser completamente passíveis de preenchimento imediatamente de acordo com o livro atual e as regras de cruzamento. Se não puderem ser totalmente preenchidas, não produzem trades e não alteram o livro. Se completamente preenchíveis, executam normalmente. Ordens FOK nunca repousam. Regras de validação e rejeição: Se um evento estiver malformado, rejeite-o sem alterar o livro. Anexe um registro de rejeição a rejected com chaves input_index, event, reason. O reason pode ser uma string curta e legível por humanos. Rejeite uma nova ordem se seu id já tiver sido usado por qualquer new order previamente aceita, mesmo que essa ordem anterior já tenha sido preenchida ou cancelada desde então. Rejeite eventos de cancelamento para ids desconhecidos ou ids que não estejam mais repousando. Rejeite qty e price não inteiros, zero ou negativos. Em Python, bool não deve ser aceito como inteiro para esses campos. Ignore campos extras em eventos que seriam de outra forma válidos. Formato de retorno: trades: lista de registros de trade na ordem de execução. rejected: lista de registros de rejeição na ordem de entrada. book: um dicionário com chaves bids e asks. book["bids"] deve listar todos os bids repousados ordenados por preço descendente, depois por tempo original de repouso, cada um como {"id": id, "price": price, "qty": remaining_qty}. book["asks"] deve listar todos os asks repousados ordenados por preço ascendente, depois por tempo original de repouso, cada um como {"id": id, "price": price, "qty": remaining_qty}. Sua resposta deve ser um código Python executável completo definindo process_events. Você pode incluir classes/funções auxiliares e uma pequena seção de auto-teste protegida por if name == "main":, mas a função principal não deve ler stdin nem escrever stdout.
Programação
Implementar aplicação atômica de JSON Patch em Python
Escreva uma implementação em Python 3.11 de uma função denominada apply_json_patch(document, patch) que aplique uma sequência de operações no estilo JSON Patch a um valor compatível com JSON e retorne o valor patchado. O documento de entrada pode ser qualquer combinação de dict, list, str, int, float, bool e None. O patch é uma lista de dicionários de operações. A implementação não deve mutar o documento original nem qualquer objeto aninhado alcançável a partir dele. Se qualquer operação for inválida, a função deve lançar uma classe de exceção personalizada chamada JsonPatchError e deixar o documento original inalterado. Operações suportadas: add, remove, replace, move, copy e test. Use caminhos JSON Pointer com tokens separados por barras, onde a string vazia identifica o documento inteiro, os tokens decodificam ~1 como / e ~0 como ~, e qualquer outro uso de ~ é inválido. Para objetos, um token de caminho é uma chave. Para arrays, um token de caminho deve ser um inteiro não negativo sem zeros à esquerda, exceto o token único 0; apenas para add, o token final pode ser - para anexar. A operação add insere em arrays em um índice de 0 até len(array), anexa para '-', define uma chave de objeto, ou substitui o documento inteiro se o caminho for vazio. A operação remove requer que o alvo exista e o elimina. A operação replace requer que o alvo exista e o substitui. A operação move requer os campos from e path, remove o valor em from e o adiciona em path, e deve rejeitar mover um valor para um dos seus próprios descendentes. A operação copy requer os campos from e path e faz uma cópia profunda (deep copy) do valor de origem para o alvo. A operação test requer value e só tem sucesso se o alvo atual for igual em profundidade (deeply equal) a value, incluindo a igualdade normal do Python para números e igualdade exata para strings, booleanos e None. Cada dicionário de operação deve conter exatamente os campos exigidos por essa operação mais o campo op; campos desconhecidos ou campos ausentes são erros. A função deve ser determinística, razoavelmente eficiente e depender somente da biblioteca padrão do Python. Inclua quaisquer funções auxiliares ou classes necessárias. Não escreva um programa de linha de comando nem use pacotes externos.
Programação
Implemente um Agendador de Tarefas Baseado em Dependências em Python
Escreva uma função ou classe em Python que agende uma lista de tarefas com base em suas dependências. O agendador deve determinar a ordem na qual as tarefas podem ser executadas, agrupando as tarefas que podem rodar em paralelo. A entrada será uma lista de dicionários, onde cada dicionário representa uma tarefa com as seguintes chaves: id: Um identificador de string único para a tarefa. name: Um nome em string para a tarefa. dependencies: Uma lista de IDs em string de tarefas que devem ser concluídas antes que esta tarefa possa iniciar. Sua implementação deve: Receber a lista de dicionários de tarefas como entrada. Retornar um plano de execução válido como uma lista de listas. Cada lista interna representa um 'lote' de tarefas que podem ser executadas concorrentemente. A ordem dos lotes representa a ordem sequencial de execução. A ordem dos IDs de tarefa dentro de um lote não importa. Detectar e tratar dependências circulares. Se um ciclo for encontrado, deve levantar um ValueError com uma mensagem descritiva. Detectar e tratar casos onde um ID de dependência não corresponde a nenhuma tarefa existente. Isso também deve levantar um ValueError.
Programação
Limitador de Taxa com Janela Deslizante e Tolerância a Rajada
Desenhe e implemente um limitador de taxa thread-safe numa linguagem à sua escolha (Python, Go, Java, TypeScript, ou Rust) que suporte os seguintes requisitos: API surface: Exponha pelo menos estas operações: allow(client_id: str, cost: int = 1) -> bool — retorna se a requisição é permitida neste momento. retry_after(client_id: str) -> float — retorna segundos até que pelo menos 1 unidade de capacidade esteja disponível (0 se atualmente permitido). Um construtor que aceite configuração por cliente: rate (unidades por segundo), burst (máx. unidades armazenadas), e um opcional window_seconds para contabilização por janela deslizante. Algorithm: Implemente um híbrido que combine um token bucket (para tolerância a rajadas) com um log ou contador de janela deslizante (para limitar o total de pedidos permitidos dentro de window_seconds, prevenindo abuso sustentado que um token bucket puro permitiria após reabastecimentos). Uma requisição é permitida somente se ambas as verificações passarem. Justifique sua escolha de estrutura de dados para a janela deslizante (log exato vs. aproximação ponderada de dois "buckets") e discuta trade-offs de memória/precisão num bloco curto de comentário ou nota acompanhante. Concurrency: O limitador será atingido por muitas threads/goroutines concorrentes para o mesmo e diferentes client_ids. Evite que um único lock global se torne um gargalo (por exemplo, locks por cliente ou lock striping). Documente por que sua abordagem está correta sob chamadas concorrentes a allow (nenhum duplo gasto de tokens, sem atualizações perdidas). Time source: Torne o relógio injetável para que os testes sejam determinísticos. Use um relógio monotônico por padrão. Edge cases to handle explicitly: cost maior que burst (deve rejeitar, nunca bloquear para sempre). Relógio retrocedendo ou pausas longas (ex.: VM suspensa): amarre (clamp) em vez de explodir, e não conceda tokens ilimitados. Primeiro pedido de um novo cliente (inicialização preguiçosa). Limpeza de clientes obsoletos (a memória não deve crescer indefinidamente se clientes pararem de chamar). Tokens fraccionários / temporização sub-milisegundo. Tests: Forneça pelo menos 6 testes unitários usando o relógio injetável que cubram: permitir/negar básico, drenagem e reabastecimento de rajada, cota de janela deslizante independente do reabastecimento do balde, cost > burst, contenção concorrente num cliente (propriedade determinística: total permitido em T segundos ≤ rate*T + burst), e evasão de cliente obsoleto. Complexity: Declare a complexidade amortizada de tempo de allow e a complexidade de memória por cliente. Entregue: código completo executável (um único ficheiro é aceitável, mas pode separar ficheiros se os identificar claramente), os testes, e uma breve nota de design (máx. ~250 palavras) explicando as suas escolhas e a semântica precisa quando os dois algoritmos discordarem.