Reasoning-Effort Routing i en AI API Gateway: kontrollera tanketokens, latens och kostnader mellan leverantörer

Resonera djup är inte längre ett enkelt modellalternativ. Vissa leverantörer avslöjar ansträngningsnivåer i enum-stil. Andra avslöjar symboliska budgetar, dynamiskt tänkande eller modellfamiljer där tänkande inte helt kan inaktiveras. Det synliga svaret kan vara kort medan dolda resonemang förbrukar fakturerbara utdatatokens. Om varje applikationsteam ställer in dessa kontroller direkt, blir kostnad, latens och kvalitet svåra att förklara.

Det praktiska svaret är att flytta resonemangskontroll till API-gatewayen. Gatewayen bör klassificera arbetsbelastningen, mappa den till en leverantörsspecifik resonemangskontroll, genomdriva hyresgästbudgetar, registrera faktisk resonemangsanvändning och göra nedgraderingsbeslut synliga i analyser. Modell-ID, tjänstenivå, maximalt resultat och resonemangsdjup bör vara separata policydimensioner.

Läsarproblem: Enkla förfrågningar betalar för djupa resonemang

Team som använder resonemangskapabla modeller börjar vanligtvis med ett rimligt mål: förbättra kvaliteten på svåra uppgifter. Problemet dyker upp senare, när samma standardinställningar återanvänds för extraktion, korta sammanfattningar, formatering och klassificering. Dessa förfrågningar behöver inte dyrbara testtidsberäkningar, men de kan fortfarande trigga den.

Detta skapar tre driftsfel:

• Kostnadsopacitet: användaren ser ett kort svar, men reskontran innehåller dolda resonemangstokens eller leverantörsspecifika motsvarigheter.
• Latensmodellen blir långsammare, eftersom det ser ut som ett långsamt arbetsflöde bakom samma modell: alias.
• Policyfragmentering: varje produktteam lär sig olika leverantörsparametrar och tillämpar olika tak.

En resonemangspolicy på gatewaynivå löser kontrollproblemet innan det blir ett faktureringsproblem.

Fakta: Leverantörens resonemangskontroller är inte likvärdiga,Följande är inte genomförandet

rekommendationer.

• API:er med OpenAI-resonemang avslöjar ett reasoning-objekt för modeller som stöds, inklusive ansträngningsvärden som none, minimal, low, medium, high och .xhigh Lägre ansträngning kan minska resonemangstokens och förbättra svarshastigheten.
• OpenAI-dokumentationen anger att max_output_tokens kan begränsa det totala antalet genererade tokens, inklusive både resonemang och slutliga utdatatokens.
• Antropiskt utökat tänkande kan aktiveras med ett budget_tokens-värde. Thinking tokens faktureras som output tokens och räknas mot max_tokens bredvid synlig svarstext.
• Antropisk dokumentation noterar också att fakturerad output token count kanske inte matchar antalet synliga respons tokens, eftersom interna tanketokens kan faktureras även när de inte är helt synliga.
• Gemini thinking output tokens tokens that can include thinking output tokens tokens. med användningsfält som separerar tanketokens och utdatatokens.
• Gemini 2.5-kontroller inkluderar thinkingBudget, med dynamiskt tänkande på modeller som stöds och nollbudget inaktiverat på vissa modellfamiljer. Vissa modeller kan inte inaktivera tänkandet.
• Nyere Gemini-vägledning rekommenderar thinking_level-värden som minimal, låg, medium och hög för modeller i Gemini 3.x-stil istället för obearbetade numeriska/kärnbudgetar: >
• Den obearbetade numeriska budgeten gör inte:
. avslöja leverantörsbaserade resonemangskontroller som det enda kontraktet. De är inte tillräckligt stabila, tillräckligt portabla eller jämförbara för styrning av flera leverantörer.

Rekommendation: Skapa leverantörsneutrala resonemangsprofiler

Definiera en liten intern vokabulär som produktteam kan förstå utan att läsa varje leverantörs API-referens.För de flesta gateways räcker det med fem profiler:

djupa insatser för uppgifter och analys

Intern profil	Syfte	Typisk användning	Policyhållning
ingen	Inaktivera	Inaktivera	Stöds	Inaktivera	Inaktivera	Inaktivera extraktion, taggning, routing	Standard för enkla slutpunkter med stora volymer
låg	Lätt resonemang för blygsam tvetydighet	Korta supportsvar, enkla jämförelser, omskrivningsuppgifter	i stort sett
standard	Balanserade resonemang för rutinmässigt kunskapsarbete	Planering, kodgranskning, policyanalys, längre syntes	Standard för blandade arbetsbelastningar
djupa insatser	Felsökning, matematik, säkerhetsgranskning, agentplanering	Begränsad av hyresgäst, nyckel, arbetsflöde och budget
capped-deep	Högt resonemang med ett hårt tak	Premiumkostnader	Premiumkostnadsuppdrag är oacceptabla

Profilen är det ansökningsorienterade kontraktet. Leverantörsparametrar blir adapterdetaljer. Detta håller klientkoden portabel och låter plattformsägare uppdatera mappningar när leverantörens API:er ändras.

Karta arbetsbelastningsklasser före mappningsleverantörer

Resonemang bör väljas utifrån arbetsbelastningens avsikt, inte utifrån personliga preferenser eller modellpopularitet. Lägg till ett gatewayfält såsom workload_class, antingen tillhandahållet av klienten eller härledd från en godkänd ruttkonfiguration.

Exempel Workload Policy

{
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "ingen",
      "max_reasoning_profile": "låg",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "ingen",
      "max_reasoning_profile": "låg",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "låg",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "djup",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "djup",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "djup",
      "max_output_tokens": 5000
    }
  }
}

Den här policyn gör två användbara saker. För det första förhindrar det att enkla slutpunkter ärver kostsamma standardinställningar. För det andra ger det administratörer en konkret granskningsyta: vilka arbetsflöden får begära djupgående resonemang, och under vilka tak?

Bygg en kompatibilitetsmatris

Gatewayadaptern bör ha en matris för varje leverantör och modellfamilj. Lagra åtminstone om modellen stöder inaktivering av resonemang, enuminsats, numerisk budget, dynamiskt tänkande, maximalt stödd budget och användningsfält för resonemangstokens.

Exempel Matrix Shape

{
  "leverantörer": {
    "provider_a": {
      "model_family_x": {
        "supports_reasoning": sant,
        "control_type": "effort_enum",
        "allowed_values": ["ingen", "minimal", "låg", "medium", "hög", "xhög"],
        "can_disable": sant,
        "reports_reasoning_tokens": sant
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": sant,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": false,
        "reports_reasoning_tokens": sant
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": sant,
        "control_type": "tänkenivå",
        "allowed_values": ["minimal", "låg", "medium", "hög"],
        "can_disable": false,
        "reports_reasoning_tokens": sant
      }
    }
  }
}

En kompatibilitetsmatris är inte dokumentation endast för människor. Det bör vara en körbar policy. Förfrågningsroutern bör använda den före avsändning, och faktureringsreskontran bör använda den under avräkning.

Översätt interna profiler till leverantörsparametrar

Providermappningar bör vara tydliga och versionsförda. Lita inte på en vag fras som "använd smartare resonemang." Gatewayen bör veta exakt vilken leverantörsparameter som skickades.

Exempelmappning

{
  "reasoning_profile_mappings": {
    "ingen": {
      "effort_enum": "ingen",
      "budget_tokens": 0,
      "thinking_level": "minimal"
    },
    "låg": {
      "effort_enum": "låg",
      "budget_tokens": 2048,
      "thinking_level": "låg"
    },
    "standard": {
      "effort_enum": "medium",
      "budget_tokens": 8192,"thinking_level": "medium"
    },
    "djup": {
      "effort_enum": "hög",
      "budget_tokens": 20 000,
      "thinking_level": "hög"
    },
    "capped-deep": {
      "effort_enum": "hög",
      "budget_tokens": 12000,
      "thinking_level": "hög"
    }
  }
}

Dessa siffror är exempel, inte universella standardvärden. Rätt budget beror på modellfamilj, prissättning, latenskrav och utvärderingsresultat. Den viktiga implementeringsdetaljen är att gatewayen äger mappningen och registrerar den lösta leverantörsparametern för varje begäran.

Feil stängd när en mappning är osäker

Resonemangskontroller som inte stöds bör inte tyst bli standardvärden för leverantören. Standardvärden kan vara dyra och de kan ändras med tiden.

Använd ett av tre resultat när en begärd profil inte kan mappas säkert:

• Tillåt: leverantören/modellen stöder den begärda profilen och hyresgästpolicyn tillåter det.
• Nedgradera: tillämpar den begärda profilen ovan och den begärda gateway-posten gäller så att den begärda profilen är ovan. nedgradera.
• Avvisa: profilen kan inte representeras på ett säkert sätt, hyresgästen kräver strikt beteende, eller så skulle nedgradering strida mot produktens förväntningar.

Exempel på beslutsprotokoll

{
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "djup",
  "applied_reasoning_profile": "standard",
  "decision": "nedgraderad",
  "decision_reason": "hyresgäst_månadsmässiga_djupa_resonemang_budget_överskred",
  "served_provider": "provider_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "effort": "medium"
  }
}

Denna beslutspost är värdefull under support, faktureringstvister och kvalitetsutredningar. Det förhindrar också osynliga kvalitetsregressioner under budgetpress.

Budgetkontroller behöver fler än maxutdatatoken

En maximal utdatatokengräns är nödvändig, men den är inte tillräcklig. För resonemangabla modeller kan modellen spendera en stor del av gränsresonemangen och lämna för lite utrymme för det slutliga svaret. Användaren kan då betala för ett oanvändbart trunkerat svar.

Använd skiktade tak:

• max_reasoning_profile per klient, API-nyckel och arbetsflöde.
• max_thinking_budget eller motsvarande per leverantör/modellpar.
• max. räknar resonemang och synliga utdata tillsammans.
• daily_deep_reasoning_spend per hyresgäst eller återförsäljarkund.
• deep_reasoning_requests_per_hour för högvolymslutpunkter.
• reasoning_tokenly_ratio_>for varningar.

Budgetkontrollen bör ske före utskick. Avvecklingssteget bör sedan stämma av den faktiska användningen efter att leverantörens svar anländer. Om leverantören rapporterar tanketokens separat, lagra dem separat. Om den bara rapporterar totala utdata-tokens, lagra de bästa tillgängliga normaliserade fälten och markera konfidensnivån.

Ledger Fields for Reasoning Use

Analytics måste visa skillnaden mellan synlig svarslängd och betald resonemangsansträngning. En användbar reskontrarad bör innehålla:

• tenant_id, api_key_id, end_user_id och workflow.
• requested_model, served_model, provider och model alias.
• requested_reasoning_profile och applied_reasoning_profile.
• provider_reasoning_param, lagrad som strukturerad JSON.
• input_tokens, visible_codeout_out, visible_code> reasoning_tokens_or_equivalent, cached_tokens och total_billable_tokens.
• max_output_tokens och eventuella leverantörsspecifika tankebudgetar.
• latency_to_first_token_codems>,
status.
• estimated_cost_before_dispatch, reserved_budget, settled_cost och reconciliation_status.
• tankekedja som standard. För de flesta styrelse- och FinOps-arbeten räcker det med räkningar och policybeslut. Att lagra känslig resonemangstext kan skapa problem med sekretess, efterlevnad och kvarhållning som kan undvikas.

  Implementeringsflöde

  En produktionsgateway kan implementera resonemang-ansträngningsdirigering som en deterministisk begäranpipeline.

  1. Autentisera begäran. Lös klienten, API-arbetsflödet, användaren, teamet, klassen, teamet, teamet och användaren. arbetsbelastning. Använd ett explicit klientfält där det är möjligt.För kända slutpunkter, bind arbetsbelastningsklass vid ruttkonfiguration.
  2. Laddpolicy. Sammanfoga globala, klient-, nyckel- och arbetsflödesbegränsningar.
  3. Välj modellkandidater. Använd det befintliga modellaliaset eller modellvalspolicyn innan du löser resonemangskontroller.
  4. använd standardprofilen för flödesresonem.använd sedan arbetsprofilen. och maximivärden.
  5. Kontrollera kompatibiliteten. Bekräfta att leverantören/modellparet stöder den valda profilen på ett säkert sätt.
  6. Uppskatta kostnaden och reservera budget. Inkludera sannolikt resonemangsanvändning, inte bara synligt resultat.
  7. Skicka med parametrar som är inbyggda i leverantören. Skicka en enum-ansträngning, ingen ansträngning eller kontrollnivån för budgeten. adapter.
  8. Normalisera användningen vid svar. Separat indata, synlig utdata, resonemang, cachad, verktyg och totala tokens där det är möjligt.
  9. Skäll och varna. Jämför reserverade och faktiska kostnader, uppdatera kvoter och avge avvikelsesignaler.

  Denna kontrollpipeline keeps. Det ger också plattformsteam ett enda ställe att ändra standardinställningar när leverantörs-API:er utvecklas.

  Utvärdering innan du ändrar standardinställningar

  Främja inte högre resonemangsansträngningar endast baserat på några få imponerande exempel. Kör utvärderingar innan du ändrar standardinställningarna för en arbetsbelastningsklass.

  Mät minst fyra resultat:

  • Uppgiftens kvalitet: noggrannhet, granskarens acceptans, schemavaliditet eller framgång för verktygssamtal.
  • Latens: tid till första token och total förfrågan och total kostnad per förfrågan och kostnad per förfrågan och total kostnad per förfrågan och total kostnad per förfrågan. accepterat svar.
  • Fellägen: trunkering, avslag, felaktig utdata, överdrivna verktygsanrop eller timeout.

  Nyckelmåttet är inte "tokens per begäran." Ett svar med lägre token som misslyckas med validering kan bli dyrare efter återförsök. Ett mer motiverat svar kan vara motiverat för säkerhetsgranskning men slösaktigt för att märka biljetter. Utvärdera efter arbetsflöde.

  Avvägningar

  Resonemang styrning ger kontroll, men det är inte gratis.

  • Portabilitet kontra leverantörsfunktioner: interna profiler håller applikationskoden portabel, men avancerade team kan behöva en godkänd utrymningslucka för leverantörsspecifika kontroller.
  hårda kontroller. från skenande utgifter, men alltför snäva tak kan avkorta användbara svar efter att resonemangstokens redan är förbrukade.
  • Dynamiskt tänkande kontra förutsägbarhet: dynamiska leverantörskontroller kan förbättra bekvämligheten, men de försvagar kostnadsuppskattningar före utsändning om inte gatewayen registrerar faktisk användning och upprätthåller avveckling och upprätthåller tillgängligheten. konsistens: nedgradering av resonemang under budgetpress bevarar tillgängligheten, men svaret bör märkas i telemetri och inkluderas i kvalitetsutvärdering.
  • Analytik kontra integritet: resonemang-token-statistik är användbara, men råa resonemangsspår bör inte lagras såvida det inte finns en avsiktlig, godkänd Retention/Retention Policy. a Standard Gateway Control

    Detta är en förutsägelse, inte ett verifierat faktum: resonemangsansträngning kommer att bli en normal produktionskontroll tillsammans med modellrouting, hastighetsgränser, servicenivåer och tokenbudgetar. När leverantörer fortsätter att exponera olika tankekontroller kommer applikationsteamen att ha mindre aptit på att hårdkoda dessa skillnader i produktkod.

    Gateways som behandlar resonemang som en styrd körtidsdimension kommer att ha tydligare fakturering för hyresgäster, renare portabilitet och bättre kontroll över latens.Gateways som behandlar det som en tillfällig modellparameter kommer att få svårt att förklara varför korta svar ibland kostar mer än långa.

    Aktiveringslista

    • Definiera interna profiler: ingen, låg, standard, djup och deep och maximal
    -profiler för varje profil. arbetsbelastningsklass.
    • Bygg en leverantörs-/modellkompatibilitetsmatris för resonemangskontroller.
    • Översätt profiler till leverantörsbaserade parametrar i adapterlagret.
    • Feil stängd när en begärd profil inte kan mappas säkert.
    • Reservera budget före avsändning med hjälp av resonemangsmedvetna uppskattningar.
    • Resonemangs-medvetna uppskattningar.
    • latens och kostnad.
    • Lägg till anomalivarningar för höga resonemang-token-kvoter och djupa resonemang i enkla arbetsflöden med stora volymer.
    • Kör utvärderingar på arbetsflödesnivå innan du ändrar standardinsatsen.
    • Undvik att logga rå resonemangstext som standard; lagra räkningar och policybeslut istället.

    Slutsats

    Modeller som kan resonera är användbara eftersom de kan spendera mer beräkning på svåra problem. Samma förmåga blir dyr när den tillämpas urskillningslöst. Gatewayen bör bestämma när djupare resonemang tillåts, hur den mappas till varje leverantör, hur mycket budget den kan förbruka och hur resultatet mäts.

    Det hållbara mönstret är att separera resonemangsinsats från modell-ID. Rutta efter arbetsbelastning, tak för hyresgästpolicy, anpassa per leverantör och ställ in faktisk användning i reskontran. Det förvandlar resonemang från en dold kostnadsvariabel till en explicit kontrollyta för AI API-kostnadskontroll.

    Relaterad läsning

    • faktureringsreskontra som reserverar och reglerar varje modell
    • interna modellalias och kapacitetskontrakt