WordPress som operativsystem for det agentiske nettet. Hvem betaler for tokens?
Automattic kunngjorde 21. april 2026 i innlegget WordPress as the Operating System of the Agentic Web at WordPress er operativsystemet for det agentiske nettet. Innlegget av James Grierson, leder for global ekspansjon, lister 8 styrker og 6 svakheter ved denne rollen. Det utelater ett spørsmål. Hvem dekker kostnaden for AI-tokens på sluttbrukerens side. Dette gapet avgjør hvem som mottar den første overraskende fakturaen når WordPress 7.0 lanseres.
“WordPress’s foundational principles position it uniquely to become the operating system of the agentic web.”
James Grierson, Automattic, 21. april 2026
Å kalle 43 prosent av nettet for “operating system” i en agentisk fremtid er en sterk påstand. Å utelate hvem som betaler for AI-bruken som flyter gjennom det systemet, er en like sterk utelatelse.
Hva Automattic faktisk kunngjorde 21. april 2026
Automattic posisjonerer WordPress som fundament for det agentiske nettet av tre grunner. Åpen kildekode, et økosystem med 61 000 gratis plugins og standardiserte API-er. James Grierson siterer Automattics egne tall, nemlig 43 prosent andel av alle nettsider og over 60 prosent av CMS-markedet. Tallet 90 000 plugins inkluderer kommersielle markedsplasser i tillegg.
Hele lista over fordeler og ulemper i innlegget
Automattic lister 8 styrker ved WordPress som plattform for AI-agenter. Et bevist, massivt økosystem. Åpen kildekode-transparens. Fagfellevurdert kode og fellesskapsstandarder. Sikkerhet via transparens. REST API og MCP-tilkobling. Handelsutvidbarhet via WooCommerce. Hook- og filterarkitektur. Tiår med dokumentasjon.
Lista over 6 svakheter er like konkret. Eldre kode og teknisk gjeld. Inkonsistent plugin-kvalitet. Forlatte og usikre plugins. Ytelsesoverhead. Kompleksitet i hook-systemet for agenter. Oppfatningen av PHP og krympende rekruttering av utviklere. Fragmentering på tvers av hosting-miljøer.
Det innlegget ikke nevner
I innlegget til Grierson dukker ordet token ikke opp én gang. Det er ingen seksjon om eierskap til API-nøkler. Det er ingen faktureringsmodell. Det er ingen scenarier der en agent tømmer den planlagte spørringskvoten midt i uka. Utelatelsen følger av forfatterens perspektiv. Innlegget kommer fra et selskap som selger hosting og AI-moduler i en pakke. En selv-hostet operatør har andre prioriteter.
En annen utelatelse gjelder logging av handlinger som agenten utfører. Hver MCP-skriving endrer databasens tilstand og krever en egen revisjonsoppføring, noe innlegget ikke berører. En tredje utelatelse gjelder personvernerklæringen, som avgjør hvilke innleggs- eller kommentardata som forlater serveren og når AI-leverandøren. Disse tre utelatelsene skiller en visjon fra et utrullingsklart produkt.
Model Context Protocol og Abilities API i praksis
Model Context Protocol er en standard som lar AI-agenter koble seg til eksterne systemer. Automattic rullet MCP inn i WordPress.com i to faser. Lesing først, skriving etterpå. Selv-hostet WordPress oppnår samme funksjonalitet via Abilities API og WordPress MCP Adapter.
Skrivebeskyttet i oktober 2025, skriving i mars 2026
WordPress.com aktiverte MCP i skrivebeskyttet modus i oktober 2025. Full støtte for skriveoperasjoner ble levende i mars 2026. Fra det øyeblikket kan en agent opprette et innlegg, publisere det, legge til en kommentar og administrere medier via naturlig språk. Hver slik operasjon genererer en kostnad på siden av modellen som utfører den.
Den praktiske konsekvensen er enkel. Aktivering av ett plugin som snakker med en agent gjør hver innleggsredigering til en forespørsel mot en ekstern AI-leverandør. Fakturaen ankommer der API-nøkkelen ligger.
Hva Abilities API endrer for selv-hostede installasjoner
Abilities API kombinert med WordPress MCP Adapter lar plugin-utviklere eksponere eksisterende funksjoner som verktøy for agenter. Adapteret brer plugin-egenskapene over til MCP-spesifikasjonen. Forfatteren av et eksisterende plugin legger til noen linjer konfigurasjon. Agenten får tilgang til funksjonen.
Denne snarveien senker terskelen for inngang, slik at antallet plugins med AI-funksjoner i WordPress.org-arkivet vokser raskere enn antallet sikkerhetsrevisjoner av disse plugins. WPPoland har observert mønsteret siden mars 2026 hos kunder i programmet vedlikehold av WordPress-nettsider.
Rollen til WordPress Playground for agenter
WordPress Playground starter en hel WordPress-instans i nettleseren på sekunder. Automattic plasserer dette verktøyet som en sandkasse for agenter. Agenten tester en endring i Playground, og bare den bekreftede handlingen returnerer til produksjon. Konstruksjonen reduserer risikoen for dataskade fra modellhallusinasjoner. Den endrer ikke hvem som betaler for de forbrukte tokens.
Gapet i visjonen, nemlig hvem som betaler for tokens
Russell Heimlich, en WordPress-utvikler med 20 års erfaring i økosystemet, stilte dette spørsmålet offentlig i WordPress AI Features Are Coming. Nobody Is Talking About What They’ll Cost Your Users den 24. april 2026. Heimlich, kjent i fellesskapet under håndtaket russellenvy, peker på at Automattic ikke nevner AI-kostnader én eneste gang i sin agentiske visjon. Poenget hans er praktisk. Når et plugin installerer seg selv, ber brukeren om å koble en konto hos en AI-leverandør, og deretter åpner et chat-felt i dashbordet, vet brukeren ikke at hver melding koster penger.
Argumentet til Russell Heimlich
Heimlich beskriver sitt eget tilfelle med arbeid mot AI-modeller. Han bruker et månedsabonnement hos leverandøren av Claude-modellen og uttømmer ukentlig grense til tross for avansert prompt- og arbeidsflytoptimalisering. Av dette trekker han en konkret konklusjon. En person uten erfaring med språkmodeller, for eksempel en matblogger som nettopp har satt opp en nettside og installert et populært plugin med AI-funksjon, vil tømme kvoten raskere og uten klar feilmelding om årsaken.
“Every interaction between an AI agent and a WordPress site costs tokens.”
“Every single one of those exchanges burns tokens. Real money. Her money. And she has no idea.”
Russell Heimlich, russellenvy.com, 24. april 2026
Et andre argument fra Heimlich gjelder ansvaret for brukeropplevelsen. Et plugin som introduserer en AI-funksjon uten leselig kostnadsmelding flytter byrden med å lære opp brukeren over på nettstedeieren og indirekte over på byrået. Et tredje argument adresserer omdømmet til WordPress som plattform. Den første bølgen av misnøye etter overraskelsesregninger faller tilbake på hele økosystemet, uavhengig av at kilden til problemet er ett enkelt plugin.
Tre modeller for eierskap til API-nøkkel og deres konsekvenser
I praksis dominerer 3 modeller for fakturering av AI-tokens i WordPress-plugins.
Bring-your-own-key. Kunden oppretter en konto hos AI-leverandøren, genererer en nøkkel og limer den inn i plugin-panelet. Kostnadene går rett til kunden. Plugin-utvikleren fungerer ikke som mellomledd. Modellen er regnskapsmessig transparent og forutsetter at kunden forstår hvordan token-kvoten virker hos leverandøren.
Abonnement administrert av plugin-utvikleren. Plugin tar en fast månedlig avgift fra kunden og gjør opp direkte med AI-leverandøren. Risikoen for misbruk faller på plugin-utvikleren, som balanserer prising mot faktisk forbruk. Modellen er praktisk for sluttbrukeren og risikabel for plugin-operatøren.
Delt token-pott med månedlig grense. Alle plugin-kunder deler én pott. Etter uttømming fornyes potten neste måned eller utvides i en høyere pakke. Modellen forenkler meldingen til brukeren og introduserer en ny effekt, nemlig naboen som forbruker mine tokens.
Scenarioet med matbloggeren fra TikTok
Heimlich beskrev dette scenarioet først. En viral blogger setter opp en WordPress-side, installerer et plugin med AI-funksjon, klikker seg gjennom veiviseren. Veiviseren ber om å koble til en konto hos Claude, ChatGPT eller Gemini. Bloggeren kobler kontoen fordi instruksjonen sier det. Deretter behandler bloggeren AI-feltet som en vanlig chat. To dager senere er ukekvoten borte. Plugin viser et tomt loader-symbol uten melding. Bloggeren skylder på WordPress. Hver del av denne historien gjentar seg hos virkelige kunder i dag.
Hva det betyr for WordPress-eiere før 7.0-utgivelsen
WordPress 7.0-utgivelsen nærmer seg raskt. Release Candidate 2 ble lansert 26. mars 2026 på wordpress.org. Datoen for generell tilgjengelighet er ikke offisielt bekreftet i prosjektets kommunikasjon. Uavhengig av nøyaktig dato modnes MCP-infrastrukturen på selv-hostet side parallelt. En operatør bør gjøre 3 trekk før den første bølgen av plugin-oppdateringer med AI inni lander.
Revisjon av installerte plugins for AI-funksjoner
Sjekk hvert installerte plugin mot 3 informasjonspunkter. Om produktets veikart har en AI-komponent i neste versjon. Om plugin-utvikleren har publisert en token-faktureringsmodell. Om det finnes en mulighet til å deaktivere AI-funksjoner uten å miste resten av pluginets evner. Plugins uten disse svarene krever overvåking av endringsloggen mellom oppdateringer.
I praksis introduserer 3 plugin-kategorier AI-funksjoner raskest. SEO-plugins, slik som Yoast SEO og Rank Math, der generatoren for meta-beskrivelser bruker en språkmodell. Kalender- og arrangementsplugins, slik som The Events Calendar, der en agent genererer beskrivelser av gjentakende arrangementsserier. Netthandel- og CRM-plugins, der en AI-assistent foreslår produktbeskrivelser og svar på kundespørsmål. Hver av disse 3 kategoriene har en annen profil for token-forbruk fordi lengden på en enkelt prompt varierer.
En full revisjon kombineres rent med en sikkerhetsrevisjon for WordPress hver sjette måned. WPPoland kjører revisjonen som del av vedlikeholdsprogrammet og legger fra mars 2026 ved et kart over AI-funksjoner i installerte plugins.
Spørsmål til plugin-leverandøren
Tre spørsmål til plugin-utvikleren før aktivering av AI-modus lyder konkret. Først, hvor API-nøkkelen ligger og hvem som betaler for den. Deretter, hvilken melding brukeren ser etter at token-kvoten er tom. Til slutt, om hver handling utført av agenten logges på en måte som lar historikken rekonstrueres. Forfattere av seriøse plugins svarer innen ett døgn. Fraværet av svar er i seg selv et svar.
Konfigurer standardatferd ved tomme tokens
Konfigurer plugin slik at fravær av tokens nedgraderer funksjonen, ikke blokkerer dashbordet. Tre innstillinger løser 80 prosent av problemene. En tekstmelding om feilårsaken i stedet for et tomt loader-symbol. En lokal kopi av det siste vellykkede svaret synlig som plassholder. Mulighet til å deaktivere AI-modulen fra en redaktørprofil uten kodeendringer.
Hva plugin-utviklere bør gjøre
Plugin-utviklere har et større ansvar enn nettstedoperatører fordi de former sluttbrukerens første møte med en AI-agent. Tre designprinsipper reduserer antallet overraskede kunder etter første faktura.
Kostnadsmelding før første forespørsel
Den første forespørselen til en agent forutgås alltid av en melding. Plugin viser hvilken handling som vil utføres, hvor mange tokens som anslagsvis forbrukes, og hvilken AI-konto som blir belastet. Meldingen vises én gang, og fraværet koster brukerens tillit ved første overraskelse. Mønsteret er etablert i populære utviklerverktøy, slik som GitHub Copilot eller Cursor.
Nedgraderingsmodus i stedet for tomt loader-symbol
Nedgraderingsmodus håndterer 4 tilstander av token-potten. Full tilgang. Advarsel om lav saldo. Skrivebeskyttet modus der agenten leser data, men ikke genererer innhold. Deaktivert modus. Hver tilstand har sin egen brukermelding. Et tomt loader-symbol er ikke en akseptabel tilstand fordi en bruker uten kontekst tolker det som plattformsvikt.
Bring-your-own-key vs. abonnement vs. delt pott
Valg av faktureringsmodell påvirker 3 områder samtidig, nemlig installasjonsmeldingen, innstillingspanelet og prosedyren for hendelseshåndtering. Bring-your-own-key krever omhyggelig kundeonboarding. Abonnementsmodellen krever at plugin-utvikleren forhandler volum med AI-leverandøren. Modellen med delt pott krever overvåkning av misbruk. Plugin-utvikleren dokumenterer modellvalget i brukerdokumentasjonen, ikke kun i personvernerklæringen.
Hvordan et byrå bør forberede kundene
Et byrå som vedlikeholder mange kundenettsteder har 3 punkter å avklare med hver kunde før WordPress 7.0-utgivelsen. En kontraktsklausul om AI-tjenester. Et oppdateringsregime for plugins. Kommunikasjon av en hendelse etter at en token-grense er overskredet.
Kontraktsklausul om eksterne AI-tjenester
Klausulen består av 4 setninger. Kunden dekker token-kostnader hos eksterne AI-leverandører direkte. Byrået informerer kunden om hver ny AI-funksjon i vedlikeholdte plugins før aktivering. Kunden autoriserer aktiveringen skriftlig. Byrået overvåker forbruket og rapporterer avvik innen 48 timer. Mønsteret vokser ut av etablert WPPoland-erfaring med forretningskunder, der uventede eksterne kostnader skader relasjonen raskest.
Klausulen beskriver også en nødprosedyre i 2 trinn. Først, automatisk pause på agentforespørsler etter at en terskel definert med kunden er passert. Deretter, kontakt fra byrået med kunden i arbeidsmodus, nemlig e-post og telefon innenfor kundens arbeidstid. En udefinert terskel betyr i praksis at den første informasjonen om overskridelse når kunden først i fakturaen fra AI-leverandøren, noe som er den vanligste årsaken til tap av tillit i første kvartal av samarbeidet.
Oppdateringsregime, altså manuelt, automatisk eller etter gjennomgang
Kunden velger 1 av 3 plugin-oppdateringsregimer. Manuelle oppdateringer der byrået ruller ut en ny versjon etter testing. Automatiske oppdateringer med en daglig endringsrapport. Oppdateringer etter gjennomgang der byrået blokkerer innføringen av nye funksjoner inntil kunden godkjenner. Regimet etter gjennomgang beskytter kunden best i perioden med innføring av AI-funksjoner i plugins.
Hva som hører hjemme i briefingen for et nytt prosjekt
Briefingen for et nytt prosjekt inneholder 4 nye spørsmål sammenlignet med en briefing fra 2024. Først, om kunden aksepterer tilstedeværelse av AI-funksjoner i redaktørpanelet. Deretter, hvem som eier API-nøkler hos AI-leverandører. Videre, hvilket månedlig budsjett kunden setter av til tokens. Til slutt, hvilke brukerscenarier som ikke skal generere agentforespørsler. Disse 4 spørsmålene fyller gapene Automattic ikke lukket i visjonen sin.
Etter disse beslutningene kan et prosjekt trygt bruke MCP-infrastruktur, Abilities API og plugin-økosystemet. Operatøren kjenner kostnadene. Plugin-utvikleren kjenner begrensningene. AI-agenten har klart definerte grenser. Resten av WordPress sine styrker, slik som åpen kildekode og rik dokumentasjon, fungerer uten endring.
WPPoland fører denne samtalen med hver kunde siden mars 2026. Hele praksiskartet beskriver vi i slik gjør du nettstedet synlig for AI og LLM og i LLMO strategisk sammendrag. Synlighet for agenter er et eget tema, men fundamentet er det samme, nemlig forståelsen av hvor ansvaret for kostnaden av en spørring begynner og slutter.
