A tokenmaxxing vége

Az AI Tájoló mai számában a Github Copilot árazási modelljének bejelentett változásával és ennek hatásaival fogok foglalkozni.

A szoftverfejlesztők mostanra megszokhatták a havidíjas AI kódolási asszisztensek által nyújtott kényelmes workflow-t - a rögzített, „per seat” havidíjakat. Ez a modell a szinte korlátlan használat illúzióját adta, miközben a háttérben a szolgáltatók hatalmas veszteségeket nyeltek le a növekedés érdekében. A GitHub Copilot közelgő lépése az előfizetői modell megváltoztatásával azonban jelzi: a kísérletezés korszaka véget ér, és a valós számítási költségek megjelennek a vállalati számlákon.

A GitHub Copilot és a token-alapú realitás

A GitHub bejelentése alapján 2026. június 1-jétől alapvetően megváltozik a Copilot elszámolása. Bár a fix előfizetési díjak látszólag megmaradnak, azok a jövőben nem korlátlan használatot biztosítanak, hanem levásárolható „kreditekké” válnak. Ezzel a szoftverfejlesztés egyik legnépszerűbb AI-eszköze áttér a tisztán használatalapú számlázásra.

A váltás mögött kőkemény gazdasági kényszer áll. Belső adatok szerint a Copilot mögötti számítási kapacitás (compute) költsége az utóbbi hónapokban olyan mértékben megemelkedett, amit a hagyományos SaaS-modell már nem tudott kezelni. A szolgáltatók már korábban rájöttek, hogy nem minden felhasználó egyforma: aki „agentic” módon, folyamatos háttér-iterációkkal használja a rendszert, az nagyságrendekkel több erőforrást éget el, mint amit a havidíja fedez.

Hogyan töri meg ez a berögzült fejlesztői szokásokat?

A fix áras modellben kialakult egy használati kultúra, amelyet az új árazás kíméletlenül felülír.

A „Tokenmaxing” büntetése

Vannak fejlesztők, akik rászoktak arra, hogy a kontextusablakot maximálisan kihasználják: teljes kódbázisokat vagy masszív dokumentációkat emelnek be a promptba, akkor is, ha csak egy apró függvényt akarnak javítani.
Ez kognitív terhelést csökkent, hisz sokan megterhelőnek érzik azt, ha egy egyszerűbb javításhoz is akkurátus promptokat kell írni, ezeket minden egyes alkalommal megtámogatva a pontosan megfelelő mennyiségű és minőségű kontextussal.
Mivel ez a fajta működés eddig nem került extra pénzbe, a hatékonyság oltárán feláldozták a takarékosságot. Az új rendszerben viszont minden feleslegesen beküldött token közvetlenül égeti a havi keretet.

A hosszú párbeszédek luxusa

Egy-egy komplex feladat oda-vissza interakciókat kíván egy nyelvi modellel vagy kódolási asszisztenssel. Ritka, hogy egy komplex feladatspecifikációra elsőre tökéletes válasz születik. Néha a specifikációból marad ki egy-két a végeredményt komolyan befolyásoló részlet, máskor egyszerűen a modell bukik bele a feladatba több próbálkozás után is, emiatt azt a fejlesztőnek/felhasználónak tovább kell bontania még egyszerűbb feladatrészekre és újrakezdenie a folyamatot.

Egy LLM chatbot párbeszédben az első generált válasz utáni egy-egy visszakérdezés nemcsak a felhasználó új promptját küldi el az LLM-nek, hanem a beszélgetés korábbi részeit is: az eredeti promptot, az arra generált választ, a csatolt fájlokat és így tovább.

Ahogy nő egy-egy beszélgetés hossza a beszélgetés folytatása egyre drágább lesz. Minden egyes follow-up üzenet a felhasználótól egyre magasabb tokenköltséggel jár, hiszen az LLM megkapja a beszélgetés minden korábbi (felhasználói prompt és generált válasz) üzenetét.

Az újrafuttatás (Re-roll) ára

Eddig természetes volt, hogy ha az LLM hallucinált vagy pontatlan kódot adott, a fejlesztő reflexszerűen, többször is újraindította a generálást. Ez a próbálkozás-alapú workflow mostantól mérhető költséggé válik.

Nagyon is emberi dolog, hogy egy-egy már eleve hosszú promptból hiányzik egy-két kulcsfontosságú információ, és akár emiatt újra kell futtatni a promptot. Egy tisztán humán workflow-val ezt az információt nem szükséges minden alkalommal leírni a feladat specifikációjakor, hisz az szervezeti tudásként megvan mindenkinél.

A promptolás logikájából következik, hogy sokszor egyszerűen az információk sorrendjének felcserélése is jelentősen megváltoztatja az LLM-től kapott eredményt.

Ha valakit ez a félkarú-rabló használatára emlékeztet, az nem véletlen:
az LLM-működés determinisztikussága miatt az újrafuttatás szükségessége gyakran nem emberi hanyagságból vagy lustaságból fakad.

Az ágensek láthatatlan étvágya

A legmodernebb fejlesztői eszközök már nemcsak válaszolnak, hanem önállóan tesztelnek és javítanak a háttérben. Ezek az autonóm ciklusok észrevétlenül emésztenek fel hatalmas mennyiségű tokent.
A vezetőknek fel kell készülniük arra, hogy a kódoló ágensek használata nem csupán szoftverköltség, hanem egy dinamikusan változó operatív kiadás lesz.

A piaci dominóhatás

Ne legyenek illúzióink: a GitHub lépése csak az első kavics az állóvízbe.
A hírek szerint az Anthropic már megkezdte nagyvállalati ügyfelei csendes átterelését a használatalapú elszámolás felé.
Várhatóan a Claude Code, és az OpenAI Codex CLI eszközei is követni fogják ezt a mintát az egyéni felhasználók esetén is. Ennek egyik oka, hogy mindkét céget az IPO irányába sürgetik az egyre türelmetlenebbé váló befektetők, és ehhez többek között az is szükséges, hogy profittermelő pályára álljanak.

A „SaaS-típusú” AI-használat korszaka a végéhez közeledik. A szolgáltatók nem tudják és nem is akarják tovább finanszírozni a vásárlóik által használt számítási kapacitást. A piaci sztenderd a „Pay-As-You-Go” modell lesz, ahol a vállalatok a tényleges LLM futtatási költsége alapján kalkulált árazás alapján fizetnek.

Új ROI-számításra van szükség

Ez a fordulat paradox módon tisztulást hozhat. Eddig sok cég „AI-t használunk” jelszóval, mérés nélkül fizette a havidíjakat. Most azonban a CTO-k kénytelenek lesznek feltenni a kérdést:

1. Valóban hoz annyi produktivitást ez a workflow, amennyibe kerül?
2. Mennyire tervezhető egy-egy fejlesztési projektnél a várható tokenhasználat hónapról-hónapra?
3. Vajon a tokentakarékos workflow-k elég hatékonyak lesznek-e?

Érdekes fordulat lehet, hogy akár már egy 6-10 fős csapat esetén is elérheti az AI használat költsége egy-egy fejlesztő teljes bérköltségét. Ilyenkor fel fog merülni a kérdés, hogy mi ér többet - a csapat bővítése fejlődőképes mérnökökkel, vagy az LLM-alapú kódolási asszisztensek használata, annak minden előnyével és hátrányával együtt?

Eddig havi fix előfizetéssel dolgoztunk, hogyan számoljam ki, hogy milyen költségek várhatók?

• Aki eddig főleg chatbot-okat használt, az próbálja ki, hogy milyen API kulcsokkal működő OpenAI, Claude vagy Gemini chat wrapper-ekkel dolgozni (pl. OpenWebUI). Így közvetlenül láthatja minden egyes promptja futtatása után, hogy mennyit “költött.”
• Claude Code vagy Codex használóknak: ccusage a Github-on. Azért fejlesztették, hogy a tényleges token fogyasztást lehessen monitorozni Claude Code használatakor. Más "agentic" kódolási asszisztenseket is támogat már. (Pl. Codex)

Kérdés a hétre

Nálatok szerepel a költségvetési tervekben az AI-eszközök lehetséges drágulása vagy az elszámolási modell váltása? Ha holnaptól minden fejlesztői prompt számlázható tétel lenne, változtatnátok a csapatotok működésén?

Ha van tapasztalatod arról, hogyan kezelitek a fejlesztői AI-költségeket, szívesen olvasom válaszban.

laci@mentorandorient.hu

Felhasznált források

• GitHub Blog: GitHub Copilot is moving to usage-based billing (2026. április)
• GitHub Docs: Usage-based billing for individuals
• Ed Zitron / Where's Your Ed At: Exclusive: Microsoft Moving All GitHub Copilot Subscribers To Token-Based Billing (2026. április)
• Finout: Anthropic API Pricing in 2026: Complete Guide (2026. május)