GPT-4.1 mini é o modelo pequeno da família GPT-4.1 que a OpenAI apresentou em 14 de abril de 2025. Recebe texto e imagens e gera texto. Suporta chamadas de funções e saídas estruturadas, portanto pode ser considerado para funções específicas como extrair campos, ordenar notas ou consultar informações de vários documentos.
Em 2026 ainda faz sentido avaliá-lo para uma tarefa bem definida. De acordo com os preços oficiais da API da OpenAI, consultados em 30 de outubro de 2026, suas tarifas padrão de entrada e saída de texto são inferiores às do modelo de ponta mais recente GPT-6 Astra. Isso permite incluí-lo entre os candidatos para uma função pequena; não prova que seja mais barato que qualquer novo modelo nem que reduza o trabalho total. A revisão de erros também conta. Esta comparação não representa o que a Crazyrouter faturou no teste que explico aqui.
Testei organizando documentos de um projeto fictício por meio da API da Crazyrouter. Conseguiu combinar uma mudança de responsável com outra de data e conservar uma condição do documento original. Porém, quando encontrou duas datas incompatíveis, deixou um estado que não refletia a necessidade de confirmá-las. Para uma aplicação que converte notas em tarefas, ambas as observações importam.
Os dados e as chamadas são de 30 de outubro de 2026. O experimento foi feito com documentos, instruções e respostas em chinês simplificado; este artigo não mede o desempenho em português.
O que pedir ao GPT-4.1 mini antes de automatizar uma lista
A documentação da OpenAI indica uma janela de contexto de 1.047.576 tokens, uma saída máxima de 32.768 tokens e um corte de conhecimento de 1º de junho de 2024. A janela ampla permite reunir fontes relacionadas em uma solicitação. Não garante que cada detalhe seja interpretado corretamente, nem equivale a uma quantidade fixa de palavras.
Para começar, escolheria uma saída que se possa contrastar: responsável, data limite e condição de aceitação, com os documentos que respaldam cada tarefa. Assim se pode distinguir entre encontrar um dado e aplicar bem uma modificação. Pedir apenas «resuma estas notas» deixa mais trabalho pendente se o que a aplicação precisa é uma lista atualizada.
Explicar código ou interpretar uma imagem são outras possibilidades descritas para o modelo, mas não fizeram parte deste teste. Também não executei ferramentas externas. Embora o modelo proponha uma chamada a uma função, é a aplicação que deve executá-la e controlar seus efeitos.
Primeira chamada: uma nota com resposta conhecida
Usei a interface Chat Completions compatível com OpenAI da Crazyrouter. Também existe o acesso pela API da OpenAI; os endereços desta seção correspondem ao canal que utilizei. Para testá-lo, crie uma conta ou inicie sessão, gere uma chave API e verifique a disponibilidade do modelo e as condições atuais. O catálogo de modelos de conversa da Crazyrouter serve como ponto de consulta; é um catálogo geral, não uma medição de qualidade.
Base URL: https://api.crazyrouter.com/v1
Model: gpt-4.1-mini
API key: leia sua chave Crazyrouter de uma configuração segura
Se seu cliente permite definir uma conexão compatível com OpenAI, insira esses valores nos campos correspondentes. Para HTTP direto, envie um POST para https://api.crazyrouter.com/v1/chat/completions, com autenticação Bearer e Content-Type: application/json. Se o cliente adicionar a rota por sua conta, use apenas a Base URL. Não inclua a chave em código público nem em capturas.
Este corpo ilustra uma primeira solicitação com uma nota e sua modificação. Está escrito em português para explicar o procedimento; não é o prompt original do experimento e não o enviei para a API.
{
"model": "gpt-4.1-mini",
"messages": [
{
"role": "system",
"content": "Retorne um objeto JSON com owner, deadline e sources. Use uma data ISO. Aplique apenas a alteração indicada e conserve o resto. Não invente dados; use null se faltar informação."
},
{
"role": "user",
"content": "Nota A: Marta prepara o relatório para 9 de novembro de 2026. Nota B, aprovada e vigente: a data do relatório muda para 12 de novembro de 2026; a responsável continua sendo a mesma."
}
],
"temperature": 0,
"max_tokens": 6000,
"stream": false,
"response_format": { "type": "json_object" }
}
O texto gerado é obtido em choices[0].message.content. Antes de conectá-lo a outra função, verificaria que não esteja vazio nem truncado, que possa ser interpretado como JSON e que mantenha Marta como responsável com a data de 12 de novembro. É o resultado esperado deste exemplo, não uma resposta observada do modelo.
Para isolar problemas, você pode começar apenas com a nota A e adicionar a B depois. Se não receber conteúdo, revise a conexão e a resposta do serviço. Se receber conteúdo mas os campos não coincidirem com as notas, você já está diante de um problema de resultado, não diante de um teste suficiente de que a função está pronta.
O teste completo: decidir quais alterações estão vigentes
No experimento real preparei 51 documentos curtos sobre doze tarefas. Havia versões iniciais, alterações aprovadas, rascunhos, discussões e registros antigos que reutilizavam os mesmos identificadores. Os nomes e os fatos eram fictícios. Cada solicitação completa registrou 26.430 tokens de entrada, longe do máximo de contexto.
Pedi uma linha por tarefa com id, owner, deadline, status, acceptance, sources e conflicts. O momento de referência do cenário era 30 de outubro de 2026 às 18:00. Apenas alterações já vigentes deveriam ser aplicadas, substituindo os campos expressamente modificados e conservando o resto. Os rascunhos e os documentos de outros projetos não podiam sobrescrever a tarefa atual.
Também estabeleci duas regras para o incerto: deixar null quando faltasse informação e conservar as alternativas quando houvesse decisões incompatíveis sem prioridade definida. No segundo caso, o estado deveria passar a «por confirmar».
Isso evita uma simplificação habitual: tratar o documento mais recente como se contivesse toda a verdade. T06 tinha uma alteração aprovada cuja vigência começava em 2 de novembro. Nas duas respostas, o modelo manteve o responsável anterior e a condição de devolver os primeiros 20 resultados, sem adiantar a nova quantidade de 50.
O que resolveu bem: uma tarefa distribuída entre três documentos
O documento B01 de T01 atribuía o trabalho a Zhou Ning para 4 de novembro e exigia conservar registros de auditoria durante 180 dias. C01 mudava a data para 9 de novembro. C02 transferia a responsabilidade para Zheng Yan e mantinha as demais condições.
O modelo retornou Zheng Yan, a data 2026-11-09 e a conservação de 180 dias. Também incluiu B01, C01 e C02 como fontes. Os dois testes completos coincidiram nesses dados.
Figura 1. Diagrama que preparei com os documentos fictícios e a primeira resposta completa. Conserva os valores chineses e as explicações em inglês; o texto desta seção os explica em português. Não é uma captura de uma aplicação. As relações entre campos e fontes procedem de minha revisão; a API retornou as fontes da tarefa como conjunto.
Há uma função aproveitável aqui: reunir alterações parciais sem perder o que continua vigente. Não se trata apenas de redigir um resumo agradável. A saída contém valores concretos que se podem contrastar e depois utilizar, se passarem nas verificações necessárias. O experimento não incluiu uma interface que permitisse abrir automaticamente a citação exata de cada campo.
O que deixaria pendente antes de importar
T02 tinha duas decisões válidas, com datas de 10 e 12 de novembro. Nenhuma anulava a outra. GPT-4.1 mini retornou deadline: null e conservou as duas datas com suas fontes, mas deixou status: "待办", que significa «por fazer». O valor exigido era 待确认, «por confirmar».
Além disso, conflicts deveria ser um arranjo de cadeias de texto e continha um arranjo aninhado. A resposta continuava sendo JSON válido: poder lê-la com um analisador não garantia que tivesse os tipos nem o estado corretos.
Figura 2. Casos da primeira resposta guardada, com valores originais em chinês e explicações em inglês. T03 requer pedir informação; T02 requer resolver decisões existentes. As ações sugeridas são propostas, não resultados de uma correção automática. O estado errado e o arranjo aninhado não foram reparados.
Antes de importar uma linha, verificaria os tipos, sua correspondência com as fontes e a coerência entre campos. Se as fontes mantêm uma data em disputa, o estado não deveria apresentar a tarefa como uma atribuição normal já definida. Essa verificação precisa de informação sobre o conflito, não apenas observar se deadline está vazio.
T03 mostra por quê: responsável e data eram null porque não estavam nos documentos, e não porque houvesse duas decisões enfrentadas. A aplicação deveria ajudar a formular a próxima pergunta correta. Não construí essa tela nem medi um processo de aprovação; é uma decisão de design que decorre das respostas observadas.
O que essas chamadas permitem concluir
Preparei as respostas esperadas antes de chamar o modelo. Depois comparei os campos, as fontes e a estrutura com um programa e revisei os documentos. Cada um dos dois testes completos obteve 47/48 campos principais corretos, 12/12 linhas com as fontes requeridas e 11/12 linhas com a estrutura solicitada. Por T02, nenhum atendeu todos os requisitos.
Houve um teste preliminar com três tarefas e duas solicitações completas sobre as mesmas doze. Foram três chamadas de geração no total, sem solicitações de reparo nem alterações manuais nas respostas. Não são 24 tarefas independentes, nem uma estimativa de estabilidade a longo prazo.
Os parâmetros das solicitações completas foram temperature=0, max_tokens=6000, stream=false e response_format=json_object. Não enviei um JSON Schema rigoroso. Portanto, essa falha de tipos não prova uma falha da imposição de esquemas rigorosos. Também não testei imagens, execução de ferramentas, o limite de contexto nem documentos em português.
Por fim, há que considerar a vida útil do modelo. O aviso da OpenAI de 14 de outubro de 2026 programa a retirada de gpt-4.1-mini-2025-04-14 de sua API para 14 de janeiro de 2027. Uma chamada bem-sucedida através da Crazyrouter não permite deduzir seu calendário futuro de disponibilidade.
Antes de financiar um teste próprio, eu revisaria as condições de uso, a faturação e a disponibilidade do canal. Depois conservaria algumas poucas notas com respostas conhecidas: uma alteração válida, um dado ausente e um conflito sem resolver. Esse pequeno conjunto permite avaliar outro modelo sem perder o critério da função. Se você já converte notas em tarefas, que sinal utiliza para impedir que uma decisão pendente termine como uma tarefa confirmada?