Reasoning effort és gondolkodási keret: mennyit gondolkodjon egy modell?

Egy éve a reasoning szabályozása egy szám kiválasztását jelentette: 4000 vagy 16 000 tokenes gondolkodási keretet. 2026-ra a három nagy API másban egyezett meg. A Claude és az OpenAI effort szintet kínál, a Gemini thinking_level értéket, és a modell kérésenként dönti el, gondolkodik-e egyáltalán. Ezt könnyebb beállítani és nehezebb átlátni, mert a szabályzó már nem egy tokenszámnak felel meg.

Ez a cikk sorra veszi, mit kínál valójában az egyes API-k, mennyibe kerül a thinking a számlán, miért a max_tokens az egyetlen kemény korlátod, miért ronthat a válaszokon a több gondolkodás, és hogyan választok szintet egy funkcióhoz: effort-sweep egy valódi eval-készleten, utána fix beállítás beszélgetésenként, hogy a prompt cache megmaradjon.

Mik a thinking-tokenek, és miért fizetsz

A reasoning modellek a látható válaszuk és a tool callok előtt, a mai modelleknél azok között is generálnak tokeneket. Minden nagy API-nál ezek kimeneti tokenként számlázódnak, vagyis az árlista drága oldalán. Az OpenAI egyértelműen kimondja, hogy a reasoning-tokenek nem láthatók az API-n keresztül, de helyet foglalnak a kontextusban, és kimeneti tokenként számlázzák őket. A Gemini a thinkinges választ a kimeneti és a thinking-tokenek összegeként árazza. Az Anthropic a teljes belső gondolkodást számlázza akkor is, ha a válasz csak összefoglalót tartalmaz.

A Claude-nál a display beállítás csak azt változtatja meg, mit látsz. summarized értékkel összefoglaló szöveget kapsz, omitted értékkel üres a thinking mező, a számlázott kimeneti token viszont mindkét esetben a modell által generált teljes gondolkodás. Az Anthropic figyelmeztet, hogy a számlázott szám nem egyezik a láthatóval. Van egy csendesebb költség is: a Claude Opus 4.5 és a 4.6-tól számozott modellek a korábbi körök thinking-blokkjait a kontextusban tartják, és minden további kérésnél bemenetként számlázzák.

A vezérlők a Claude-nál, az OpenAI-nál és a Gemininél

Messziről a három API hasonlónak tűnik, de azokban a részletekben különböznek, amelyeken a kód eltörik: hol van a paraméter, milyen értékeket fogad el egy modell, és mi az alapértelmezés. Az alapértékek számítanak a legtöbbet, mert egy kihagyott paraméter is döntés.

Nem minden modell fogad el minden értéket. A Claude-nál nem minden max-ot támogató modell támogatja az xhigh-t, és az effort-dokumentáció modellenkénti ajánlásai felülírják az általános táblázatot: az Opus 4.7 és 4.8 kódoláshoz és ágensekhez xhigh-ról javasolja az indulást, a Sonnet 5.5 jól specifikált ágensalapú kódoláshoz medium-ot. Az OpenAI-nál a GPT-6 Astra HTTP 400-zal utasítja el a none értéket. A Gemininél a gemini-3-pro-preview csak a low és a high szintet ismeri.

A budget_tokens-től az effortig

A régi Claude-vezérlő, a thinking: {type: "enabled", budget_tokens: N}, a 4.6-os modelleken elavult, a Claude 4.7-től pedig 400-as hibával elutasítják. A Claude 4.5-ön és korábbiakon továbbra is számít, mert ott ez az egyetlen thinking-mód: a keret legalább 1024 token, és kisebb kell legyen a max_tokens értéknél, 32k feletti keretre pedig az Anthropic batch-feldolgozást javasol az időtúllépések elkerülésére. A migráció a kódban kicsi, a viselkedésben nagy.

// before: fixed budget, Claude thinks on every request
{ "model": "claude-sonnet-4-6", "max_tokens": 16000,
  "thinking": { "type": "enabled", "budget_tokens": 10000 } }

// after: adaptive thinking, depth controlled by effort
{ "model": "claude-sonnet-4-6", "max_tokens": 16000,
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "high" } }

Fix kerettel a Claude minden kérésnél gondolkodik. Adaptív thinkinggel kérésenként dönt, alacsony effortnál és könnyű bemeneten akár teljesen kihagyja a gondolkodást, ezért ne írj olyan kódot, amely feltételezi, hogy minden asszisztens-kör thinking-blokkal kezdődik. Az effort a thinkingen túl is hat: alakítja a szöveget és a tool callokat, az alacsonyabb szintek kevesebb és tömörebb tool callt adnak. Az Opus 5.5-ön az adaptív thinking ki sem kapcsolható; a thinking: {type: "disabled"} 400-at ad.

A max_tokens az egyetlen kemény korlát

Az effort iránymutatás, nem keret. Az Anthropic viselkedési jelzésnek nevezi, a kemény plafon pedig a max_tokens, amely a gondolkodást és a választ együtt fedi le. Ha egy nehéz kérés sokáig gondolkodik, a válasz megírása előtt elérheti ezt a plafont. A Claude ilyenkor stop_reason: "max_tokens" értékkel áll meg. Az OpenAI status: "incomplete" állapotot ad max_output_tokens okkal, akár mielőtt bármilyen látható kimenet keletkezne, és a reasoningért így is fizetsz. A Gemini ugyanígy viselkedik, és számlázza a legenerált thinking-tokeneket.

Az OpenAI azt javasolja, hogy kezdetben legalább 25 000 tokent tarts fenn reasoningre és kimenetre, az Anthropic pedig nagyobb modelljein xhigh és max szintnél 64k körüli indulást javasol. Csonkolásnál döntsd el, melyik javítás illik: ha a csonka kéréseknek kellett a reasoning, emeld a plafont; ha túlgondolták, csökkentsd az effortot. Akárhogy is, a csonkolt esetet kezeld a kódban, ahelyett hogy félkész választ szállítanál.

// Claude: treat truncation as a failure, not as an answer
const res = await client.messages.create({
  model: "claude-opus-5-5",
  max_tokens: 32000,
  output_config: { effort: "high" },
  messages,
});
if (res.stop_reason === "max_tokens") {
  metrics.increment("llm.truncated", { effort: "high" });
  // retry once with a larger cap, or fall back to a lower effort
}
const thinking = res.usage.output_tokens_details?.thinking_tokens ?? 0;

A több gondolkodás nem mindig jobb

Az intuitív modell, hogy több reasoning jobb választ jelent, nehéz feladatokon igaz, a széleken viszont elbukik. Chen és társai 2024 végén dokumentálták az o1-stílusú modellek túlgondolását: túlzott számítás egyszerű feladatokra minimális haszonnal, például hosszú láncok a 2+3-ra. 2025 júliusában az Anthropichoz köthető kutatók olyan feladatokat publikáltak, ahol a hosszabb reasoning rontja a pontosságot, vagyis fordított skálázódást a futásidejű számítás és a minőség között, többek között irreleváns információtól elterelődő és látszólagos összefüggések felé sodródó modellekkel.

A gyártói dokumentációk ugyanezt mondják üzemeltetési nyelven. Az Anthropic Opus 4.7-re vonatkozó útmutatója szerint a max a legtöbb munkaterhelésnél jelentős költséget ad kis nyereségért, és strukturált kimenetű vagy kevésbé intelligenciaigényes feladatokon túlgondoláshoz vezethet. Az OpenAI csak akkor javasolja az xhigh-t, ha az evalok egyértelmű hasznot mutatnak. Egy adatkinyerő vagy osztályozó funkciónál a helyes válasz gyakran a legalacsonyabb szint, amely még tartja a minőséget, strukturált kimenettel kombinálva, hogy a formátum ne attól függjön, mennyit gondolkodott a modell.

Szintválasztás: az effort-sweep

Minden gyártó ugyanazzal az utasítással zárja az útmutatóját: teszteld a saját munkaterheléseden. Az Anthropic kifejezetten azt mondja, hogy friss sweepet futtass, ne vidd át a beállításokat egy korábbi modellről, mert a szinteket generációnként újrakalibrálják. A gyakorlatban ez egy kis szkript: ugyanaz az eval-készlet, ugyanaz a modell, minden támogatott szint, és szintenként négy szám.

for (const effort of ["low", "medium", "high", "xhigh"]) {
  const runs = await Promise.all(evalSet.map(async (c) => {
    const t0 = Date.now();
    const r = await client.messages.create({
      model, max_tokens: 64000, output_config: { effort },
      messages: c.messages,
    });
    return { ms: Date.now() - t0, out: r.usage.output_tokens,
             truncated: r.stop_reason === "max_tokens",
             score: await grade(c, r) };
  }));
  report(effort, runs); // pass rate, mean output tokens, p95 ms, truncation rate
}

Az eredményt görbeként olvasd, ne győztesként. Ha a medium ugyanazokat az eseteket teljesíti, mint a high, a kimeneti tokenek töredékéért, a medium nyer. Ha a high épp az üzletileg fontos eseteket javítja, a plusz tokenek olcsók. A nehéz rész az értékelés, és ez ugyanaz a munka, mint bármely LLM-eval egy termékfunkcióhoz: valódi forgalomból címkézett esetek és egy értékelő, amelyben megbízol.

Effort kérésenkénti routolása a cache feltörése nélkül

Funkciónként egy szint az alapvonal. A következő lépés, hogy kérésenként változtatod: low egy rutin megerősítéshez, high a tervezési lépéshez. Az Anthropic a dinamikus effortot bevált gyakorlatként említi, egy csapdával. A feloldott effort-érték bekerül a renderelt promptba, így a felső szintű érték változtatása két kérés között érvényteleníti a cache-töréspontokat. Az Anthropic saját példájában a második kérés teljes cache-olvasást mutat, a harmadik pedig új cache-írást, miután az effort medium-ról low-ra csökkent.

Két kerülőút van. Munkaterhelések között a funkcióhatáron routolj, ahol a beszélgetések amúgy sem osztoznak cache-en; a logika ugyanaz, mint a modell-routingnál. Egy beszélgetésen belül a mai Claude-modellek, például az Opus 5.5, a Sonnet 5.5 és a Haiku 5.5 bétában támogatják az üzenetenkénti effort-váltást a mid-conversation-output-config-2026-07-01 fejléc mögött: egy üres, output_config.effort értéket hordozó system üzenet a következő felhasználói körtől váltja a szintet, és cache-ben hagyja a korábbi előtagot.

A promptalapú terelés a harmadik eszköz. Az Anthropic olyan mondatokat dokumentál rutinkörökre, mint az "Answer directly without deliberating.", de figyelmeztet, hogy ez a megfogalmazásra érzékeny és kevésbé megbízható, mint az effort, a Haiku 5.5-ön pedig a fékező mondat nem csökkentette megbízhatóan a gondolkodást. Én csak akkor használom, ha a szint már jó.

Ágenshurkok: interleaved thinking és task budget

Egy ágensben egy felhasználói üzenetből sok kérés lesz, a max_tokens pedig csak az egyes kéréseket korlátozza, nem az egész kört. A mai modellek automatikusan gondolkodnak a tool callok között. Az Anthropic szerint az új felhasználói bemenet utáni első kérés viszi jellemzően a reasoning nagyját, a csak tool-eredményeket feldolgozó követő kérések pedig akár xhigh szinten is kihagyhatják a gondolkodást. Az OpenAI azt kéri, hogy a reasoning itemeket a function call kimenetekkel együtt add vissza, previous_response_id segítségével vagy a teljes output itemekkel, hogy a modell folytathassa a gondolkodást, ne kezdje elölről.

Az egész hurokra a Claude-nak bétában task budgetje van (task-budgets-2026-03-13): output_config.task_budget, type: "tokens" értékkel és legalább 20 000-es total mezővel. A modell egy szerveroldali visszaszámlálót lát, és beosztja magát, hogy rendezetten fejezze be. Ez ajánlás, nem kikényszerített korlát, és egy nyilvánvalóan túl kicsi keret miatt a Claude leszűkítheti vagy elutasíthatja a feladatot. Az Anthropic a mért feladatonkénti költés p99 értékéből javasolja a méretezést. Az effort lépésenként a mélységet, a task budget az összes szélességet hangolja. Az ágenshurok működését Az ágenshurok, elmagyarázva cikk tárgyalja.

Mérd a thinkinget, mint bármely más költséget

Mindhárom API külön jelenti a thinkinget, így nincs ok a találgatásra. A Claude a usage.output_tokens_details.thinking_tokens mezőt adja, amely mindig legfeljebb akkora, mint az output_tokens, streamelésnél pedig az utolsó message_delta eseményben jelenik meg. Az OpenAI az output_tokens_details.reasoning_tokens, a Gemini a total_thought_tokens mezőt adja. Tedd a mezőt minden trace-re, az effort-szint és a modellazonosító mellé.

Három grafikon elég: kérésenkénti thinking-token funkciónként, csonkolási arány effort-szintenként, és minőségi pontszám effort-szintenként a mintavételezett evalokból. Ha egy promptváltozás után kúszik felfelé a kérésenkénti gondolkodás, még aznap látod, nem a számlán. A tracing oldalát az LLM-ágensek megfigyelhetősége OpenTelemetryvel cikk írja le.

Források

1. Claude Platform Docs: Effort
2. Claude Platform Docs: Extended thinking (manual budget_tokens mode)
3. Claude Platform Docs: Steering thinking (cost, caching, pricing)
4. Claude Platform Docs: Task budgets
5. OpenAI API Docs: Reasoning models
6. Google AI for Developers: Gemini thinking
7. Chen et al.: Do NOT Think That Much for 2+3=? On the Overthinking of o1-Like LLMs (arXiv 2412.21187)
8. Gema et al.: Inverse Scaling in Test-Time Compute (arXiv 2507.14417)