Mijn Mac mag nu dicht. Claude, Codex, OpenCode en Grok draaien op een aparte server in een datacenter, met vier blijvende browserprofielen en een eigen werkplek die ik vanaf mijn Mac of telefoon open. Een agent kan dus doorwerken terwijl mijn laptop slaapt.
Dat klinkt alsof je vooral een grote server moet kopen. Dat dacht ik eerst ook. De praktijk bleek minder spannend en een stuk nuttiger: 31 GiB werkgeheugen helpt, maar opruimen, begrenzen en gescheiden browsers maken het verschil tussen een agentbox en een dure computer die langzaam volloopt.
De hele agentbox in één tabel
| Onderdeel | Onze inrichting | Waarom dat nodig is |
|---|---|---|
| Computer | 12 processorkernen, 31 GiB RAM en ongeveer 1 TB schijf | Meerdere agents en browsers kunnen tegelijk werken zonder dat één taak alles opeet. |
| Besturingssysteem | Debian 13 | Een rustige Linux-basis die goed met diensten en geheugenlimieten omgaat. |
| Agents | Claude, Codex, OpenCode en Grok | Per taak kunnen we het gereedschap kiezen dat het best past. |
| Browsers | Vier blijvende Chromium-profielen | Accounts en cookies blijven per werkplek bewaard en agents zitten elkaar minder in de weg. |
| Bediening | Eén webapp via een privéverbinding | Dezelfde gesprekken zijn vanaf Mac en telefoon bereikbaar. |
| Opruimen | Automatische schoonmakers voor sessies, tijdelijke bestanden en verweesde browsers | Het systeem ruimt werkgeheugen op zonder gesprekken of logins weg te gooien. |
| Bewaking | Geheugen, schijf, belasting en wachttijd worden gemeten | Een melding gaat over echte druk, niet alleen over een groot getal in een dashboard. |
Waarom ik dit niet meer op mijn Mac draai
Een laptop is gemaakt voor iemand die hem open- en dichtklapt. Hij gaat slapen, wisselt van wifi, verliest een tunnel of krijgt een update. Dat is normaal gedrag voor een laptop en vervelend gedrag voor een agent die om drie uur ’s nachts een rapport moet maken.
De server staat altijd aan. Hij heeft een vast besturingssysteem, een vaste werkmap en dezelfde browsers. Als ik op mijn Mac een taak start en daarna vertrek, blijft die taak op de server draaien. Mijn telefoon toont alleen de bediening en de berichten. Het zware werk gebeurt niet op het apparaat in mijn hand.
Dat is hetzelfde verschil als tussen gereedschap meenemen in de kofferbak en een vaste werkplaats huren. Met een kofferbak kun je prima één klus doen. Bij dagelijks werk wil je een bank, vaste stopcontacten en een kast waarin alles morgen nog op dezelfde plek ligt.
Vier browserprofielen zijn belangrijker dan vier agents
Veel agenttaken eindigen in een browser. Search Console openen, een WordPress-pagina controleren, een formulier testen of een dashboard lezen: een API is niet altijd beschikbaar en soms is de gewone website de enige route.
Daarom draaien er vier zichtbare browserwerkplekken. Elk profiel heeft zijn eigen cookies, lokale opslag en vensters. Ze starten als vaste diensten. Een agent krijgt dus geen verse wegwerpbrowser die na de taak verdwijnt.
Dat voorkomt een groot deel van het bekende uitlogprobleem. We wissen de profielen niet bij een opruimronde en starten niet voor iedere klus met een lege browser. Toch kan niemand eerlijk beloven dat een account nooit meer om een login vraagt. Google, Meta of een andere aanbieder kan een sessie zelf laten verlopen of opnieuw controle vragen. Onze inrichting voorkomt vooral dat wij onszelf uitloggen.
De agents delen een machine, niet één rommelige tafel
Claude, Codex, OpenCode en Grok staan naast elkaar op dezelfde server. Dat betekent niet dat alle processen op één hoop liggen. De agents gebruiken dezelfde projecten en kunnen dezelfde soorten werk doen, maar hun draaiende sessies en browsers blijven herkenbaar.
Boven die laag zit onze webapp. Die maakt een gesprek aan, start de gekozen agent en stuurt de uitvoer terug naar hetzelfde gesprek. De webapp is dus de receptionist. De agent is de vakman. De browser is zijn werkbank.
Voor teamwork is die scheiding belangrijker dan het model. In mijn eerdere stuk over een teamworkflow schreef ik al dat losse chats pas nuttig worden als overdracht en context kloppen. De agentbox maakt die afspraak technisch: één plek voor gesprekken, vaste projecten en hervatbare sessies.
31 GiB RAM lost slecht gedrag niet op
Op 23 augustus 2026 mat de server 31 GiB werkgeheugen. Daarvan was 6,6 GiB werkelijk in gebruik en 24 GiB beschikbaar. Slechts 5,8 MiB stond in de wisselruimte. De wachtdruk voor geheugen was 0,00.
Dat laatste getal verdient uitleg. Linux gebruikt ongebruikt geheugen graag als snelle voorraadkast voor bestanden. Daardoor kan het vakje “vrij” laag lijken terwijl het systeem nog veel kan vrijmaken. Het nuttige cijfer heet MemAvailable: wat kan een nieuw programma werkelijk gebruiken zonder dat de machine gaat worstelen?
We kijken daarnaast naar PSI, voluit Pressure Stall Information. Dat meet of programma’s moeten wachten omdat geheugen schaars is. Een melding “80% gebruikt” zegt weinig als het grootste deel makkelijk vrij te maken cache is. Een stijgende wachttijd zegt wél dat gebruikers het gaan merken.
De fout die wij maakten was simpel. Te veel agentprocessen, browserkoppelingen en MCP-servers bleven na een taak hangen. MCP is een manier waarop een agent extra gereedschap aankoppelt. Handig, maar twintig geopende gereedschapskisten nemen ook ruimte in als niemand ze gebruikt.
De oplossing was niet nog meer RAM kopen. We stopten ongebruikte gereedschappen, startten koppelingen pas wanneer een taak ze nodig had en ruimden afgeronde sessies op.
Harde geheugenmuren houden één agent klein
Een zware agent mag niet de hele machine meenemen. Daarom gebruikt de server cgroups. Dat is Linux-taal voor een hek rond een groep processen.
Onze gespreksdienst krijgt eerst een zachte waarschuwing bij 10 GiB en een harde grens bij 12 GiB. Een losse zware batch krijgt 4 GiB als zachte grens en 6 GiB als maximum. Die batch mag geen wisselruimte gebruiken. Als hij verkeerd gaat, faalt de klus in zijn eigen vak en niet de hele agentbox.
Zware taken staan bovendien in een rij. Voor de start controleert de server of minimaal 12 GiB beschikbaar is en of de geheugendruk laag genoeg is. Twee grote imports tegelijk voelen snel, totdat allebei halverwege vastlopen. Eén voor één afmaken is meestal sneller dan twee keer opnieuw beginnen.
Opruimen zonder gesprekken of logins te wissen
“Opruimen” is bij een agentbox een gevaarlijk woord. Een bot die lukraak processen doodt, kan ook een actieve browser of een antwoord dat nog wordt geschreven weggooien. Onze schoonmakers volgen daarom verschillende regels.
- Een sessie die klaarstaat maar al vijftien minuten niets doet, wordt gestopt. Het gesprek en de berichten blijven bestaan. Een nieuw bericht hervat de sessie.
- Een gesprek met een actieve beurt, een goedkeuringsvraag of een open vraag aan mij wordt overgeslagen.
- Tijdelijke bibliotheken worden pas verwijderd als ze oud zijn, niet openstaan en niet in het geheugen zijn gekoppeld.
- Verweesde browserprocessen worden opgeruimd, maar de vier vaste browserprofielen blijven staan.
- Als de webapp zelf te groot wordt, wacht de recycler tot het rustig is en herstart alleen die dienst. De gespreksdatabase blijft staan.
Dit is precies waarom “nooit uitloggen, wel opruimen” geen enkele instelling is. Je moet onderscheid maken tussen een profiel, een draaiend proces, een gesprek en een tijdelijk bestand. Wie alles als “sessie” behandelt, wist vroeg of laat het verkeerde.
Automatiseringen horen niet allemaal op de agentbox
In het begin voelt een dikke agentbox als de logische plek voor iedere cronjob. Dat is een val. Een taak die elk uur luchtdata voor een website ververst, hoort bij de productieserver van dat project. Een taak die een agent nodig heeft om een rapport te beoordelen, past wel op de agentbox.
Onze scheidslijn is nu:
| Werk | Beste plek |
|---|---|
| Website, database, webshop of publieke API | De productieserver van dat project |
| AI-onderzoek, browserwerk en eenmalige beheerklus | De agentbox |
| Vaste data-import zonder AI-oordeel | Een gewone timer bij de applicatie |
| Taak met menselijk akkoord of een agentgesprek | De agentbox, met melding en hervatbaar gesprek |
Die keuze houdt de agentbox beschikbaar en maakt storingen beter te begrijpen. Als een luchtfeed faalt, zoek ik bij de luchtfeed. Als een agent vastloopt, zoek ik op de agentbox.
Een privéverbinding is de voordeur
De webapp, browsers en beheerverbinding zijn niet bedoeld als openbare website. Ik bereik ze via een privéverbinding tussen mijn eigen apparaten en de server. Voor buitenstaanders hoeft er geen beheerpagina klaar te staan.
Dat is geen vervanging voor updates, sterke accounts of beperkte rechten. Het verkleint wel het aantal deuren waarop onbekenden kunnen kloppen. De server draait Debian 13 en de diensten werken onder een gewone gebruiker in plaats van alles als beheerder uit te voeren.
Een eigen server betekent ook niet dat alle AI lokaal draait. De agents gebruiken nog steeds modellen van externe aanbieders. Projectbestanden, browserprofielen en gespreksgeschiedenis staan op onze machine, maar een prompt die naar een model gaat verlaat de server. Dat onderscheid hoort in elk eerlijk privacyverhaal.
De drie fouten die het meeste leerden
We vertrouwden op het formaat van de server. Met 31 GiB RAM leek opruimen minder dringend. Hangende processen groeien alleen wat langzamer op een grote machine.
We zagen een hoog geheugencijfer als storing. Linux-cache is geen tekort. Sinds we beschikbaar geheugen en wachtdruk meten, zijn waarschuwingen rustiger en kloppen ze beter.
We zetten werk op de verkeerde machine. Productieroutines en agentwerk liepen door elkaar. Het verplaatsen van zo’n routine is pas klaar nadat de nieuwe plek aantoonbaar verse data levert. Alleen het oude proces stoppen bewijst niets.
Er ging ook iets stuk in de chatlaag. Antwoorden waren soms pas na afloop zichtbaar in plaats van tijdens het schrijven. Dat bleek een ander probleem dan RAM: de dienst die gebeurtenissen opslaat en naar de app streamt moet net zo betrouwbaar zijn als de agent zelf. Een grotere server repareert geen verkeerde datastroom.
Zo zou ik hem opnieuw bouwen
- Begin met één agent en één blijvende browser. Bewijs eerst dat een taak na een nacht nog hervat.
- Zet de privéverbinding en updates goed. Een mooie webapp is geen beveiligingslaag.
- Bewaar gesprekken los van draaiende processen. Dan kun je een vastgelopen agent stoppen zonder zijn werkgeschiedenis kwijt te raken.
- Voeg geheugenmuren toe vóór de tweede agent. Test bewust wat er gebeurt als één taak te groot wordt.
- Maak daarna pas vier browserprofielen. Geef ieder profiel een vaste plek en verwijder cookies niet tijdens onderhoud.
- Plan schoonmakers als echte diensten. Geen los script dat ooit in een terminal is gestart en daarna vergeten wordt.
- Laat monitoring een fout echt nadoen. Een testmelding omlaag én weer omhoog bewijst meer dan een groen dashboard.
Voor wie is een eigen agentbox logisch?
Als je één keer per week ChatGPT vraagt om een tekst, heb je dit niet nodig. Gebruik gewoon de app. Een eigen VPS wordt interessant wanneer agents dagelijks meerdere projecten openen, ingelogde websites nodig hebben, geplande taken draaien of werk moeten hervatten nadat jouw laptop dicht is.
De rekensom gaat daarom niet alleen over de maandprijs van een server. Tel hoeveel uren de machine zelfstandig moet draaien, hoeveel browserlogins je wilt bewaren en wat een mislukte nachtelijke taak kost. Pas als daar een duidelijk antwoord uitkomt, is de extra beheerlaag de moeite waard.
Mijn gouden regel na deze verhuizing: koop genoeg geheugen, maar ontwerp eerst hoe het weer vrijkomt. De server is groot genoeg. De afspraken maken hem betrouwbaar.
Verder lezen en bronnen
- Eerder op 1704media: een homelab en workflows automatiseren met n8n
- Van AI-chat naar een teamworkflow
- Debian: release-informatie voor Debian 13
- Tailscale: uitleg over privéverbindingen tussen apparaten
- Eigen meting op de agentbox, 23 augustus 2026: 12 processorkernen, 31 GiB RAM, 24 GiB beschikbaar, 5,8 MiB swap in gebruik en geheugen-PSI 0,00.