Claude Desktop start op mijn Mac automatisch mee bij het inloggen. Dat is geen luxe maar een voorwaarde: werk dat ik vanaf mijn telefoon wegzet draait op deze machine, en die moet wakker zijn met de app open. Het gevolg is dat ik de app zelden zie starten. Hij is er gewoon als ik het scherm openklap. Wat ik wel merkte, was dat het eerste halve minuutje na inloggen stroperig aanvoelde, en ik had dat al lang geleden weggeschreven onder “laptop moet nog op gang komen”.
Op 19 augustus meldde het ontwikkelaarsaccount van Anthropic dat Claude Desktop nu ongeveer twee keer zo snel start als een maand geleden. De reden die ze erbij geven is precies mijn situatie: als de app in de achtergrond startte, werden zijn timers afgeknepen en zakte de JavaScript-motor in een energiebesparende stand. Ze zeggen nu op volle snelheid te booten terwijl het venster nog verborgen is.
Wat er onder die zin zit
Claude Desktop is een Electron-app, dus onder de motorkap draait Chromium. En Chromium behandelt een pagina die niemand ziet bewust anders dan een pagina die iemand aankijkt. Dat is geen bug maar beleid, bedoeld om accuduur te sparen bij de twintig tabbladen die je open hebt staan.
| Toestand | Wat de motor doet | Bedoeld voor |
|---|---|---|
| Zichtbaar | Timers lopen normaal, animatieframes op schermsnelheid | De tab waar je naar kijkt |
| Verborgen | setTimeout en setInterval worden samengevoegd tot ongeveer één keer per seconde, animatieframes stoppen | Achtergrondtabs |
| Verborgen en stil | Intensieve afknijping: nog ongeveer één keer per minuut, bij een volledig geladen pagina al na tien seconden verborgen te zijn | Tabs die je vergeten bent |
| Achtergrondproces | Het rendererproces zakt in prioriteit, de JavaScript-motor kiest zuiniger boven sneller | Accuduur |
Voor een tabblad met een nieuwsartikel is dat prima. Voor een app die op dat moment staat op te starten is het funest. Opstarten van een Electron-app is grotendeels JavaScript: modules inladen, sessie herstellen, verbindingen opzetten, connectors aanspreken. Veel van dat werk hangt aan timers en beloftes die netjes op elkaar wachten. Zet je die keten op één tik per seconde, dan wordt een startprocedure van vijftig stappen ineens een startprocedure van bijna een minuut, zonder dat er ergens iets traags gebeurt.
Electron heeft hier een knop voor. In de vensterinstellingen kun je backgroundThrottling: false zetten, en dan houdt de pagina zich voor de motor voor dat ze zichtbaar is. Dat die knop bestaat betekent niet dat hij overal doet wat je hoopt. In de bugtracker van Electron staan meldingen van jaren oud waarin de knop wel werkt voor een geminimaliseerd of afgedekt venster, maar niet voor een venster dat met hide() echt verborgen is. Wat Anthropic precies heeft aangepast, staat nergens beschreven.
Het getal dat niet te controleren is
“Ongeveer twee keer zo snel” is de enige meting in de aankondiging. Er staat geen versienummer bij, geen besturingssysteem, geen aantal metingen, geen begin- en eindtijd in milliseconden, en geen definitie van wat “gestart” betekent. Is dat het moment waarop het venster verschijnt, of het moment waarop je kunt typen? Dat scheelt in elke app een factor.
Ik heb gezocht naar de onderbouwing. De officiële release notes voor de Claude-apps in het helpcentrum van Anthropic noemen deze wijziging op 19 augustus niet, en de release notes van het platform verwijzen voor app-nieuws door naar dat helpcentrum. Er is dus geen changelog-regel, geen versienummer en geen tweede bron. Eén bericht op X is alles.
De claim kan best kloppen. Je kunt hem alleen niet nakijken. Het enige harde dat je eraan hebt is de oorzaak, want die is wel na te lezen in de documentatie van Chromium en Electron.
Onder het bericht ging het overigens nauwelijks over opstarttijd. De best gelezen reacties gingen over de app in het algemeen en over verbruik, met als scherpste grap de vraag of dit verklaart waarom iemands limiet twee keer zo snel opraakt. Dat bewijst niets, maar het laat wel zien waar het publiek nu zit.
De kanttekening
Een prestatieclaim zonder meetopzet wordt de norm. Als “ongeveer twee keer zo snel” zonder versienummer en zonder methode voldoende is voor een aankondiging, verschuift de lat voor wat als meting telt. Bij een opstarttijd is de schade beperkt. Bij een claim over nauwkeurigheid of veiligheid van een model is dezelfde vormgeving een stuk gevaarlijker, en de gewenning komt uit dit soort kleine berichten.
De controle landt bij jou, zonder gereedschap. Je kunt niet in een changelog kijken welke versie de fix draagt, dus je kunt ook niet vaststellen of jouw installatie hem al heeft. Wat overblijft is zelf meten, en de meeste mensen doen dat niet. Voor een gratis snelheidswinst is dat te overzien, maar het is dezelfde structuur als bij een update die iets stukmaakt: je merkt het pas als je erin loopt.
Minder spaarstand betekent meer verbruik terwijl je er niet bij bent. De afknijping die hier is weggehaald bestond niet zonder reden. Een app die bij het inloggen meestart, verborgen blijft en nu op volle snelheid draait, doet dat op momenten dat jij niets van hem vraagt. Op een laptop op accu is dat merkbaar, en het is precies het soort verbruik dat nooit in een aankondiging staat, omdat het aan jouw kant landt en niet aan die van de aanbieder.
Wat ik zelf doe
Twee dingen. Ik meet het bij mezelf voordat ik het geloof: laptop opnieuw opstarten, stopwatch tot het moment dat ik daadwerkelijk een prompt kan intypen, en dat een paar keer. Zonder een cijfer van vóór de wijziging kan ik geen factor bevestigen, maar ik weet dan wel of de eerste minuut nog stroperig is.
En ik ben mijn eigen werk gaan nalopen op dezelfde val. Alles wat ik in een verborgen browsertab laat lopen, zoals een langlopende taak die met een timer zijn eigen voortgang bijhoudt, kan op precies deze manier stilvallen zonder foutmelding. Dat soort werk hoort in de terminal, niet in een tab die achter mijn editor verdwijnt. Ik gebruik de laptop ook voor gesproken werk waarbij de app continu meeluistert, en daar geldt hetzelfde: verborgen is niet hetzelfde als uit.
Veelgestelde vragen
Moet ik iets doen om dit te krijgen?
Nee. Het gaat om een wijziging in de app zelf, dus je krijgt hem met een update mee. Omdat er geen versienummer bij de aankondiging staat, kun je alleen niet nakijken of jouw installatie hem al draagt.
Geldt dit ook als ik de app handmatig start?
Waarschijnlijk niet, of veel minder. Het probleem trad op als het venster bij het opstarten verborgen was, wat vooral gebeurt bij automatisch meestarten na het inloggen. Start je de app zelf, dan is het venster meteen zichtbaar en knijpt de motor niets af.
Kan ik dit in mijn eigen Electron-app voorkomen?
Er is een instelling voor, backgroundThrottling: false in de vensterinstellingen, maar reken er niet blind op. Er staan meldingen open waarin die instelling wel werkt voor een geminimaliseerd venster en niet voor een echt verborgen venster. Meten is hier het enige antwoord.
Bronnen
- @ClaudeDevs op X, bericht over de opstarttijd van Claude Desktop, 19 augustus 2026.
- Chrome for Developers, “Heavy throttling of chained JS timers beginning in Chrome 88”, geraadpleegd 19 augustus 2026.
- Chromium blink-dev, “Intent to Ship: Quick intensive timer throttling of loaded background pages”, geraadpleegd 19 augustus 2026.
- Electron, documentatie
BrowserWindowenwebPreferences.backgroundThrottling, geraadpleegd 19 augustus 2026. - Electron, issues 20974, 31016 en 9567 over
backgroundThrottling, geraadpleegd 19 augustus 2026. - Anthropic Help Center, “Release notes” voor de Claude-apps, geraadpleegd 19 augustus 2026.
Gecontroleerd op 19 augustus 2026. Wat ik niet heb kunnen verifiëren: de factor twee zelf, want er is geen meetopzet gepubliceerd en ik heb geen meting van vóór de wijziging. Ook het versienummer waarin de fix zit heb ik niet gevonden. De bronnen spreken elkaar niet tegen, maar ze dekken elkaar ook niet: het helpcentrum van Anthropic noemt deze wijziging op 19 augustus nergens, terwijl dat volgens de platformdocumentatie de plek is waar app-nieuws hoort te staan. De uitleg over afknijping in de achtergrond komt uit de documentatie van Chromium en Electron en niet van Anthropic, dus de koppeling tussen die mechaniek en deze specifieke fix leun ik op de formulering in het bericht zelf.