Por que Gemini 2.5 Flash Lite — Não GPT-5 ou Claude — Executa o Composer da Cambio

Quando se coloca um modelo de linguagem atrás da superfície de um produto, o caminho mais fácil é recorrer ao modelo de fronteira que lidera o ranking daquele mês. Quanto mais inteligente, melhor, diz o raciocínio, e em escala a diferença de custo desaparece.

A Cambio roda com o Gemini 2.5 Flash Lite — a faixa rápida do Google, não a de raciocínio. É o padrão em produção desde 27 de maio de 2026; antes disso, a mesma camada rodava com o grok-4-1-fast da xAI. Este post traz o raciocínio de engenharia por trás da escolha atual e as condições que nos fariam revê-la de novo.

O que o modelo tem que fazer na Cambio

Dois trabalhos, ambos limitados. Nenhum deles exige muito raciocínio.

O primeiro é a interpretação da mensagem. O modelo recebe uma mensagem curta do usuário e devolve um único objeto JSON: uma intenção de uma lista fechada, sete campos de entidade — moeda de origem, rede de origem, moeda de destino, rede de destino, valor, direção e preferência — e um número de confiança. Não é a primeira coisa a ver a mensagem: um resolvedor determinístico atende a maioria dos turnos sozinho, e o modelo é consultado quando esse resolvedor fica em dúvida. Numa amostra de 209 turnos de produção, a camada determinística respondeu 69% sozinha e o modelo foi acionado em 8%.

O segundo é a narração. O modelo recebe um objeto de cotação estruturado e escreve uma linha curta em linguagem simples em torno dele. Ele não pode escrever um preço, uma taxa ou um valor — o cartão carrega todos os números, e o modelo nunca recebe a tarefa de produzir um. Quando acrescenta uma frase de tom, o código limita essa frase a doze palavras e descarta o que passar disso.

Nenhum dos trabalhos envolve raciocínio multi-etapas. Nenhum trabalho exige que o modelo escolha entre muitas alternativas. Nenhum trabalho tem o modelo interagindo com ferramentas, chamando APIs ou mantendo estado entre turnos. Os requisitos de capacidade são: ler um prompt curto, seguir um formato de saída estruturado, produzir inglês coerente. Todo modelo de linguagem moderno pode fazer isso, incluindo os lançados há dois ou três anos.

Por que modelos de raciocínio de fronteira são a ferramenta errada aqui

Não fizemos um comparativo direto dos modelos de fronteira nesta carga de trabalho, e não vamos publicar um que não fizemos. A escolha não precisava disso. A pergunta nunca foi qual modelo é mais capaz; foi qual modelo é rápido o bastante, barato o bastante e disciplinado o bastante com saída estruturada para duas tarefas que o código determinístico já resolve na maior parte das vezes.

O que medimos foi o nosso próprio sistema. Uma chamada de classificação tem cerca de 70 tokens de entrada e 30 de saída — da ordem de US$ 0,0001 por prompt sem cache a preços de tabela, medido contra o Flash Lite em 26 de maio de 2026 — e um prompt repetido é servido do cache sem chegar ao modelo. Em latência, o caminho determinístico fica em torno de 1,1 segundo ponta a ponta e o caminho que chama o modelo em torno de 2,3. É essa diferença, e não um ranking público, que a escolha do modelo precisa responder.

Passado certo ponto, mais capacidade é orçamento desperdiçado. Quando um modelo já é rápido o bastante e certeiro o bastante para uma tarefa delimitada, a experiência é dominada pela latência, não pelo teto do modelo.

Por que o nível rápido em geral

A lista curta é a faixa rápida dos provedores que a nossa camada de agente suporta: Gemini 2.5 Flash Lite, que a executa hoje; grok-4-1-fast, que a executava antes; e GPT-5 Mini, que continua selecionável. Todos sabem ler um prompt curto, seguir um esquema e escrever uma frase. No nosso volume, todos custam pouco o suficiente para que o preço sozinho não decida.

Então a decisão é de encaixe operacional e não de capacidade: quanto custa uma chamada no volume que realmente rodamos, com que confiabilidade o modelo devolve exatamente o objeto que o nosso esquema pede, como ele se comporta quando o provedor está carregado e o quanto é fácil conviver com esse provedor no dia a dia.

Por que Gemini 2.5 Flash Lite especificamente

Sobre custo: nossos prompts são curtos na entrada e curtos na saída, que é o formato que a faixa rápida precifica melhor. Com cerca de 70 tokens de entrada e 30 de saída, uma chamada custa da ordem de US$ 0,0001 a preços de tabela, e um prompt repetido nem chega ao modelo porque a classificação está em cache. Não publicamos um ranking de preços entre os três, porque não fizemos nenhum que resista a escrutínio.

Sobre saída estruturada: não pedimos texto livre e torcemos. A chamada fixa o tipo de resposta como JSON, entrega ao Google um esquema de resposta com os campos obrigatórios e os enums explícitos, e roda a temperatura zero. Tudo o que volta e não encaixa no esquema é descartado e o turno cai no tratamento determinístico — uma saída malformada custa uma nova tentativa, nunca um cartão errado.

Sobre o comportamento em falha: a camada recebe uma lista ordenada de provedores, Gemini e depois xAI por padrão, e pula em silêncio os que não estiverem configurados. Se todos os configurados falharem, o turno devolve uma forma de segurança em vez de travar o cliente. Uma indisponibilidade do modelo é uma resposta mais lenta, não um composer morto.

Sobre a fase anterior em produção: a primeira versão da Cambio rodou esta camada com grok-4-1-fast. A troca para o Flash Lite em 27 de maio de 2026 não foi por o Grok estar errado. A camada do agente é agnóstica de provedor — xAI e OpenAI continuam selecionáveis por uma única variável de ambiente — então a escolha é reversível.

Por que não a variante de raciocínio

Gemini 2.5 lança uma variante com modo de pensamento. Nós não o usamos. O modo de pensamento é projetado para problemas que se beneficiam de cadeia de pensamento — problemas de múltiplos passos, problemas onde o modelo tem que considerar alternativas, problemas onde passos intermediários de rascunho melhoram a resposta final.

Nenhuma das nossas duas tarefas é assim. Transformar uma mensagem curta em um objeto JSON não melhora com uma etapa de raciocínio, e escrever uma frase em torno de uma cotação que o código já calculou também não. Por isso a chamada define o orçamento de raciocínio como zero. O comentário no nosso próprio classificador diz sem rodeios: não precisamos de cadeia de pensamento para uma classificação de passo único.

Esse ajuste vive no código e não na cabeça de ninguém, e vale para cada chamada que esta camada faz. É o tipo de padrão que compensa deixar escrito: raciocínio de que você não precisa é latência que você paga em todo turno.

O que estamos abrindo mão

Reconhecimento honesto do trade-off. Ao não recorrer a um modelo de fronteira, abrimos mão da margem nas mensagens mais ambíguas: quem digitar algo genuinamente confuso pode receber uma pergunta de esclarecimento mais fraca do que um modelo maior daria. Também abrimos mão de capacidades que a faixa de fronteira vende — janelas de contexto enormes, longas cadeias de chamadas de ferramentas, raciocínio multimodal profundo — nenhuma das quais as nossas duas tarefas usam, e todas as quais importariam se ampliássemos o escopo do modelo. Não vamos ampliar, conforme o post anterior desta série.

Do que não abrimos mão: do caminho determinístico, que resolve a maioria dos turnos sem modelo nenhum; da regra de que todo número do cartão é calculado por código e nunca escrito pelo modelo; e da possibilidade de trocar de provedor em uma linha se a troca deixar de fazer sentido.

Quando revisaríamos

Algumas condições específicas nos fariam reabrir a seleção do modelo novamente.

Se a latência do Flash Lite piorar de forma relevante e continuar assim, o orçamento quebra e trocamos. Acompanhamos a latência do nosso próprio composer e não o número publicado pelo fornecedor, porque é esse que o cliente sente.

Se a qualidade cair em um idioma específico, podemos rotear esse idioma para outro lugar. O assistente já responde em nove idiomas, e a camada aceita uma lista ordenada de provedores, então isso é configuração e não reescrita.

Se os preços mudarem substancialmente — digamos, o Google aumentar as taxas do Flash Lite em 5x ou um concorrente cortar para um décimo — revisamos o eixo de custo. Não mudaremos por uma diferença de preço de 10%, mas uma mudança estrutural importa.

Se um modelo de faixa rápida mais novo se sair melhor nos nossos próprios prompts — os que os clientes realmente digitam, não um ranking público — trocamos. Foi assim que esta camada chegou ao Gemini em primeiro lugar.

A lição geral

Escolher um modelo é uma decisão específica da carga de trabalho, não uma decisão de marca. O "melhor" modelo para um produto depende da forma dos prompts que você está enviando, do orçamento de latência que você tem, da disciplina de saída estruturada que você precisa, do envelope de custo na sua escala e da postura do provedor com a qual você pode conviver. Nenhuma dessas coisas é visível em um leaderboard. Todas elas têm que ser medidas contra sua carga de trabalho real — e reavaliadas periodicamente, porque os provedores lançam novos modelos de nível rápido a cada poucos meses e a resposta pode mudar.

Para a forma da Cambio — prompts curtos e simétricos, orçamento de latência rígido, dois trabalhos estreitos que não precisam de raciocínio — Gemini 2.5 Flash Lite é a resposta certa hoje. Para um produto diferente com uma forma diferente, a resposta certa é genuinamente diferente. Se você está construindo algo semelhante, a conclusão não é "use Gemini Flash Lite". É "construa uma camada de agente independente do provedor, teste o nível rápido contra sua carga de trabalho real e execute o teste a cada trimestre".

O último post desta série vai mais fundo do que qualquer outro até aqui: como as trocas entre redes funcionam na Cambio sem contratos de bridge, e por que esse é um perfil operacional diferente das arquiteturas que boa parte do setor usa para a mesma tarefa.