Amikor legutóbb elvesztettem egy éjszakára indított ügynökfuttatást, semmi sem omlott össze. Hibaüzenet sem volt. Elindítottam egy hosszú migrációt egy repón, amit hónapok óta kerülgettem, néztem, ahogy átrágja magát az unalmas elején, aztán lecsuktam a laptopot, mert aznapra végeztem. Másnap reggel egy kávézóban nyitottam ki újra. A munkamenet eltűnt. Nem hibára futott. Megállt valahol félúton, egy félkész ággal és semmilyen feljegyzéssel arról, mi lett volna a következő lépése.
Pedig a javítást már lefuttattam. Pontosan ez fájt benne.
Ez tehát arról szól, miért nem működhetett soha az a javítás, és arról a rendkívül unalmas bérelt gépről, amelyik helyette elvégzi a munkát. Most azon futnak az AI-ügynökeim 24/7-ben, és teljesen abbahagytam a laptopom energiabeállításain való gondolkodást.
A javítás, amit mindenki ajánl
caffeinate -dimsu. Vagy egy menüsor-alkalmazás kávéscsésze ikonnal. Vagy, ha mélyebbre ástál, sudo pmset -a disablesleep 1, ami a legdurvább megoldás, és egyben az, ami a legmagabiztosabban hangzó tanácsokban felbukkan. Ezt futtattam le. Olyan érzés volt, mintha megoldottam volna a problémát.
A macOS többféleképpen is el tud aludni, és az itt fontos kettő független egymástól: a tétlenségi alvás egy időzítő, amely lejár, ha semmi sem történik, míg a fedél lecsukása rendes esetben egy külön útvonalon kényszerít alvást. Amit a caffeinate létrehoz, az energiakezelési deklarációk (power assertion) halmaza, és az ss64 caffeinate-referenciája mutatja, hogy a kapcsolói lefedik a kijelző alvását, a tétlenségi alvást, a lemez tétlenségi alvását és a rendszeralvást. Az Apple energiakezelési dokumentációja megteszi a lényeges különbségtételt: a tétlenségi alvás deklarációja továbbra sem írja felül a fedél szokásos lecsukását, az Apple menüt vagy az alacsony töltöttséget.
Az ébren tartó eszközök tehát valóban működnek azokon az alvási feltételeken, amelyek kezelésére készültek. A fedél szokásos lecsukása viszont más kérdés, és a caffeinate nem csukott fedeles szerverstratégia.
Megjegyzés:
disablesleepa furcsa eset. Egyáltalán nem szerepel a szabványos pmset-opciók referenciájában egyáltalán nem. A javítás, amiért az emberek nyúlnak, egy dokumentálatlan beállítás. Nem energiakezelési deklaráció. Csukott fedéllel is ébren tud tartani egy MacBookot, akkumulátorról is, egészen addig, amíg vissza nem kapcsolod, vagy le nem merül az akkumulátor.
Egy laptop rossz formájú a 24/7-es munkához
Volt egy időszak a kilencvenes években, amikor az emberek éles webszervereket futtattak valaki asztala alatt álló asztali gépházakon, és az egész épület megtanulta, hogy nem rúgunk bele az elosztóba. Ezt nem egy elosztóra ragasztott táblával oldottuk meg. Úgy oldottuk meg, hogy áttettük a terhelést egy gépre, amelynek az egyetlen dolga az volt, hogy egy helyben álljon és áram alatt maradjon.
Ugyanaz a formájú probléma, harminc évvel később. A MacBook olyan gép, amelyet arra terveztek, hogy lecsukják és elvigyék. Ez nem hiba az energiakezelésében. Ez maga a termék. Minden ébren tartó trükk vita egy szándékosan meghozott tervezői döntéssel, és ezt a vitát meg lehet nyerni egy ideig, cserébe azért, hogy örökké rajta jár az eszed.
Elmehetsz még tovább, és kikapcsolhatod az alvást teljesen. Gratulálok: mostantól van egy folyamatosan futó szervered, akkumulátorral a belsejében, plusz egy rendszerszintű beállításod, amelynek visszaállítására emlékezned kell, mielőtt a laptop táskába kerül. Az első kapkodós összepakolás nem állítja le a futást. Ébren hagyja a gépet, ami meríti az akkumulátort és hőt termel pontosan ott, ahol egyáltalán nem szeretnéd.
Ebben egyébként semmi új nincs. Az önállóan üzemeltetett ügynökdémonok ugyanabba a falba ütköznek, ugyanazért: akkor is futniuk kell, amikor nem ülsz az asztalodnál, ami már azelőtt kizárja a laptopot, hogy bármit is konfiguráltál volna. Ez a kategóriára már jó ideje igaz. Csak épp engem még nem került egy éjszakányi munkába.
Az ügynököd nem azon a gépen gondolkodik
A Claude Code saját rendszerkövetelményei ennyit kérnek: 4 GB or more of RAM and an x64 or ARM64 processor. Ennyi a hardversor, teljes egészében. Nincs GPU-sor. Nincs VRAM-sor. Semmi a modellről, mert a te gépeden nincs is modell.
Kínosan sokáig tartott, mire ez leesett, és pontosan ezért szűnik meg gyanúsan hangzani az ár. Az ügynökfolyamat a te gépeden három dolgot csinál: összeállítja a kontextust és API-hívásokként elküldi, körök között tartja a beszélgetés állapotát, és futtatja azokat az eszközöket, amelyeket a modell kér. Ez koordinációs munka. (Folyton a GPU-t kerestem ebben a történetben. Ebben a történetben nincs GPU.) A drága rész, az, amelyik egy rack gyorsítót kíván, valaki más adatközpontjában zajlik.
Az ügynök nem azon a gépen gondolkodik. Hívásokat intéz valamihez, ami gondolkodik.
Éppen ezért kerül annyiba egy gép, amelyik erre képes. 2026 augusztusának végén a DigitalOcean legolcsóbb Basic Droplet csomagja havi 4 $ 512 MiB-ért és egy vCPU-ért, a Vultr Cloud Compute létrája pedig 2,50 $-nál kezdődik egy 512 MB-os, csak IPv6-os példánnyal, és 1 GB-nál éri el az 5 $-t. Két szolgáltató, ugyanolyan formájú padló. Mindkét alsó fok a követelménysorban szereplő 4 GB alatt marad, és az 5 $-os kategóriájú csomagok is. Ha kifejezetten Claude Code-ot futtatsz, 4 GB a közzétett alsó határ. Az olcsó vég csak akkor működik, ha a ténylegesen futtatott ügynök igényei alacsonyabbak.
Egy határvonal, mert ezt elrontani pénzbe kerül: mindez azokra az ügynökökre igaz, amelyek hosztolt modellt hívnak. Ha az a cél, hogy a modell helyben fusson a saját hardvereden, ebből semmi sem érvényes. Egy gigabájt RAM-mal rendelkező gép nem futtat olyan modellt, amivel kódolni akarnál.
A gép azért olcsó, mert a drága rész máshol történik.
Mennyibe kerül egy Mac mini, és mit kapsz érte
Egy Mac mini most 899 $, és szeptember 22. előtt nem juthatsz hozzá. Az alap M6-os konfiguráció (12 magos CPU, 12 magos GPU, 16 GB memória, 256 GB tárhely) előrendelhető, és aznap indul a szállítása; a TechCrunch bemutatóról szóló cikke közli a számot. Az Apple ez alatt semmit nem kínál.
Ennél a számnál érdemes elidőzni. Ugyanaz a 16GB, ugyanaz a 256GB: ez a memória- és tárhelykonfiguráció 599 $-on indult 2024 októberében. Feleannyival több az alap Mac miniért, két éven belül. Volt közben egy 799 $-os lépcsőfok, amikor az Apple 2026 májusában abbahagyta a 256GB-os konfiguráció árusítását, és a belépőár együtt mozdult vele. Ez az a talaj, amelyen a vedd-meg-inkább érv áll, és ez a talaj folyamatosan mozog.
A másik oldalnak több érv szól mellette, mint amennyit szeretnék. A gép teljesen a tiéd, van viszonteladási értéke, és nincs havi tétel. Az áram üresjáratban alig számít: az Apple 4 W-ot közöl üresjáratban az M4-es konfigurációra, ami körülbelül 6,40 $-t jelent évente a 2026. júniusi egyesült államokbeli lakossági átlagos áramár mellett. A valódi terhelések többet esznek, úgyhogy nem állítom, hogy a 4 W az üzemi szám. A bérelt számítási kapacitás pedig csak a létra alján olcsó. Ugyanaz a DigitalOcean-lista, amely 4 $-nál nyit, havi 96 $-nál tetőzik egy 16 GB-os géppel, és ennek három éve a Mac mini árának többszörösébe kerül.
Szóval igen. Ha a kérdés az, hogy mennyibe kerül egy adott mennyiségű számítási kapacitást birtokolni, szemben azzal, hogy három évig bérled, vedd meg a Mac minit. Arra a kérdésre van válasz, és nem az, amelyik mellett érvelek.
Két dolog, amit egy Mac mini megvesz, és amitől megváltozik az egyenlet. Az első maga a macOS: az ott futó ügynök a macOS automatizálásán és az alkalmazásengedélyeken keresztül összeköthető a Jegyzetekkel, az Üzenetekkel, a Parancsokkal, a Naptárral és az Emlékeztetőkkel. Egy fej nélküli Linux-gépen nincsenek meg ezek a helyi alkalmazások. Ha az ügynököd dolga éppen ezekkel dolgozni, akkor a Mac mini a helyes gép, és nem fogok mást állítani.
A második a helyi inferencia, ahol a sok gyors memória egy gyors chip mellett tényleg erős értékajánlat, és semmilyen olcsó VPS nem versenyképes. A Hacker News pontosan erről szóló szálában jól érvelnek emellett, és szerintem igazuk van. Csak épp ez más kérdés, mint az enyém.
Egyik sem javítja meg azt, hogy a laptopot lecsukják. Asztali gépet venni azért, hogy a laptop ne aludjon el, annyi, mint hardvert venni egy topológiai probléma megoldására.
Mi változott, miután átköltöztettem
Pár hétig elfelejtettem, hogy létezik. Ennyi a tesztem.
Elindítottam, átköltöztettem rá az ügynököt, néhányszor ránéztem, mert még nem bíztam benne, aztán abbahagytam a nézegetést. A futások befejeződnek. A fedélnek semmihez semmi köze. A Macem most már alszik, és pontosan ezt várom egy laptoptól.
A súrlódás valós, úgyhogy tessék. Elvesztettem a helyi gépet: mindaz, amit az ügynök a saját asztali gépemhez nyúlva végzett, most már nem megy, és ez eltört két apró munkafolyamatot, amelyeket gondolkodás nélkül építettem. Van most egy szerver, rajta SSH-val, előtte tűzfallal és egy disztribúcióval, ami frissítéseket kér, ami kicsi, de állandó adó a figyelmemen. Aki azt mondja, hogy egy bérelt gép nulla karbantartást igényel, kihagy egy lépést. És azért olcsó, mert az inferencia távoli: azon a napon, amikor valamit helyben akarok futtatni rajta, az olcsó szint megszűnik az a szám lenni.
Az SSH-shellben közvetlenül elindított ügynök meghalhat, amikor az a kapcsolat megszakad. Előbb indítsd el egy tartós munkamenetben. tmux a bevett válasz, és a munkamenetek életben tartása egy távoli gépen tartalmazza a részleteket.
Aztán jön a legélesebb ellenvetés, amit erre felhoznak: nem rosszabb otthon-e egy bérelt gép egy ügynöknek, mint a hardver, amelyet fizikailag birtokolsz? Egy operátor jellegű ügynöknél, amely hozzáfér a személyes fájljaidhoz, jogos. Egy kódoló ügynöknél viszont egy VPS, amelyet root hozzáféréssel irányítasz és amelynek a tűzfalát te állítottad be, más kockázati profil, mint egy ügynökszolgáltatás, amelyet szélesre tárva teszel ki a nyilvános internetnek. Attól még virtuális gép valaki más hardverén, és minden, amit elérhetően hagysz az internet felől, továbbra is a támadási felületed része. Az a rész pedig, amely kikerül az irányításod alól, vagyis az API-hívás, amely elviszi a kódodat egy modellszolgáltatóhoz, mindenképpen kikerül. Mac vagy Linux, ez a bizalmi határ ugyanaz.
Én olyan gépet akartam, amivel abbahagyhatom a törődést. Beindítani, megerősíteni, ráültetni az ügynököt, elfelejteni. Ha épp ilyet állítasz be, egy egyszerű Linux VPS az összes, amit ez a terhelés kér, a miénk pedig egy perccel azután átadja a rootot SSH-n, hogy kiválasztottad a régiót és a disztribúciót. Nagyjából ennyi ceremónia jár ennek.
Építkezz Linux VPS-en root hozzáféréssel, NVMe-vel és AMD EPYC teljesítménnyel.
Linux csomagok megtekintéseMit mondanék annak, aki ma kezdi
Három dolog, aztán végeztem.
Amit most futtatok: egy kicsi bérelt Linux-gép, egy-két gigabájt RAM, egyetlen vCPU, NVMe tárhely, egy hozzám közeli régióban. Ennyi kell az én terhelésemnek; ha a te ügynököd magasabb alsó határt tesz közzé, azt vedd alapul. Rajta: az ügynök CLI-je, tmux, egy tűzfal, felügyelet nélküli frissítések. Nagyjából annyi figyelmet kap tőlem, mint a routerem.
A tanács, amilyen: mielőtt bármit is vennél, tedd rá az ügynököt a legolcsóbb gépre, amely megfelel a közzétett követelményeinek. Nem végleges döntésként. Tesztként. Egy héten belül tudni fogod, hogy a terhelésed API-orkesztráció-e, és akkor kész vagy, épp most tartottál meg 899 $-t, vagy tényleg saját hardverre van szüksége.
Az egyetlen dolog, amit nem csinálnék újra: heteket eltölteni az energiakezelés hangolásával. Kipróbáltam a caffeinate-t, aztán egy menüsor-alkalmazást, aztán a disablesleep-t, aztán egy ütemezett ébresztést, és minden kudarcot úgy kezeltem, mint egy konfigurációs hibát, amit még nem találtam meg. Nem az volt. Az árulkodó jel ott hevert: minden javítás egy kicsit rosszabb laptoppá tette a gépet. Egy éjszakányi munka elvesztése drága módja volt annak, hogy ezt észrevegyem.
Gyakran ismételt kérdések
Ébren tartja a Caffeinate a Macet csukott fedéllel?
Szám. caffeinate energiakezelési deklarációkat használ, hogy visszatartson olyan alvási feltételeket, mint a tétlenségi alvás és a kijelző alvása. Az Apple saját dokumentációja erről a deklarációról azt írja, hogy a rendszer így is elalhat a fedél lecsukása, az Apple menü vagy az alacsony töltöttség miatt. A fedél szokásos lecsukása kényszerített alvást indít, amit ezek a deklarációk nem akadályoznak meg, és éppen ezért működnek az ébren tartó eszközök megbízhatóan egészen addig a pillanatig, amíg a fedél be nem csukódik.
Mennyi RAM kell egy AI kódoló ügynöknek egy szerveren?
Kevesebb, mint amire a legtöbben számítanak, mert a modell nem azon fut. A Claude Code közzétett rendszerkövetelményei 4 GB vagy több RAM-ot és x64 vagy ARM64 processzort kérnek, GPU-követelmény nélkül, mivel az inferencia a modellszolgáltató hardverén zajlik. Az alsó határt az ügynök saját eszközkészlete szabja meg (a checkoutod, a build lépéseid, a nyelvi futtatókörnyezeted), nem a modell.
Olcsóbb-e egy Mac mini, mint három évig szervert bérelni?
Attól függ, mekkora gépre van szükséged. A bérleti piac alján egy kis gép három éve a Mac mini árának töredékébe kerül, amely most 899 $-tól indul az alap M6-os konfigurációval, szeptember 22-i szállítással. Menj feljebb a létrán, és a saját hardver nyer, mert a vételár véget ér, a havi számla nem. Így vagy úgy, ez egy költségkérdésre válaszol, nem arra, hogy hol kellene laknia egy hordozható gép folyamatosan futó terhelésének.
Mi tartja futásban az ügynök munkamenetét, miután lecsatlakozom a szerverről?
Egy terminálmultiplexer. Indítsd el az ügynököt a szerveren egy tmux (vagy screen) munkamenetben, majd válj le róla; tovább fut azután is, hogy az SSH-kapcsolatod megszakad, és később bárhonnan visszacsatlakozhatsz. Enélkül a terminál bezárása megölhet egy közvetlenül ahhoz a shellhez kötött folyamatot, és a szerveren pontosan azt a problémát állítja elő újra, amely elől otthagytad a laptopot.
Beszélgetés
Hozzászólások
Jelentkezzen be a beszélgetéshez.