Pare de pagar mais do que precisa por inteligência | DevDay 2026

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Stop Overpaying for Intelligence | DevDay 2026 · Canal: OpenAI · 22:49 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos de IA

Resumo

A conversa explica por que o custo por tarefa concluída é uma métrica mais útil do que o custo por token e como escolher um modelo que atenda ao nível de qualidade esperado. Os palestrantes apresentam quatro formas de otimizar custos: prompt caching, programmatic tool calling, ajuste do reasoning effort e processamento em lote ou flexível. Também compartilham exemplos de clientes e recomendações para melhorar o aproveitamento do cache. A orientação final é testar mudanças de forma iterativa, usando evals para equilibrar qualidade, custo e latência.

Pontos-chave

Avalie o custo por tarefa concluída, incluindo o trabalho humano necessário quando o modelo não resolve a solicitação.
Defina a tarefa e o nível de precisão esperado antes de escolher o modelo.
Compare modelos e configurações em uma curva de Pareto para encontrar o melhor equilíbrio entre custo e precisão.
Teste modelos menores em tarefas simples, sem presumir que modelos maiores serão sempre mais eficientes.
Use prompt caching para reutilizar partes estáveis dos prompts e reduzir custos e latência.
Considere programmatic tool calling para processar resultados intermediários com código, em vez de enviá-los todos ao modelo.
Comece com um reasoning effort menor em tarefas rotineiras e valide a qualidade com evals.
Use batch ou flex quando a resposta puder esperar, aproveitando o custo menor do processamento assíncrono.
Mude uma configuração de cada vez e repita as evals conforme a aplicação evolui.

Capítulos

Início	Capítulo	Resumo
00:14	O custo por tarefa como métrica	Os palestrantes explicam por que o custo por token pode ocultar o custo real de concluir uma tarefa.
04:29	Como escolher o modelo adequado	A recomendação é definir a tarefa e a precisão esperada, testar modelos e configurações e comparar custo e qualidade.
08:47	Alavancas de otimização além do modelo	São apresentados prompt caching, programmatic tool calling, reasoning effort e processamento em lote ou flexível.
12:02	Exemplos e práticas para reduzir custos	Os palestrantes detalham o uso de programmatic tool calling, reasoning effort e batch para reduzir custos sem comprometer a qualidade.
16:25	Como melhorar o aproveitamento do cache	A conversa aborda prompts estáveis, breakpoints explícitos e ferramentas para monitorar e diagnosticar o cache.
21:12	Recomendações finais	A orientação é definir tarefas representativas, testar modelos e configurações e iterar com evals.

Citações

Um modelo barato por token pode não ser o mais barato por tarefa. — 01:18

A métrica que desenvolvedores e empresas devem observar é o custo por tarefa, não o custo por token. — 01:49

Mesmo uma resposta curta pode exigir muito esforço de raciocínio para ser gerada. — 13:08

Não se trata apenas de reduzir tokens, mas de obter um resultado bem-sucedido com custo menor e latência aceitável. — 14:45

Conceitos e entidades

cost per task (conceito): Métrica que considera o custo total para concluir uma tarefa, incluindo eventuais intervenções humanas.
Pareto frontier (conceito): Representação das configurações que equilibram precisão e custo sem que uma delas possa ser melhorada sem afetar a outra.
Luna (modelo): Modelo apresentado como uma opção eficiente para tarefas simples e para muitos workflows de clientes.
GPT-6 Astra (modelo): Modelo descrito na conversa como uma opção de alta inteligência, com controles para ajustar o reasoning effort e o cache.
prompt caching (conceito): Reutilização do processamento de partes repetidas de um prompt para reduzir custo e latência.
programmatic tool calling (conceito): Abordagem em que um programa coordena chamadas a ferramentas e processa resultados antes de enviá-los ao modelo.
OpenAI (empresa): Empresa cujas equipes e produtos são o foco da apresentação.
Perplexity (empresa): Cliente citado por resultados de precisão e custo em um benchmark de pesquisa.
Notion (empresa): Cliente citado por migrar para uma série mais recente de modelos e reduzir o custo por tarefa.
Clio (empresa): Cliente citado por reduzir tokens de prompt em análise documental com programmatic tool calling.

Tradução completa (pt-BR)

00:14 Olá, pessoal. Espero que estejam tendo um DevDay incrível até agora. No palco ao ar livre, vamos ter uma conversa em painel com duas pessoas da nossa equipe de engenharia de implantação de IA para falar sobre como otimizar os custos de IA. Vamos falar de coisas como: qual é o “porquê” certo, qual é a métrica certa para observar quando pensamos em otimizar custos? Como escolher o tamanho certo de um modelo para uma tarefa específica? Quais são as alavancas além do próprio modelo? E, ao longo da conversa, vamos recorrer a exemplos de clientes reais com quem a OpenAI

00:44 trabalha. Então, com isso, recebam no palco Mandeep e Sapto. Obrigado por estarem aqui. >> Obrigado pela introdução, Aarti. Agradeço. >> Obrigado. >> Claro. Vamos começar pelo principal erro que vemos os desenvolvedores cometerem, que é começar pela própria métrica. A maioria das pessoas pensa em custo e olha o preço de tabela dos tokens de entrada e saída no nosso site. Mas conte para nós, Mandeep, o que esses números deixam de fora? >> Sim. A propósito, uma breve apresentação: sou Mandeep e lidero a equipe de engenharia de IA aplicada

01:18 aqui em San Francisco. E sejam bem-vindos ao DevDay. Um modelo que é barato em custo por token pode não ser o mais barato em custo por tarefa. Há muitos motivos para isso. Dois motivos principais são: um modelo mais barato pode consumir mais tokens ou gerar mais tokens para concluir a tarefa. Ou o modelo pode nem concluir a tarefa, e uma pessoa precisa intervir para terminá-la. Portanto, a métrica que desenvolvedores e empresas

01:49 deveriam observar é o custo por tarefa, não o custo por token. >> Entendi. Então, custo por tarefa, não custo por token. Você pode dar alguns exemplos de como isso funciona na prática? >> Sim. Vou dar um exemplo bem pessoal. Na semana passada, precisei viajar para Nova York e pegar um voo. Quem aqui já ficou preso em um aeroporto por causa de um voo cancelado? Bem, acho que esse infortúnio já aconteceu com a maioria de nós em algum momento da vida. Consultei os voos online para fazer a troca, mas não consegui encontrar um que

02:23 realmente se encaixasse na minha programação. Precisei ligar para a companhia aérea e fui atendido por um chatbot de suporte ao cliente. Tenho um carinho especial por chatbots de suporte ao cliente, porque trabalhamos na criação deles. Então, expliquei com muita paciência ao chatbot de IA que queria remarcar meu voo. Não queria um voo noturno, mas não consegui fazê-lo entender. Então, literalmente, tive que dizer: “Preciso falar com uma pessoa.” Uma pessoa precisou intervir e concluir a transação, responder à minha pergunta e me reservar

02:55 um voo com conexão por Houston. Cheguei antes do encontro externo da minha equipe. Então, embora o modelo que a companhia aérea talvez estivesse usando fosse mais barato em custo por token, o custo para realmente concluir a tarefa foi o custo dos tokens mais o custo da pessoa que precisou intervir para concluir a tarefa. Portanto, a métrica que a companhia aérea deveria ter observado é o custo por tarefa, que também inclui o tempo que a pessoa precisou dedicar para concluí-la. >> Obrigado. Infelizmente, é um exemplo muito familiar

03:25 e espero que o restante de vocês tenha tido uma viagem mais tranquila até o DevDay. >> Sim, e vou citar alguns exemplos de clientes. A Perplexity, se vocês conhecem o produto, é uma cliente com quem trabalhamos muito de perto. No benchmark de pesquisa deles, relataram que 6 Astra produz resultados 9% mais precisos pela metade do custo. Então, embora seja um pouco [trecho incompleto] em comparação com o modelo anterior. Portanto, embora 6 Astra possa ser mais caro em custo por token, em termos de custo

03:56 por tarefa, na verdade é muito mais eficiente. Usa menos tokens e conclui a tarefa. Da mesma forma, a Notion, uma cliente com quem trabalhamos muito de perto — conheço o produto Notion, uso todos os dias — é muito boa em migrar para as séries mais recentes de modelos. Por exemplo, migraram de 5.5 para 5.6 e relataram melhor precisão e metade do custo por tarefa. >> Faz sentido. Você mencionou o custo por tarefa, ou seja, se a tarefa foi realmente concluída com sucesso. Mas a outra coisa que você destacou é a eficiência no uso de tokens. Continuamos investindo bastante para tornar nossos modelos não

04:29 só eficientes, mas também eficientes no uso de tokens, e isso tem um papel importante. Falando nisso, vamos começar pelo seguinte: falamos da métrica certa, que é o custo por tarefa. A maior decisão que você precisa tomar, é claro, é qual modelo escolher. Como você pensa em escolher o tamanho certo de um modelo para uma tarefa específica? >> Quando aconselhamos desenvolvedores e empresas sobre como escolher o tamanho certo do modelo, recomendamos que comecem definindo claramente a tarefa e a precisão, os objetivos de negócio ou o que o desenvolvedor espera dessa tarefa.

04:59 No exemplo da companhia aérea, poderia ser: queremos que o chatbot resolva 80% das consultas. Então, se tivessem usado, por exemplo, GPT live com 6 all como modelo delegado, talvez conseguissem resolver minha consulta sem encaminhá-la para uma pessoa. Portanto, comece definindo a tarefa e depois defina qual é a precisão que esperamos dela. O objetivo aqui é encontrar o harness do modelo e a configuração capazes de alcançar essa precisão com o melhor

05:35 custo possível. Aqui, vale a pena apresentar o conceito de curva de Pareto. Muitos de vocês talvez já tenham ouvido falar dela. Basicamente, é representar graficamente duas variáveis que dependem uma da outra e entre as quais é preciso encontrar um equilíbrio. Neste caso, as duas variáveis em que nos concentraríamos são precisão e custo. A ideia é experimentar modelos diferentes, configurações e ajustes diferentes, harnesses diferentes, descobrir qual é a precisão por tarefa com essas configurações e identificar

06:05 qual configuração de modelo e harness atende a esse limite de precisão com o melhor custo possível. >> Entendi. Você mencionou que há algumas tarefas em que talvez já se saiba de antemão qual modelo usar. Por exemplo, se for uma tarefa mais simples, talvez você queira que Luna faça o roteamento. Ou, se for um exemplo mais complexo, talvez queira que Astra cuide de boa parte do planejamento. Mas e se não estiver claro de antemão qual modelo usar em uma tarefa? >> Felizmente, aqui na OpenAI temos modelos que estão na fronteira de Pareto entre precisão e custo. Então,

06:39 começando com 6 Astra, nosso modelo de fronteira, que tem inteligência muito alta; 6.1 Soul oferece um nível muito alto de inteligência e é muito eficiente em custo por tarefa. E depois, Luna — e já ouvimos falar de Luna maxing. Então, voltando ao que você disse: se a tarefa for um tanto… Em muitas tarefas, você saberia intuitivamente qual modelo usar. Se for uma classificação simples ou a extração de alguns campos de um documento, saberia que Luna provavelmente… Então, nesses casos, eu

07:09 testaria um modelo menor e mais eficiente logo no início do processo. Se a tarefa exigir mais inteligência, começaria com 6 Astra e, ao testar modelos diferentes, traçaria essa fronteira de Pareto e descobriria qual é o ponto de corte em que o modelo e a configuração atingem o limite de desempenho com a melhor eficiência de custo por tarefa. >> Faz sentido. Então, começar com conjuntos de avaliação, tentar encontrar o modelo que atenda ao limite de precisão desejado e, depois, tentar otimizar os custos.

07:43 >> Sim, exatamente. >> Entendi. Você também mencionou Luna maxing. Quantas pessoas já ouviram esse termo? Certo, bastante gente. Mas a ideia principal é que Luna é, na verdade, um modelo bastante capaz e já se mostrou melhor do que muitos modelos, como modelos maiores de gerações anteriores. Mas, Mandeep, você poderia explicar rapidamente o que é Luna maxing? >> Sim. Muitos clientes ficam agradavelmente surpresos ao descobrir que Luna, com um esforço de raciocínio alto ou extra alto, pode superar muitos modelos maiores, especialmente os de gerações anteriores, ou

08:16 concorrentes. Muitos clientes oferecem o Luna como a principal opção para seus desenvolvedores programarem e só recorrem a outros modelos quando precisam de uma inteligência maior. Então, estamos aqui… ouvimos isso de muitos dos nossos clientes: o Luna funciona muito bem para 80% a 90% dos fluxos de trabalho deles. >> Então, não subestimem o Luna. Experimentem; ele pode fazer mais do que vocês imaginam. E hoje também anunciamos a Decisions API, também para tarefas mais simples, então a família está crescendo.

08:47 Então, falamos sobre a métrica certa que vocês devem otimizar: o custo por tarefa. Falamos sobre como encontrar a família de modelos ou o tamanho de modelo certo para a tarefa. Mas, é claro, essa é apenas uma das alavancas, certo? Encontrar o modelo certo. Então, Seth, você pode falar sobre o que há além do modelo? Que outras alavancas os desenvolvedores podem usar para otimizar os custos da aplicação? >> Sim, ótima pergunta, Aarti. Primeiro, eu gostaria de colocar desta forma, certo? A mesma família de modelos pode custar valores muito diferentes, dependendo da quantidade de informação que processamos, da quantidade

09:21 de informação que passamos para ele e do resultado que buscamos. Hoje, vou falar sobre quatro maneiras de controlar os custos e, ao mesmo tempo, manter a qualidade. Vamos falar de quatro alavancas. A primeira é o prompt caching; depois, temos programmatic tool calling. A terceira é o esforço de raciocínio, e a última é o processamento pela API em lote ou flex. Então, vamos falar sobre, ou nos aprofundar em, nossa primeira alavanca: o prompt caching. Um bom ponto de partida é identificar o texto repetido no seu prompt de entrada.

09:53 Então, vou dar um exemplo rápido. Suponha que você tenha um assistente de suporte de uma empresa, certo? E que ele use as mesmas políticas e documentos da empresa para atender cada cliente. O prompt caching funciona com base no conceito de reutilizar o pré-processamento dessas informações compartilhadas, enquanto o modelo continua processando qualquer informação nova no prompt e produz uma resposta nova a cada vez. Agora que falamos um pouco sobre prompt caching, quero me aprofundar na nossa segunda alavanca. Mas essa é muito importante, então vou

10:27 fazer uma pergunta rápida a todos vocês. Vou apresentar um exemplo ou cenário. Suponha que vocês tenham um sistema de pedidos online. E queiram que seu agent, que preenche ou processa muitos pedidos, descubra se há estoque suficiente para atendê-los. Como isso vai funcionar? O agent pode chamar várias ferramentas, processar os pedidos, descobrir o que está faltando e o que está chegando e, depois, enviar todos os resultados de volta ao LLM, que é o mecanismo de raciocínio.

10:57 Uma pergunta rápida para todos vocês: acham mesmo que o modelo precisa ler e comparar todos esses resultados por conta própria? O que vocês acham? >> E também, chegue ao microfone. Desculpe. >> Ah. Sim, o que vocês acham? O modelo realmente precisa ler e comparar todos esses resultados por conta própria? >> Estou vendo algumas pessoas balançando a cabeça. >> Certo. Certo, provavelmente não. E esse é o conceito principal por trás da nossa segunda alavanca: o programmatic tool calling.

11:29 O programmatic tool calling é útil em alguns cenários. Vocês podem enviar todos os resultados das ferramentas de volta ao modelo para que ele julgue, mas, em outros cenários, não é necessário fazer isso. Os resultados podem ser calibrados, combinados e também comparados. O programmatic tool calling é um conceito em que o modelo executa um pequeno programa, e esse programa coordena as chamadas às ferramentas, processa os resultados e compartilha um relatório consolidado com o modelo para que ele faça o

12:02 julgamento. Com o programmatic tool calling, vocês evitam precisar enviar cada dado intermediário de volta ao modelo e também reduzem o número de chamadas ao modelo feitas pelo workflow em cada etapa possível. Agora, vou dar um exemplo rápido. É um caso de um cliente, só para mostrar a todos vocês o impacto real do uso do programmatic tool calling. Um dos nossos clientes é a Clio. É uma empresa de IA jurídica que fornece sistemas de software de gestão na nuvem para escritórios de advocacia.

12:35 Eles relataram que, na análise de documentos em várias etapas, conseguiram reduzir em 38% os prompt tokens usando programmatic tool calling, sem perda de qualidade. É muito importante lembrar disso: 38% menos prompt tokens, apenas mudando a forma como a aplicação interage com o modelo. Agora que falamos da segunda alavanca, o programmatic tool calling, vamos à terceira, que é o esforço de raciocínio. Acho que muitos de vocês talvez já conheçam, mas pensem no esforço de raciocínio como uma configuração a ser testada.

13:08 O esforço de raciocínio — nossa principal recomendação é que ele é bem diferente do tamanho da resposta. Até mesmo uma resposta curta pode exigir muito esforço de raciocínio para ser gerada. Mas uma das principais orientações que temos para vocês é começar sempre com um nível mais baixo de esforço de raciocínio para qualquer tarefa rotineira. Depois, executem seus evals para ver se a qualidade se mantém. Para tarefas difíceis ou diferenciadas, vale a pena pagar pelos tokens extras. Mas o mais importante a ter em mente é que é muito importante

13:40 executar seus evals iterativamente para ajudar vocês a tomar uma decisão bem fundamentada. Falamos dessas três alavancas. Vamos falar da última: o processamento pela API em lote ou flex. Isso nos leva à pergunta: quanto tempo vocês estão dispostos a esperar? Suponham que estejam processando milhares de documentos e possam esperar um pouco. Temos as APIs em lote da OpenAI, que oferecem uma janela de processamento de 24 horas com preços por token 50% menores que os das solicitações síncronas padrão.

14:14 Isso é ideal para workflows em que vocês não precisam de uma resposta imediata do modelo. Agora que falamos dessas quatro alavancas, quero deixar uma ideia rápida para vocês: sempre que estiverem desenvolvendo aplicações de IA e se perguntarem: “Que família de modelos devo usar?”, façam também uma pergunta adicional: quanto trabalho vou pedir para o modelo fazer? Nossa recomendação para vocês é

14:45 acompanhar uma tarefa completa dentro da aplicação. Vejam o que entrou e como ficou o resultado. Observem se há workflows repetitivos ou, como posso dizer, chamadas a ferramentas, e também quantas chamadas foram feitas. Pensem nisso e vejam o que melhora os resultados. Mudem uma configuração e, depois, iterem. Executem seus evals conforme a aplicação e os modelos evoluem. E outra coisa importante

15:18 a ter em mente é que não se trata apenas de reduzir os tokens ou simplesmente usar menos tokens. Trata-se de alcançar um resultado bem-sucedido, reduzindo os custos e mantendo uma latência aceitável. >> Faz sentido. Obrigado, Sapthau. Foram muitas alavancas diferentes, então vou fazer um resumo rápido para o público e vamos nos aprofundar um pouco mais. Primeiro, falamos sobre prompt caching. Isso acaba sendo muito, muito importante. Basta olhar nossa lista de preços: vocês verão o custo dos tokens de entrada e de saída, e os inputs em cache podem custar até 90% menos. Então, o prompt caching pode ter um impacto de até 90% no

15:53 custo que vocês pagam. Vamos falar um pouco mais sobre isso. A segunda coisa que mencionamos é que, é claro, vocês querem reduzir a quantidade de tokens de entrada que fornecem ao modelo. Em vez de simplesmente despejar um monte de informações, vocês podem usar programmatic tool calling para transferir parte do processamento de dados ou do contexto para o código e mantê-la fora da context window do modelo, o que reduz diretamente o custo. Falamos sobre o esforço de raciocínio. Muitos de vocês conhecem o controle deslizante que temos no Codex. Na nossa API, também é possível alterar o esforço de raciocínio. E, na verdade, agora, na API, vocês podem alterar

16:25 o esforço de raciocínio sem invalidar o cache. Isso foi enorme. Acho que lançamos esse recurso com Astra há algumas semanas. E, por último, batch ou flex: se uma solicitação não for urgente e você puder adiá-la, paga menos por esse tipo de solicitação. Dada a importância do prompt caching, acho que vale a pena nos aprofundarmos. Então, Sapthau, você pode falar sobre os erros comuns que vê os desenvolvedores cometerem ao otimizar a taxa de acerto do prompt cache e sobre alguma recomendação que possa ter? >> Sim. Esse é um tópico muito interessante

16:56 e estou muito animado para falar sobre ele com vocês. Mas, antes disso, quero fazer uma pergunta rápida novamente. Quantos de vocês estão usando prompt caching atualmente? Certo. >> Todos nós. Ele vem ativado por padrão. >> Sim. Estou muito animado em ver tantas mãos levantadas aqui. Obrigado, Mandeep. Mas, como Mandeep mencionou, ele vem ativado por padrão. Converso com muitos dos nossos clientes sobre prompt caching, mas também estamos vendo que muitos não estão aproveitando esse recurso ao máximo

17:28 possível. Nossa principal orientação sobre prompt caching é manter consistente o início do prompt sempre que possível. Assim, o prompt caching pode reutilizar o pré-processamento dessa instrução compartilhada, enquanto qualquer informação mais recente no seu prompt — que não esteja nessa parte correspondente — pode ser processada novamente pelo modelo, que produzirá uma resposta mais atualizada a cada vez. Quando essa técnica é combinada

17:58 com nossas famílias de modelos mais recentes, ela reduz significativamente o custo e a latência para nossos clientes. Vou dar um exemplo rápido de um cenário de cliente para mostrar como você pode melhorar a reutilização do cache com prompt caching. Um dos nossos clientes é a Blitz C. A Blitz C é uma empresa de desenvolvimento de software com tecnologia de IA, e eles relataram que, ao passar de uma chamada de saída estruturada única para o loop de tool calling da Luna, conseguiram aumentar a reutilização do cache de 24% para 90%. E, em milhares de chamadas em produção, eles

18:31 também relataram 8,5 vezes menos tokens de prompt de saída e um custo 87% menor em comparação com GPT 5.4 mini, além de lidar com 2,2 vezes mais contexto. >> Ah, certo. Então, você pode manter o prompt consistente, por assim dizer, mas e se os seus prompts mudarem frequentemente entre consultas diferentes? >> Sim, ótima pergunta. Como estamos dizendo, nas nossas famílias de modelos anteriores, o cache automático vinha ativado por padrão. O sistema conseguia

19:01 escolher pontos de quebra com base em intervalos de tokens. Conseguíamos manter consistente o início do prompt, mas não havia opção para escolher nossos próprios limites. Isso mudou completamente com as famílias GPT 5.6 Astra e GPT 5.6, nas quais temos a opção de adicionar pontos de quebra explícitos. Em termos simples, pense nos pontos de quebra explícitos como uma forma de dizer: quero armazenar em cache até este ponto. Certo? Com um ponto de quebra explícito, você pode, por exemplo,

19:33 ter as mesmas instruções de programação de longa duração e tarefas que mudam a cada vez no final. Com pontos de quebra explícitos, você pode inserir pontos de quebra logo depois da parte estável e antes da tarefa que muda constantemente. Assim, você reutiliza a parte estável das informações, enquanto o modelo ainda processa a tarefa que continua mudando. Se quiser mais controle, temos outra opção: o modo somente explícito. Com esse modo, você pode escolher exatamente qual parte ou caminho quer armazenar em cache. Isso é ideal porque você

20:06 não quer armazenar em cache conteúdo desnecessário que muda com frequência e não será reutilizado depois. Como Aarti mencionou, com GPT-6 Astra, mantemos todos os controles e recursos que você tinha nas famílias GPT 5.6, mas acrescentamos mais um recurso. Com GPT-6 Astra, agora você pode alterar o esforço de raciocínio durante uma conversa em andamento sem invalidar o cache. >> Obrigado, Sapta. Isso me lembrou de outra coisa que já tínhamos e que talvez as pessoas não conheçam: você também pode alterar as ferramentas fornecidas ao modelo sem invalidar o

20:40 cache, adicionando-as a allowed tools ou a outros parâmetros. Estamos oferecendo bastante flexibilidade para alterar o esforço de raciocínio e as ferramentas, mantendo a taxa de acerto do cache. Continuamos investindo muito nessa área. Mais duas coisas para destacar: lançamos um painel de prompt caching na nossa página web de administração, para que você possa ver, medir e acompanhar a taxa de acerto do cache nas suas aplicações. Também lançamos uma API de diagnóstico. Com duas consultas diferentes, podemos identificar onde ocorre a falha do cache, para que você possa

21:12 começar a otimizá-lo. Mas, reforçando, isso é muito importante e é uma alavanca realmente importante para otimizar custos. Ótimo. Cobrimos bastante coisa. Falamos sobre a métrica certa: observe o custo para concluir a tarefa, não apenas o preço de tabela. Falamos sobre como encontrar o modelo certo para a tarefa. E, mais uma vez, temos orgulho de dizer que nossos modelos estão na fronteira de Pareto em termos de custo e precisão. Falamos sobre as várias alavancas: prompt caching, tool calling programático, esforço de raciocínio e, por fim, batch e flex.

21:45 Então, com tudo isso, Mandeep e Sapto, que mensagem vocês gostariam de deixar para o público? O que eles devem fazer quando voltarem para casa? >> Sim. O primeiro passo é definir a tarefa que você quer que o modelo consiga realizar. Identifique o limite de precisão que a empresa espera ou que você espera para o caso de uso. Segundo, defina um conjunto representativo de tarefas que descreva como a aplicação será usada. Use… experimente modelos diferentes, as configurações diferentes que Sapto mencionou, diferentes níveis de esforço de raciocínio,

22:17 prompts diferentes para ver como funciona o prompt caching. Trace a fronteira de Pareto e encontre a configuração do modelo e o harness que funcionam melhor para a tarefa no limite de precisão esperado pela empresa. >> Sim. E, da minha parte, teste uma mudança, uma melhoria por vez. Quando encontrar uma melhoria, mantenha essa configuração e continue iterando; execute seus evals à medida que sua aplicação e seu modelo evoluem. >> Excelente. Obrigado a todos. Vocês podem nos procurar ao longo do dia se tiverem alguma dúvida.

22:49 >> Obrigado. >> Obrigado. >> [música]

Transcrição original

[00:14] Hello everyone. Hope you’re having an amazing DevDay so far. Uh on the outdoor stage now, we’re going to have a panel side discussion with two people from our AI deployment engineering team to talk about how to optimize AI costs. So, we’re going to talk about things like, you know, what is the right Why what is the right metric to look at even when you think of optimizing costs? How do you right-size a model for a particular task? Levers beyond the model itself. And throughout we’ll be drawing on uh examples from real customers that OpenAI

[00:44] works with. So, with that, please welcome to the stage Mandeep and Sapto. Thank you for being here. >> Thanks for the introduction, Aarti. Appreciate >> Thank you. >> Of course. Uh so, let’s start with the number one mistakes that we see developers make, which is starting with even the metric. You know, most people think of cost and look at the list price of the input and the output tokens on our website. But talk to us, Mandeep, about what do those numbers miss? >> Yeah. Uh by the way, quick introduction. Mandeep, I lead the applied AI

[01:18] engineering team based out of here San Francisco. And welcome to the DevDay. A model that is cheap on cost per token basis may not be the cheapest model on cost per task basis. And there are many reasons for this. Two main reasons are a cheaper model may consume more tokens or produce more tokens to complete the task. Or the model may not complete the task at all, and a human has to intervene to complete the task. So, the metric that developers and businesses

[01:49] should be looking at is cost per task, not cost per token. >> Got it. So, cost per task, not cost per token. Can you give us a few examples of what this looks like in practice? >> Yes, so I’ll give a very personal example. Last week I had to travel to New York City, had to take a flight. Who here has been stranded on an airport with a canceled flight? And well, I I guess that misfortune has happened to most of us at one point in our life. And I look at the flights online, change, but couldn’t find the flight that

[02:23] actually matches the schedule. I had to call the airline and I’m greeted by a customer support chatbot. Now, I have a soft spot for customer support chatbots because we’re in business of building customer support chatbots. So, I very patiently explained to the AI chatbot that I wanted to reschedule my flight. I did not want a red eye, but I could not make it understand. So, I literally had to say, “I need to speak with a human.” So, a human had to intervene and complete the transaction, answer my query, book me in

[02:55] a flight through Houston, and I arrived before my team offsite. So, while the model that the airline may have been using may have been cheaper on cost per token basis, but the cost to actually complete the task was the cost of the tokens plus the human that had to intervene to actually complete the task. So, the metric that airline should have been looking at is the cost per task, which includes the human the the time that human had to spend to complete the task as well. >> Thanks. Unfortunately, a very relatable

[03:25] example, and I hope the rest of you had a smoother journey here to DevDay. >> Yeah, and I’ll I’ll quote a couple of customer examples. So, Perplexity, if you’re familiar with the product, a customer we work very closely with. On their research benchmark, they reported 6 Astra produces 9% more accurate results at half the cost. So, while a bit compared with the previous model. So, while 6 Astra may be more expensive on token per cost basis, but on a cost

[03:56] per task basis it’s actually much more efficient. It uses fewer tokens and gets the task done. Likewise, Notion, a customer we work very closely with, we’re familiar with the Notion product, I use it every day. They are very good at using the migrating to the latest series of models. For example, they migrated from 5.5 to 5.6 all reported better accuracy, half the cost per task. >> Makes sense. You’ve mentioned, you know, cost per task so is the task really done successfully? But then the other thing you called out is token efficiency. We continue to invest a lot in making not

[04:29] just our models performant, but also token efficient and that really plays in. Speaking of, uh, let’s start with, you know, we we’ve talked about the right metric here, which is cost per task. The biggest decision you’ve to make, of course, is which model to pick. So how do you think through right-sizing a model for a particular task? >> Yeah, so when we advise developer on businesses on right-sizing the model, we recommend begin with crisply defining the task and what accuracy, business, or

[04:59] a developer expects from that task. So from the airline example, it could have been we want 80% of inquiries to be resolved by the chatbot. So if they had used, for example, GPT live with 6 all as a delegate model, they might have been able to resolve my inquiry without delegating it to a human. So begin with define the task and then define what is the accuracy we expect from the task. Um, so the goal here is to find the model harness and the configuration that can achieve that accuracy at at the best

[05:35] cost possible. Here it’ll be good to introduce a concept Pareto curve. Many of you may have heard of it. It’s essentially plotting two variables that are dependent on each other and you have to optimize for one or the other. In this case, the two variables that we would focus on is accuracy and cost. The idea here is try different models, try different settings, different configurations, different harnesses, figure out what is the accuracy per task with those configurations, and figure

[06:05] out which model configuration and harness meets that accuracy threshold with the best cost possible. >> Got it. So, you touched on, you know, there are some tasks where you might know up front what model to use. Like, let’s say if it is a simple simpler task, you might want Luna to, let’s say, route. Or, um if it’s a more complex example, you might want Astra to handle a lot of the planning. But, what if it is not clear up front what model to use for a task? >> Yes. So, well, luckily here at OpenAI, we have models that are at the Pareto frontier for accuracy and cost. So,

[06:39] starting with 6 Astra, which is our frontier model, very high intelligence, 6.1 Soul, provides a very high level of intelligence, very cost efficient per task. And then, Luna, and we’ve heard Luna maxing. Um so, to your point, if the task is somewhat Many tasks you would intuitively know which model to use. If it is simple classification, or it is extracting a few fields out of a document, you would know that Luna is probably So, I would in those cases, I

[07:09] would test a smaller, more efficient model early on in the process. If the task is more requires more intelligence, I would begin with 6 Astra, and then, as I test different models, I would plot that Pareto frontier, and figure out what is that cutoff where the model and the configuration meets the performance threshold with the best cost efficiency per task. >> Makes sense. So, start with evaluation sets, try to find the model that meets the accuracy threshold that you want, and then try to optimize for costs.

[07:43] >> Yes, exactly. >> Got it. You also mentioned Luna maxing. How many people have heard of that term? Okay, quite a few people, but the overall takeaway there is Luna’s actually quite capable model, and it’s found to beat a lot of models like larger models from previous generations. But yeah, Mandeep, do you want to quickly tell us about what Luna maxing is? >> Yeah, so a lot of customers are pleasantly surprised that Luna with a high or extra high reasoning effort can actually beat many bigger models, especially from previous generation or

[08:16] competitors. To a lot of customers offer Luna as the primary way for their developers to code, and only default to other models when a higher intelligence is needed. So we’re here that we hear that a lot from our customers that Luna for 80-90% of their workflows, it it works really well for our customers. >> So don’t discount Luna, and give it a shot, it might do more than you think it can do. And today we also announced Decisions API, also for simpler tasks, so the family grows.

[08:47] So we’ve talked about the right metric, cost per task, that you want to optimize for. We’ve talked about how do you find the right model family or the model size for the task. But that’s of course just one lever, right? Finding the right model. So Seth though, can you talk to us about beyond the model, what are other levers developers can use to optimize costs for their application? >> Yeah, great question, Aarti. Firstly, I would like to tell like this, right? Same model family can cost very different amounts based on the amount of information we process, amount

[09:21] of information we pass it through, and what the output that we are seeking from it. Now, today I’m going to talk about four ways which where you can control cost while also kind of maintaining the quality. So we are going to talk about four levers here. The first one is prompt caching, then we have programmatic tool calling. Third one is reasoning effort, and the last one is batch of flex API processing. So, let’s talk about or dive deeper into our first lever, that is prompt caching. So, a good starting point is to take the repeated text within your input prompt.

[09:53] So, uh, let me give a quick example here. So, suppose you have a company support assistant, right? And it uses uh, com- same company policies and documents to process every customer. Now, prompt caching like works on the concept where it can reuse the pre-processing of those shared information, while your model still processes any kind of new information in the prompt and produces a fresh response each and every time. So, now that we talked about prompt caching a little bit, I want to go deeper into our second lever. But, after this is a very important one, so I’m

[10:27] going to ask all of you a quick question here. So, I’m going to give you a quick example or a scenario. Suppose you have an online ordering system. And you want your agent, which kind of fills or processes a lot of orders, and you want your agent to find, you know, if there’s F stock available to fill those orders. Now, how is going to work? You know, the agent can call multiple tools, process the orders, find what’s missing, what’s arriving, and then pushes all the results back to your LLM, which is the reasoning engine.

[10:57] Quick question to all of you. Do you really think your model needs to read and compare all of those results by itself? What do you all think? >> Also, step up to the mic, sorry. >> Oh. Yeah, what do you all think? Like, does your model really need to read and compare all of those results by itself? >> I’m seeing some shakes. >> Okay. Okay, probably not. Uh, and that’s that’s the that’s the main concept behind our second lever, that is uh, programmatic tool calling.

[11:29] So, programmatic tool calling uh, is like for some scenarios, your model you can pass all of those tool results back to your model for judgment, but for some for some scenarios, there is no need for you to pass those tool results back to your model. It can be calibrated, combined, and then compared as well. So, programmatic tool calling is a concept where your model runs runs a small program, and that small program kind of coordinates the tool calls and processes the results and and and shares the package report back to your model for

[12:02] judgment. With programmatic tool calling, the thing that you’re avoiding here is there is no need for you to send every piece of intermediary data back to your model, and you’re also reducing the number of model calls that your workflow is making at every possible step. Now, let me give a quick example. This is a customer scenario just to show all of you the real-world impact of using programmatic tool calling. So, we have one of our customers, Clio. So, it’s a legal AI-powered company which provides cloud management software systems to law firms.

[12:35] They reported in their multi-step document analysis that they were able to achieve 38% fewer prompt tokens by using programmatic tool calling with no loss of quality. So, this is very important thing to remember. That’s 38% fewer prompt tokens just by changing how the application interacts with the model. So, now that we talked about our second lever, programmatic tool calling, the third lever, which is the reasoning effort, I think all of you might might already be aware of it, but think of reasoning effort as a setting to test.

[13:08] The reasoning effort, like our main recommendation that reasoning effort is very different from the answer length. Like even like a short answer can require a lot of reasoning effort to generate it. But one of our major guidance for all of you here is whenever for any kind of routine task, always start with a lower reasoning effort level. And then run your evals to see whether the quality holds or not. Now, for any kind of difficult or differentiated task, the extra tokens is worth paying for. But the most important thing to keep in mind is it’s very important to

[13:40] run your evals iteratively to under to help you make that informed decision. So, we talked about these three levers. Let Let’s talk about our last one. That is batch or flex API processing. Now, this comes to the question. Like, how much are you willing to wait? So, suppose you’re processing, you know, thousands of documents, and you have the capacity to wait a little bit. We have OpenAI batch APIs, which provides a 24-hour processing window at a 50% lower token pricing compared to standard synchronous requests.

[14:14] Now, this is ideal for workflow where um where you do not need an immediate response back from the model. So, now that we’ve talked about these four levers, um I want to like give a quick uh thought to all of you guys here is whenever you’re building your AI applications, and you have this question in your mind, like, “Hey, like, which model family should I use?” You should also ask an additional question, that how much work am I going to make the model do? Our recommendation for all of you is

[14:45] follow through one complete task within your application. See what went in, you know, what the output looks like. You know, if there are any kind of repetitive workflows, or uh if there are any kind of, you know, what you can say, like some there are tool calls, the number of tool calls that has been made here as well. Now, think of it, see what improves the results. Change one setting, and then iterate, run your evals as your application and models kind of evolves from there. And another thing another important

[15:18] thing to keep in mind is it’s not about lowering tokens or having simply like fewer tokens. It’s about having a successful outcome through lowering cost and acceptable latency. >> Makes sense. Thank you, Sapthau. That was a lot of different levers, so let me quickly summarize that for the audience and we’ll dive a little deeper. First, we talked about prompt caching. This ends up being really, really important. If you even look at our price list, you’ll see cost of input and output tokens and there’s up to 90% fewer cost for cached inputs. So, prompt caching ends up having up to 90% impact in terms

[15:53] of the cost that you pay. So, we’ll talk about it a little more. The second one we talked about is, of course, you want to reduce the amount of input tokens you give the model. Instead of just dumping in a lot of information, you can use programmatic tool calling to offload some of that processing of data or context to code and keep that out of the model’s context window, which directly lowers the cost. We talked about reasoning effort. A lot of you are familiar with the slider that we have on Codex. Uh on our API, too, you can change the reasoning effort. And actually now, in the API, you can change

[16:25] the reasoning effort without breaking the cache. Uh which was massive. I think we released it with Astra a few weeks ago. And then lastly, batch or flex, which is if a request is not urgent and you can delay it, you get to pay less uh for those types of requests. Just given how important prompt caching is, I think it’s worth going deeper. So, Sapthau, can you talk to us about, you know, what are the common mistakes you see developers make in terms of optimizing their prompt cache hit rate and any recommendation you might have? >> Yes. Uh so, that’s a very interesting

[16:56] topic and I’m really excited to talk to you about here. Uh but before we do that, I want to ask a quick question again. Um how many of you are currently using prompt caching? Okay. >> It’s all of us. It’s enabled by default. >> Yeah. So, as like and I I’m quite excited to see like a lot of raised hands here. Thanks, Mandeep. Um but as Mandeep mentioned, like it’s like enabled by default, and we talk I’ll talk to a lot of our customers about prompt caching, but we are also seeing that a lot of customers are not utilizing it to the fullest extent as

[17:28] possible. Now, our number one guidance with prompt caching is to keep the beginning of your prompt consistent whenever possible. In that way, prompt caching can reuse the preprocessing of that shared instruction, while any kind of newer information in in your prompt, like with this which is not in that matching portion, can be can be freshly processed by your model, and your model produces a fresher response each and every time. Now, when this technique is combined

[17:58] with our newer model families, it significantly reduces cost and latency for our customers. Let me give a quick example of customer scenario here to show you how you can improve your cache reuse with prompt caching. So, we have one of our customers, Blitz C. Blitz C is like an AI-powered software development company, and they reported that by moving from single structured output call to Luna’s tool calling loop, they were able to improve their cache reuse from 24% to 90%. And across their thousands of production calls, they were

[18:31] also they were also reported 8.5x fewer output prompt tokens and 87% cheaper cost compared to GPT 5.4 mini, while also handling 2.2x more context. >> Oh, okay. So, you can keep the prompt consistent as it were, but what if your prompts change frequently across different queries? >> Yeah, great question. So, as as we as we are saying, like for our earlier model families, automatic caching was enabled by default. We didn’t had like the system was able

[19:01] to choose break points based on token intervals. We were able to keep the beginning of the prompt consistent, but we we weren’t there there weren’t any option for us to choose our own boundaries. Now, that has completely changed with GPT 5.6 Astra GPT 5.6 families where you have where we have the option to add explicit breakpoints. So, if I want to put it in simple words, think of explicit breakpoints as like I want to cache until this point. Right? With explicit breakpoint, what you can do is let if I if I give you a quick example,

[19:33] you have the same long-running coding instructions and you have tasks that keep on changing every time at the end. With explicit breakpoints, you can actually put breakpoints right after the stable piece and before the task that actually keeps on changing. In that way, you are actually reusing the stable piece of information while the model still processes the task that keeps on changing. Now, if you want more control, we have another option that is explicit only mode. With explicit only mode, you can pick and choose which specific portion or path that you want to cache. And this is very ideal because you do

[20:06] not want to cache unnecessary content which changes frequently and it won’t be reused later. Now, as Aarti mentioned, like with GPT-6 Astra, we keep all of the controls or all of the capabilities that you had with GPT 5.6 families, but with the one added capability here. With GPT-6 Astra, you now have the power to change your reasoning effort within an ongoing conversation without breaking the cache. >> Thank you, Sapta. That just reminded me the other thing we already had that people not might not be aware of is you can already change the tools that you give to the model without breaking the

[20:40] cache as well by adding them in allowed tools or other parameters. So, we’re adding just a lot of flexibility in terms of changing the reasoning effort and the tools while maintaining the cache rate. Uh again, we continue to invest so much in this area. Two other things to flag, we shipped a prompt caching like dashboard on our admin web page so that you can actually see, measure, and track your cache hit rate across your applications. The other thing we released is a diagnostics API. So, given two different queries, um we can actually tell you where the cache miss is happening so that you can

[21:12] start to optimize it. But again, reinforcing again how important that is and and really a important lever for cost optimization. Great. So, we’ve covered a lot. Uh we’ve talked about the right metric. Look at cost for completing the task, not just the list price. We talked about how do you find the right model for the task? And again, we’re very proud to say we have models at the Pareto frontier um in in terms of cost and accuracy. We talked about the various levers, prompt caching, programmatic tool calling, reasoning effort, and then batch reflex.

[21:45] So, with all of that now, Mandeep and Sapto, what would you like to leave the audience with? Like what should they go home and do? >> Yeah. So, the first starting point is define the task that you want the model to be able to do. Identify the accuracy threshold that business expects or you expect from the use case. Second, define a representative set of tasks that define how the application is going to be used. Use Try different models, different settings that Sapto mentioned, different reasoning effort,

[22:17] different prompts to see prompt caching, how that works. Plot the Pareto frontier and find the model configuration and hardness that works best for the task at the accuracy threshold that the business expects. >> Yeah. And and from my side is test one change, one improvement. And when you find that improvement, keep that setting and iterate, run your evals um as your application and model evolves. >> Amazing. Thank you all and you can come find us throughout the day if you have any questions.

[22:49] >> Thank you. >> Thank you. >> [music]