Em 21 e 22 de setembro de 2026 saíram três modelos de fronteira. A xAI lançou o Grok 4.7 na segunda, com 2,1 trilhões de parâmetros — 40% a mais que o 4.6 — a US$ 2 por milhão de tokens de entrada e US$ 6 de saída. No dia seguinte a Anthropic publicou o Claude Opus 5.5 e a OpenAI respondeu com dois modelos da família GPT-6, o Sol e o Luna.

Os números que interessam estão na tabela de preço. Opus 5.5 custa US$ 4 na entrada e US$ 20 na saída, por milhão de tokens, com leitura de cache a US$ 0,20 — uma queda de 60% nesse item específico. GPT-6 Sol fica em US$ 2 e US$ 10; GPT-6 Luna, em US$ 0,10 e US$ 0,50, com 90% de desconto na leitura de token em cache. Em benchmark, a Anthropic reporta 66,4% no Terminal-Bench 4.0 contra 55,8% do Fable 5.1, e 40% de tarefas concluídas no AutomationBench contra 26,9% do Opus 5. A OpenAI reporta 33,2% no mesmo AutomationBench para o Sol, a US$ 0,27 por tarefa.

Por que isso importa

A notícia não é "modelo novo ficou mais inteligente". É que a distância de preço entre o topo e a base da mesma família virou duas ordens de grandeza. Entre o Luna e o Opus 5.5 há 40x na entrada e 40x na saída. Isso muda o desenho do sistema, não a escolha do fornecedor.

Até o ano passado eu escolhia um modelo por produto e vivia com ele. Com essa escada de preço, escolher um só é desperdício nas duas pontas: ou eu pago modelo de fronteira para classificar e-mail, ou uso modelo barato para escrever código que vai para produção e gasto revisão humana no lugar.

O segundo ponto é o cache. Quando a leitura de token em cache cai 60% ou 90%, o custo deixa de ser dominado pelo tamanho do prompt e passa a ser dominado por quantas vezes você muda o prompt. Prompt de sistema estável e longo ficou barato; prompt montado do zero a cada requisição, não. Isso premia uma arquitetura específica: contexto fixo no começo, variável no fim.

Na prática

O que eu faço em projeto Laravel é declarar as camadas por tarefa, não por modelo, e deixar o nome do modelo na configuração. Assim a troca de setembro não vira caça a string espalhada pelo código:

// config/ia.php
return [
    'camadas' => [
        'triagem'  => env('IA_MODELO_TRIAGEM', 'gpt-6-luna'),
        'redacao'  => env('IA_MODELO_REDACAO', 'gpt-6-sol'),
        'critico'  => env('IA_MODELO_CRITICO', 'claude-opus-5-5'),
    ],
    'teto_mensal_usd' => env('IA_TETO_MENSAL_USD', 50),
];

class RoteadorDeModelo
{
    public function __construct(private GastoMensal $gasto) {}

    public function para(string $camada): string
    {
        // Estourou o teto: cai para a camada barata em vez de derrubar a fila.
        if ($this->gasto->acumuladoUsd() >= config('ia.teto_mensal_usd')) {
            return config('ia.camadas.triagem');
        }

        return config("ia.camadas.{$camada}")
            ?? throw new InvalidArgumentException("camada desconhecida: {$camada}");
    }
}

Três detalhes que eu não pulo:

1. Registrar tokens de entrada, de saída e de cache separados em cada chamada. Sem isso não dá para saber se a conta subiu por volume ou por prompt reescrito.
2. Prompt de sistema imutável, com o que varia no fim da mensagem. É o que faz o desconto de cache existir.
3. Teto de gasto com degradação, e não com erro. Fila que morre por limite de orçamento vira incidente de madrugada.

O que eu faria

Se eu tivesse um sistema em produção usando modelo de fronteira para tudo, eu mexeria esta semana — mas só na camada de baixo. Trocar a classificação e a extração de campo para o modelo mais barato da família é uma mudança de configuração com efeito imediato na fatura, e o erro, quando acontece, é visível e barato de corrigir.

A camada que escreve código ou responde cliente eu não trocaria pelo preço. Trocaria depois de rodar o meu próprio conjunto de casos — de 30 a 50 exemplos reais do projeto, com resposta esperada — porque benchmark público mede a média do mundo, e o que importa é a média do seu domínio.

Grok 4.7 eu deixo de fora por enquanto: o próprio anúncio o posiciona abaixo do topo em capacidade, e o preço dele não é baixo o bastante para competir com o Luna na camada de triagem. É o pior lugar para ficar — nem o mais barato, nem o melhor.

E a parte chata, que eu repito em toda consultoria: antes de trocar qualquer coisa, tenha como medir. Se você não consegue dizer hoje quanto custou a última semana de IA no seu sistema, a resposta para "vale a pena trocar de modelo?" não é técnica, é chute.

Hoje, 22 de setembro de 2026, o time do Next.js publicou uma atualização de segurança fora do calendário: as versões 16.3.6 e 15.5.26. O comunicado oficial explica que as duas atualizam dependências upstream, entre elas o Satori, a biblioteca que transforma JSX em SVG por baixo do ImageResponse de next/og. O advisory GHSA-vcvr-r3jv-pc5j (CVE-2026-94545) tem severidade crítica, com nota 9.5, e descreve execução remota de código.

O recorte é estreito, e isso importa. Só as versões >=16.2.0 <16.3.6 são afetadas, e só a implementação Node.js do ImageResponse. Quem gera imagem no runtime Edge está fora. O 15.x não tem a falha de execução remota: o 15.5.26 traz só endurecimento relacionado. A condição para explorar também é específica. A aplicação precisa colocar um valor controlado pelo atacante dentro do conteúdo, dos atributos ou dos estilos do SVG gerado. Um escape mal feito nesse SVG abre caminho para falhas em outras dependências.

Por que isso importa mais do que parece

Imagem de Open Graph é o tipo de código que ninguém revisa. Ela nasce num tutorial, gera aquela prévia bonita do link no LinkedIn e no WhatsApp, e fica esquecida em opengraph-image.tsx ou numa rota /api/og. O padrão mais copiado da internet é exatamente o que o advisory usa como exemplo de código vulnerável: ler ?title= da URL e desenhar esse texto na imagem.

Esse padrão já era ruim antes da falha. Qualquer pessoa consegue gerar uma imagem com o seu domínio e o texto que quiser, e ainda gasta CPU do seu servidor a cada variação. A falha só transforma um problema de reputação num problema de servidor comprometido.

Tem um segundo ponto. Muita gente trata o bump de patch do framework como tarefa de segunda-feira. Aqui o advisory e o patch saíram juntos, com o detalhe técnico público. A janela entre "saiu a correção" e "tem gente varrendo rota /api/og na internet" costuma ser curta.

Na prática

Primeiro, descubra se você está no intervalo afetado:

npm ls next

Se aparecer 16.2.x ou 16.3.0 a 16.3.5, atualize:

npm install next@16.3.6

No 15.5, atualizar para next@15.5.26 é recomendado, mas não é emergência de execução remota.

Depois, procure onde o projeto usa ImageResponse e olhe de onde vem cada valor que entra no JSX:

grep -rn "ImageResponse" app src --include=*.tsx --include=*.ts

A correção de verdade, que vale mesmo depois do patch, é não desenhar entrada do usuário. Troque o texto vindo da query string por dado que você controla, buscado pelo parâmetro da rota. No Next 16, params é uma Promise:

// app/blog/[slug]/opengraph-image.tsx
import { ImageResponse } from 'next/og'
import { getPostBySlug } from '@/lib/posts'

export const size = { width: 1200, height: 630 }
export const contentType = 'image/png'

export default async function Image({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params
  const post = await getPostBySlug(slug)

  // O slug só serve para buscar. Nunca vai para o SVG.
  if (!post) return new Response('Not found', { status: 404 })

  return new ImageResponse(
    (
      <div
        style={{
          width: '100%',
          height: '100%',
          display: 'flex',
          alignItems: 'center',
          padding: 80,
          fontSize: 64,
          background: '#0b0b0b',
          color: '#fafafa',
        }}
      >
        {post.title}
      </div>
    ),
    { ...size },
  )
}

O título sai do banco ou do markdown do próprio site, não da URL. Se o slug não existe, a rota devolve 404 em vez de desenhar qualquer coisa. getPostBySlug é a sua função de leitura, seja do banco ou do markdown. De bônus, sem API de request a imagem fica em cache, conforme a documentação, e não é redesenhada a cada acesso.

Se você não pode atualizar hoje, o próprio advisory dá o contorno: parar de passar valor controlado pelo atacante para conteúdo, atributo ou estilo do SVG. Na prática, é aplicar o exemplo acima antes do bump.

O que eu faria

Atualizaria hoje quem estiver no 16.2 ou no 16.3. O custo é um patch dentro da mesma minor, e o risco de não fazer é execução remota no servidor.

Quem está no 15.5 pode colocar o 15.5.26 no próximo deploy normal, sem correria. Mas eu aproveitaria para fazer a busca por ImageResponse do mesmo jeito. Se a rota de OG lê texto da query string, isso vira o próximo problema na hora em que o projeto subir para o 16.

E eu tiraria uma regra desse caso: gerador de imagem é renderizador, e renderizador que recebe texto de fora precisa da mesma desconfiança que um template de e-mail ou uma query SQL. A prévia do link parece enfeite, mas o código roda no seu servidor.

Produto não tem essa pessoa. Produto tem mil execuções por dia, sem ninguém olhando, e uma resposta ruim vira registro no banco, e-mail enviado ou cobrança errada. A distância entre esses dois mundos é onde mora todo o trabalho de engenharia — e é a parte que quase nunca aparece na demo.

Texto livre é dívida técnica

O primeiro erro estrutural é deixar o modelo devolver prosa e depois tentar entender essa prosa com regex. Já vi parser de trinta linhas para extrair um valor monetário de uma frase que o modelo escrevia de quatro jeitos diferentes dependendo do dia.

A saída de um LLM dentro de um sistema precisa ser um contrato, exatamente como qualquer outra integração. Hoje isso se resolve com saída estruturada: você declara o schema, o modelo responde dentro dele, e o que chega no seu código é um objeto validável.

{
  "categoria": "reembolso",
  "urgencia": "alta",
  "valor_centavos": 12990,
  "resumo": "Cliente pede estorno de cobrança duplicada em 12/07.",
  "confianca": 0.82
}

Repare no último campo. confianca não é enfeite: é o que permite rotear. Acima de um limiar, o fluxo segue automático; abaixo, cai numa fila de revisão humana. Sem esse número, você só tem duas opções ruins — confiar em tudo ou revisar tudo.

E, mesmo com schema, valide de novo do seu lado. O schema garante a forma, não o sentido. valor_centavos: 999999999 passa em qualquer validação de tipo e ainda assim é absurdo para o seu domínio.

A chamada é lenta, então trate como sistema externo

Um LLM é uma dependência de rede com latência variável, limite de taxa e indisponibilidade eventual. Ou seja: é exatamente igual a um gateway de pagamento, e merece o mesmo tratamento arquitetural.

Na prática, isso significa que a chamada raramente deve acontecer dentro do request HTTP. No pipeline de vídeo que mantenho, tudo que envolve modelo — transcrição do áudio, seleção dos melhores trechos, geração de título e descrição — está em jobs separados, com retentativa e backoff. O usuário do painel vê um status mudando, não uma tela travada por quarenta segundos.

Fila também é o que torna a falha barata. Quando a API responde 529 num pico, o job volta pra fila e roda dez minutos depois. Sem fila, isso vira um erro 500 na cara do cliente e um chamado no suporte.

Cache é a diferença entre viável e inviável

A conta que ninguém faz na fase de protótipo é o custo por operação em escala real. Um pipeline que processa duzentos itens por dia e chama o modelo três vezes por item faz dezoito mil chamadas por mês. Se você não mediu isso antes de aprovar a feature, vai descobrir na fatura.

Duas coisas cortam esse custo de forma quase gratuita:

• Cache de resultado por hash da entrada. Se o input é idêntico, a resposta pode ser reaproveitada. Em classificação de tickets, chamado repetido é regra, não exceção — vi taxa de acerto de cache passar de 30% só com isso.
• Escolher o modelo por tarefa. Classificar em cinco categorias não precisa do modelo mais caro do catálogo. Redação final para o cliente talvez precise. Tratar "o modelo" como uma escolha única para o produto inteiro é desperdício.

E tem a economia que é só disciplina: não mande o documento inteiro quando três parágrafos resolvem. Contexto é o item de linha mais caro da conta.

Sem avaliação, você está chutando

Essa é a parte que mais separa protótipo de produto. Como você sabe que mexer no prompt melhorou alguma coisa?

A resposta útil é chata: um conjunto de casos com o resultado esperado, rodado a cada mudança. Não precisa de ferramenta sofisticada — comecei com um arquivo de casos e um comando Artisan cuspindo uma taxa de acerto no terminal. Cinquenta casos reais, tirados do que já aconteceu em produção, incluindo os feios: texto truncado, mensagem em duas línguas, cliente irritado escrevendo tudo em caixa alta.

Sem isso, cada ajuste de prompt é superstição. Alguém troca uma frase, testa em dois exemplos, acha que melhorou, e ninguém percebe que quebrou um caso que funcionava desde março.

Projete para o erro, não para o acerto

A pergunta que eu faço em toda reunião de escopo de IA é: o que acontece quando o modelo erra?

Se a resposta for "o cliente recebe um e-mail errado" ou "a cobrança sai com o valor errado", a funcionalidade não pode ser automática. Ela pode sugerir, pré-preencher, ordenar por prioridade, rascunhar — tudo com uma pessoa apertando o botão final. Se a resposta for "o item fica na categoria errada e alguém arrasta de volta", aí sim automatize.

Essa distinção define o produto muito mais do que a escolha do modelo. E ela é uma decisão de negócio, não técnica.

O resumo

A parte de IA de uma feature de IA costuma ser dez linhas de código. O resto — schema, validação, fila, cache, avaliação, fallback e desenho do momento em que o humano entra — é engenharia comum, do tipo que todo dev sênior já sabe fazer. A boa notícia é que a experiência anterior conta. A má é que ninguém escapa dessa parte.

O problema é que muito time escreve código de 2013 dentro de um framework de 2026. A stack evoluiu; o hábito, não.

O sintoma: array como contrato

O primeiro cheiro é sempre o mesmo. Um método de service que recebe array $data, mexe em dez chaves e devolve outro array. Ninguém sabe o que entra, ninguém sabe o que sai, e o autocomplete da IDE vira decoração. Aí o time compensa isso com documentação em Notion, que envelhece em duas sprints.

PHP tem tipagem forte o suficiente para acabar com isso desde a 7.4, e desde a 8.x ficou confortável de verdade. Um objeto de valor com readonly resolve mais do que um bloco de PHPDoc:

final readonly class NovaAssinatura
{
    public function __construct(
        public int $clienteId,
        public PlanoAssinatura $plano,
        public Carbon $inicioEm,
        public ?string $cupom = null,
    ) {}
}

Agora o contrato existe no código, não na cabeça de quem escreveu. Se alguém tentar passar um cupom como int, o erro aparece no CI, não no suporte.

Enum é a ferramenta mais subaproveitada da linguagem

Máquina de estados em string solta é a causa de bug mais chata que já depurei. 'pending', 'PENDING', 'pendente', 'aguardando' — todos no mesmo banco, todos escritos por pessoas diferentes ao longo de dois anos. Enums nativos, que chegaram no PHP 8.1, matam essa categoria inteira de problema.

enum StatusDemanda: string
{
    case Aberta = 'aberta';
    case EmVisita = 'em_visita';
    case Orcada = 'orcada';
    case Concluida = 'concluida';

    public function podeAvancarPara(self $proximo): bool
    {
        return in_array($proximo, $this->proximosPassos(), strict: true);
    }
}

O Eloquent faz o cast direto no model, o Filament monta o select sozinho a partir do enum, e a regra de transição fica no mesmo arquivo que define os estados. Num marketplace de serviços que eu mantenho, esse único movimento cortou a maior fonte de chamado do suporte: pedido que "pulava" etapa porque alguém escreveu a string errada numa migration de correção.

Fila não é otimização, é design

A outra herança do PHP antigo é achar que tudo tem que acontecer dentro do request. Envio de e-mail, geração de PDF, chamada de gateway, processamento de imagem — tudo empurrado no ciclo do HTTP porque "é rápido". Até o dia em que o gateway demora oito segundos e o cliente clica duas vezes no botão de pagar.

Filas mudam a forma de modelar a operação, não só o tempo de resposta. Quando o job é a unidade de trabalho, você ganha de graça três coisas que dificilmente ia implementar na mão: retentativa com backoff, isolamento de falha e visibilidade. Eu tenho pipeline de vídeo em produção onde cada etapa — baixar, transcrever, selecionar trecho, cortar, publicar — é um job separado. Quando a transcrição falha por limite de API, só aquela etapa volta para a fila. O resto do pipeline não sabe e não precisa saber.

A regra prática que uso: se a operação depende de um sistema que eu não controlo, ela não roda no request.

Teste que você escreve porque quer

A objeção clássica contra teste em PHP era a ergonomia. PHPUnit funciona, mas escrever suíte nele nunca foi prazeroso. Pest resolveu isso de um jeito quase injusto — a barreira caiu tanto que hoje é mais rápido escrever o teste do que abrir o Postman e reproduzir o cenário na mão.

it('bloqueia checkout quando a loja está fechada', function () {
    $loja = Loja::factory()->fechada()->create();

    postJson('/api/checkout', payloadValido($loja))
        ->assertStatus(422)
        ->assertJsonPath('erro', 'loja_fechada');
});

Não é sobre cobertura de 100%. É sobre ter uma rede embaixo das regras que dão dinheiro: pagamento, cupom, zona de entrega, transição de status. Essas eu testo sempre. Layout de e-mail, não.

O que eu não faço mais

Duas coisas que já defendi e abandonei.

A primeira é encher o projeto de camada. Repository que só faz proxy pro Eloquent, DTO para toda ação, interface com uma implementação só. Isso não é arquitetura limpa, é imposto de indireção. O Eloquent já é a camada de dados; brigar com ele custa caro e não devolve nada.

A segunda é perseguir a última versão de tudo no dia do lançamento. Laravel tem ciclo previsível e política de suporte clara justamente para você planejar a atualização. Subir versão major numa sexta porque saiu no Twitter é escolha, não obrigação.

O ponto

PHP moderno é uma linguagem tipada, com enums, com atributos, com um ecossistema que resolve fila, painel, teste e deploy sem você escrever nada disso do zero. A linguagem cumpriu a parte dela. Falta o hábito acompanhar — e isso não se resolve trocando de stack, se resolve lendo a documentação da versão que você está usando e parando de escrever array $data.