> Így működik az effort, az adaptív thinking és a thinking_level a Claude-nál, az OpenAI-nál és a Gemininél, mennyibe kerül a thinking, és hogyan válassz szintet
>
> Web page: https://balazscsorba.com/hu/blog/reasoning-models-effort-thinking-budget · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/reasoning-models-effort-thinking-budget.md) · [Deutsch](https://balazscsorba.com/de/blog/reasoning-models-effort-thinking-budget.md)
> Author: Balázs Csorba · Published: 2026-10-17 · Keywords: reasoning effort parameter, claude effort parameter, claude adaptive thinking, budget_tokens deprecated, openai reasoning effort, gemini thinking_level, thinking tokens cost, reasoning tokens billing, task budget claude, overthinking reasoning models, max_tokens thinking

[Blog](https://balazscsorba.com/hu/blog)/LLMOps és értékelés

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

Így működik az effort, az adaptív thinking és a thinking\_level a Claude-nál, az OpenAI-nál és a Gemininél, mennyibe kerül a thinking, és hogyan válassz szintet

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 17.·10 perc olvasás

-   Reasoning models
-   Effort
-   LLMOps
-   Cost
-   Evals

![Négy függőleges sáv emelkedik rövidtől a magasig egy vonalon, a legmagasabb fölött kis jelző.](https://balazscsorba.com/images/blog/reasoning-models-effort-thinking-budget/cover.webp?v=86c39c5934)

## A lényeg röviden

-   A Claude, az OpenAI és a Gemini is tokenkeretről elnevezett szintekre váltott: effort a Claude-nál és az OpenAI-nál, thinking\_level a Gemininél.
-   A thinking-tokeneket kimeneti tokenként számlázzák akkor is, ha csak összefoglalót vagy semmit sem látsz belőlük.
-   A max\_tokens az egyetlen kemény korlát egy kérésen; az effort és a task budget iránymutatás, amelyet a modell túlléphet vagy figyelmen kívül hagyhat.
-   A több gondolkodás nem mindig jobb: kutatások túlgondolást mutatnak könnyű feladatokon, és egyes feladatokon csökkenő pontosságot hosszabb reasoning mellett.
-   A szintet saját evalokon futtatott effort-sweeppel válaszd ki, és beszélgetésenként tartsd stabilan, hogy ne törd el a prompt cache-t.

Ezen az oldalon

1.  [Mik a thinking-tokenek, és miért fizetsz](https://balazscsorba.com/#what-you-pay-for)
2.  [A vezérlők a Claude-nál, az OpenAI-nál és a Gemininél](https://balazscsorba.com/#three-apis)
3.  [A budget\_tokens-től az effortig](https://balazscsorba.com/#from-budget-tokens)
4.  [A max\_tokens az egyetlen kemény korlát](https://balazscsorba.com/#max-tokens-hard-cap)
5.  [A több gondolkodás nem mindig jobb](https://balazscsorba.com/#more-is-not-better)
6.  [Szintválasztás: az effort-sweep](https://balazscsorba.com/#effort-sweep)
7.  [Effort kérésenkénti routolása a cache feltörése nélkül](https://balazscsorba.com/#per-request-routing)
8.  [Ágenshurkok: interleaved thinking és task budget](https://balazscsorba.com/#agent-loops)
9.  [Mérd a thinkinget, mint bármely más költséget](https://balazscsorba.com/#measure-it)
10.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

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.

API

Paraméter

Értékek

Alapérték

Claude Messages API

`output_config.effort`

`low`, `medium`, `high`, `xhigh`, `max`

`medium` az Opus 5.5-ön és a Haiku 5.5-ön, máshol többnyire `high`

OpenAI Responses API

`reasoning.effort`

`none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`

Modellfüggő, a gpt-5.5-ön `medium`

Gemini API

`thinking_level`

`minimal`, `low`, `medium`, `high`

Modellfüggő, a gemini-3.8-flash-en `medium`

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 kihagyott effort nem stabil beállítás**

A Claude Opus 5.5 alapértéke `medium`, a Claude Opus 5-é `high` volt. Az Anthropic jelzi, hogy egy `effort` nélküli kérés ezért egy szinttel lejjebb fut, mint az Opus 5-ön. Ha effort beállítása nélkül cserélsz modellazonosítót, egyszerre két változót módosítasz. Rögzítsd a szintet a kódban, és a modellfrissítést kezeld migrációként, saját [regressziós futtatással](https://balazscsorba.com/hu/blog/llm-model-migration-regression-testing).

## 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](https://balazscsorba.com/hu/blog/structured-outputs-json-schema-llm) 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.

A sweep olcsó ahhoz képest, mintha egy hónapig rossz szinten futna éles környezetben. Futtasd újra, valahányszor változik a modellazonosító.

```
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](https://balazscsorba.com/hu/blog/llm-evals-for-product-features): 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](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-routing). 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](https://balazscsorba.com/hu/blog/agent-loop-explained) 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](https://balazscsorba.com/hu/blog/agent-observability-opentelemetry) cikk írja le.

## Források

1.  [Claude Platform Docs: Effort](https://platform.claude.com/docs/en/build-with-claude/effort)
2.  [Claude Platform Docs: Extended thinking (manual budget\_tokens mode)](https://platform.claude.com/docs/en/build-with-claude/extended-thinking)
3.  [Claude Platform Docs: Steering thinking (cost, caching, pricing)](https://platform.claude.com/docs/en/build-with-claude/thinking-steering-and-cost)
4.  [Claude Platform Docs: Task budgets](https://platform.claude.com/docs/en/build-with-claude/task-budgets)
5.  [OpenAI API Docs: Reasoning models](https://developers.openai.com/api/docs/guides/reasoning)
6.  [Google AI for Developers: Gemini thinking](https://ai.google.dev/gemini-api/docs/thinking)
7.  [Chen et al.: Do NOT Think That Much for 2+3=? On the Overthinking of o1-Like LLMs (arXiv 2412.21187)](https://arxiv.org/abs/2412.21187)
8.  [Gema et al.: Inverse Scaling in Test-Time Compute (arXiv 2507.14417)](https://arxiv.org/abs/2507.14417)

## Gyakori kérdések

Mi a különbség az effort és a gondolkodási keret között?

A gondolkodási keret, például a régebbi Claude-modellek budget\_tokens paramétere, tokencélt ad a válasz előtti reasoningnek. Az effort viselkedési szint, amely minden kimeneti tokent alakít, a szöveget és a tool callokat is, és a modellre bízza, gondolkodjon-e egyáltalán. A Claude 4.7-től a budget\_tokens 400-as hibát ad, ott az effort a vezérlő.

Kifizetem a thinking-tokeneket, ha nem is látom őket?

Igen. Az Anthropic a teljes thinking-tokenmennyiséget kimeneti tokenként számlázza, akár summarized, akár omitted a display értéke. Az OpenAI a rejtett reasoning-tokeneket kimenetként számlázza, a Gemini pedig a thinkinges választ a kimeneti és a thinking-tokenek összegeként árazza.

Melyik effort-szinttel kezdjek?

A modell alapértelmezésével, és futtass sweepet a saját eval-készleteden. Az alapértékek eltérnek: a Claude Opus 5.5 és a Haiku 5.5 medium, a legtöbb más Claude-modell high, a gpt-5.5 medium. Ott lépj lejjebb, ahol a minőség tart, és csak ott feljebb, ahol az evalok nyereséget mutatnak.

Miért jött vissza üres vagy csonka válasz?

A modell gondolkodás közben elérte a max\_tokens vagy max\_output\_tokens határt. A Claude max\_tokens stop\_reasont ad, az OpenAI incomplete státuszt max\_output\_tokens okkal, a Gemini hiányos kimenetet. Emeld a határt, vagy csökkentsd az effort-szintet.

Eltöri az effort váltása a prompt cache-t?

A Claude-nál igen, ha a felső szintű értéket változtatod: az effort értéke bekerül a renderelt promptba, így egy új érték érvényteleníti a cache-töréspontokat. Több mai Claude-modell bétában támogatja az üzenetenkénti effort-váltást, amely megtartja a cache-elt előtagot.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [DeepSeek V4.1 Flash 1017: 890 bájt KV-cache tokenenként, és mit nyer ezzel egy ágens](https://balazscsorba.com/hu/blog/deepseek-v4-1-flash-1017)
-   [LLM rate limitek élesben: újrapróbálás, backoff és szolgáltatóváltás](https://balazscsorba.com/hu/blog/llm-rate-limits-retries-provider-fallback)
-   [Promptverziózás élesben: git, registry, címkék és visszaállítás](https://balazscsorba.com/hu/blog/prompt-versioning-management)
-   [LLM batch API-k: félárú inferencia olyan munkára, amely várhat](https://balazscsorba.com/hu/blog/llm-batch-api-offline-workloads)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)