Modelos recomendados

Existem milhares de modelos para os quais você poderia apontar AI_MODEL. A maioria deles não vai funcionar para este curso, e o motivo se resume a uma única capacidade.

O único requisito obrigatório: tool calling

Um agente é um modelo que consegue pedir à sua aplicação para executar algo em seu nome. Ele mesmo não executa nada.

Ele retorna uma solicitação estruturada dizendo, em essência, "chame get_weather com a cidade definida como Brasília, depois me diga o que voltou." Seu código executa a função e devolve o resultado.

Essa solicitação estruturada é o tool calling, e um modelo sem essa capacidade não pode se transformar em agente, não importa como o código em volta seja escrito. Não é uma questão do modelo ser mais fraco ou mais lento. O formato de mensagem do qual todo o curso depende simplesmente não existe nele.

Além do tool calling, o curso se apoia em algumas capacidades relacionadas ao longo do caminho: passar argumentos com tipagem estrita, controlar se uma ferramenta é usada ou não, e retornar saída estruturada, ou seja, uma resposta moldada segundo um schema que sua interface consegue renderizar em vez de um texto solto. Os modelos variam na confiabilidade com que fazem isso, e é por isso que existe a lista de recomendações abaixo.

Se algo quebrar mais adiante, suspeite do modelo

Esse é o instinto de depuração mais útil de todo o curso. Se uma lição funciona para todo mundo, menos para você, e seu código está igual à solução, tente um modelo recomendado antes de assumir que o problema está no seu código. Uma limitação do modelo e um bug produzem saídas no console muito parecidas.

JunoO único requisito obrigatório: tool calling Tool calling significa que o modelo responde com uma solicitação em vez de uma resposta: o nome de uma função e o que passar para ela. Seu código executa a função e devolve o resultado.

Essa troca de idas e voltas é a ideia central de um agente. Um modelo que não consegue fazer essa solicitação não é um agente mais fraco, ele simplesmente não é um agente, então essa é a primeira coisa a verificar em qualquer modelo que te interesse.

JunoO único requisito obrigatório: tool calling A divisão para guardar na cabeça: o modelo decide, seu código executa. Tool calling é o formato de mensagem que permite ao modelo dizer qual função e quais argumentos, e tudo que o curso constrói se apoia nisso.

Quando você for olhar um modelo fora da lista abaixo, essa é a capacidade a confirmar primeiro. As páginas dos provedores costumam chamar isso de "function calling" ou "tools", e é uma questão de sim ou não, não uma questão de grau.

JunoO único requisito obrigatório: tool calling O suporte não é um único flag, e é daí que vêm as surpresas. Um modelo pode emitir tool calls e ainda ser inconsistente nas coisas em que as lições mais avançadas se apoiam: respeitar um schema de argumentos estrito, respeitar uma escolha forçada de ferramenta, ou emitir várias chamadas em um único turno.

Então "suporta tools" no card de um modelo significa que o formato de mensagem existe, não que todo comportamento que o curso demonstra vai se manter. É essa lacuna que a lista testada abaixo está fechando para você.

A lista de recomendações

Todo modelo abaixo foi testado contra o fluxo de trabalho real de agente do curso, não avaliado de forma abstrata em benchmarks. Todos são rápidos e de baixo custo.

Use este quando	Modelo	Rota do provedor
Você quer o padrão	gpt-5.4-nano	OpenAI
Você quer a rota mais barata fora da OpenAI	mistralai/ministral-3b-2512	OpenRouter
Você quer mais margem	gpt-5.4-mini	OpenAI
Você quer o modelo mais novo e leve em custo	gpt-5.6-luna	OpenAI
Você quer um modelo mais novo e equilibrado	gpt-5.6-terra	OpenAI
Você quer um Mistral maior	mistralai/ministral-14b-2512	OpenRouter

gpt-5.4-nano é a recomendação se você não quer pensar muito no assunto. Ele passou em todas as verificações de capacidade das quais o curso depende, e é a rota verificada mais barata para o fluxo de trabalho completo.

Algumas observações sobre o resto. O Ministral 3B é uma alternativa econômica, não uma melhoria de qualidade, então escolha-o pelo preço. A família 5.6 é mais nova que a 5.4, embora mais novo não signifique mais barato, e o Nano continua sendo o padrão para quem se preocupa com custo. O Ministral 14B funciona, mas foi um pouco menos consistente que o 3B no fluxo combinado de tool calling e saída estruturada do curso, e é por isso que ele fica mais abaixo na lista.

Os modelos da OpenAI também são acessíveis pela OpenRouter, caso você prefira manter uma única conta e uma única chave. openai/gpt-5.4-nano na OpenRouter é uma rota verificada.

JunoA lista de recomendações Pegue o gpt-5.4-nano e siga com o curso. É o modelo mais barato que passou em todas as verificações, e escolher um modelo não é a parte interessante disso tudo!

Se quiser experimentar outra coisa depois, a tabela está aqui e nada te impede.

JunoA lista de recomendaçõesgpt-5.4-nano é o padrão por um bom motivo: é a rota mais barata que passou em todas as verificações de capacidade que o curso precisa.

O único motivo para subir de nível é ter mais margem nas lições mais avançadas, onde o agente lida com várias ferramentas em um único turno. gpt-5.4-mini é o menor passo que ajuda nesse sentido, e vale a pena testá-lo antes de assumir que o problema está no seu prompt.

JunoA lista de recomendações A ordenação aqui é sobre consistência no fluxo combinado de tool calling e saída estruturada do curso, que é um teste mais específico do que um benchmark e, por isso, mais relevante. O Ministral 14B é um modelo competente que ficou atrás do 3B exatamente nesse fluxo, e esse é o tipo de resultado que rankings gerais não vão te mostrar.

Vale generalizar: quando você avaliar um modelo para trabalho com agentes, teste o formato dos seus turnos reais. Pontuações agregadas de raciocínio preveem isso mal, e um modelo mais barato que mantém seu schema de forma confiável vence um modelo mais inteligente que sai da linha.

Chamadas de ferramentas sequenciais versus paralelas

Alguns modelos emitem várias tool calls em um único turno, e outros emitem uma chamada por turno e repetem o ciclo. Ambos completam o curso sem problema.

Se seu modelo só chama uma ferramenta por vez, você ainda vai chegar ao mesmo resultado. Só que você não vai ver o turno em lote demonstrado em uma lição mais adiante, em que o modelo pede duas ferramentas de uma vez. Isso é uma escolha de design do modelo, e não é algo que você precise corrigir.

JunoChamadas de ferramentas sequenciais versus paralelas Alguns modelos pedem várias ferramentas de uma vez, outros pedem uma, esperam, e então pedem a próxima. Ambos terminam o curso e ambos dão a mesma resposta.

Então, se uma lição mostra duas tool calls em uma única resposta e a sua faz isso uma depois da outra, não tem nada quebrado. É o estilo do modelo, não um bug seu.

JunoChamadas de ferramentas sequenciais versus paralelas Os dois padrões chegam ao mesmo resultado, e a diferença está no design do modelo, não em nada do seu código.

É útil saber disso quando você comparar a saída do seu console com a de uma lição: um modelo que repete uma chamada por vez em loop faz mais idas e voltas, então é mais lento e custa um pouco mais por tarefa, mas a lógica que você escreveu é idêntica nos dois casos.

JunoChamadas de ferramentas sequenciais versus paralelas A distinção começa a importar quando a latência é uma restrição real. Chamadas paralelas condensam buscas independentes em uma única ida e volta, enquanto um modelo sequencial paga a latência completa por ferramenta, e isso se multiplica rapidamente em um turno que envolve quatro ou cinco ferramentas.

Isso também muda seu tratamento de erros. Um turno em lote pode retornar várias tool calls das quais uma falha, então o loop precisa devolver um resultado para cada chamada que recebeu, incluindo as que falharam, ou o próximo turno chega com um buraco no histórico.

Modelos gratuitos

Endpoints gratuitos existem, principalmente pela OpenRouter, e são uma forma razoável de aprender sem gastar nada.

A rota gratuita sugerida para este curso é google/gemma-4-26b-a4b-it:free na OpenRouter. Trate-a como um experimento, e não como uma das recomendações acima, porque endpoints gratuitos têm limite de taxa, ou seja, o provedor limita quantas requisições você pode fazer em um determinado período e recusa o restante, com frequência o suficiente para não ter passado pelo mesmo processo de testes.

Duas ressalvas valem para qualquer rota gratuita:

• A disponibilidade muda. Um modelo gratuito que funciona hoje pode ter limite de taxa aplicado ou ser removido no mês seguinte, e as políticas de camada gratuita mudam com frequência suficiente para que qualquer lista impressa em documentação fique desatualizada.
• A consistência também muda. Rotas gratuitas costumam alternar entre provedores por trás dos panos, então o mesmo prompt pode se comportar de forma diferente de uma execução para outra. Quando você está aprendendo um conceito novo, essa variabilidade dificulta saber se um resultado estranho veio do seu código ou da rota.

Se uma rota gratuita interromper uma lição, troque para um modelo pago verificado da lista acima, por poucos centavos. É a forma mais rápida de descartar o modelo como causa do problema e continuar.

Verifique primeiro as configurações de Privacidade

Antes mesmo de habilitar endpoints gratuitos, abra as configurações de Privacy da OpenRouter. Rotas gratuitas podem enviar suas requisições para provedores com políticas de dados diferentes, e é nessa página que você decide quais são permitidos.

JunoModelos gratuitos Rotas gratuitas são uma boa forma de acompanhar o curso e experimentar sem gastar nada. Mas são um lugar ruim para estar quando algo dá errado.

O motivo é simples: você não consegue diferenciar uma resposta estranha de uma rota instável, e é exatamente isso que você precisa conseguir distinguir enquanto está aprendendo. Se uma lição começar a se comportar de forma estranha, gaste alguns centavos em um modelo pago antes de gastar uma hora revisando seu código!

JunoModelos gratuitos Duas coisas mudam por baixo de uma rota gratuita: a disponibilidade e qual provedor de fato está te atendendo. As duas tornam os resultados mais difíceis de reproduzir de uma execução para outra.

Isso é aceitável para ler e explorar, mas ruim para depurar. Mantenha um modelo pago configurado como a opção para a qual você troca no momento em que uma lição parar de se comportar como esperado, assim você consegue descartar a rota como causa em segundos.

JunoModelos gratuitos Endpoints gratuitos têm limite de taxa, e vale a pena esperar como isso se manifesta: um erro 429, ou uma fila que estende os tempos de resposta o suficiente para parecer que travou. Nenhum dos dois se apresenta claramente como um problema de cota quando visto de dentro do seu próprio código.

A configuração de Privacy merece uma resposta deliberada, não o valor padrão. A capacidade gratuita é subsidiada, e os termos de retenção e treinamento variam de acordo com o provedor em que sua requisição cai, o que é decidido por requisição, e não por você.

Saindo da lista

Experimente livremente. Essa é a maior parte da graça. Guarde a única regra de depuração de antes: quando algo não funcionar como esperado em uma lição mais adiante, verifique se é uma limitação do modelo antes de sair caçando erros no seu código.

Catálogos e preços de modelos mudam mais rápido do que a documentação, então trate qualquer nome específico de modelo aqui como uma fotografia de um momento. A própria página de modelos do provedor é sempre a fonte mais confiável sobre o que existe e quanto custa.

JunoSaindo da lista Vá e experimente outros modelos. A lista é um ponto de partida, não uma cerca, e experimentar é a maior parte da graça.

Dois hábitos mantêm isso sem dor de cabeça: verifique se o modelo consegue chamar ferramentas antes de culpar seu código, e copie os IDs de modelo direto da página do provedor, e não de qualquer coisa escrita há um tempo, esta página incluída!

JunoSaindo da lista Experimente livremente, e mantenha a única regra de depuração: quando uma lição mais adiante se comportar mal, teste um modelo que você já sabe que funciona antes de revisar seu próprio código.

Leia os IDs de modelo direto da página atual do provedor. Os catálogos mudam rápido o suficiente para que um nome na documentação seja apenas uma fotografia de um momento, e um ID descontinuado falha com uma mensagem que não se parece nada com "esse modelo não existe mais".

JunoSaindo da lista Trate todo nome de modelo nesta página como uma afirmação datada. Os catálogos dos provedores giram numa escala de semanas, e a postura honesta para uma documentação é nomear a capacidade que realmente importa, tool calling, e apontar para o catálogo em tempo real para saber o que atualmente tem essa capacidade.

Quando você for avaliar algo novo, teste contra um turno real do curso, não contra uma pontuação de benchmark. O modo de falha que importa é um modelo que responde bem mas mantém mal o schema de ferramentas, e nenhuma pontuação agregada vai te avisar sobre isso.

Para onde ir a partir daqui

Chat Completions e Responses cobre os dois formatos de API que você vai encontrar e por que este curso opta por um deles. Se você ainda não salvou os valores do seu provedor, Configuração do provedor é a página que faz isso.