DEV Community: Aleksandr Argunov

CVE statistics from the raw CVE list: a Python count and a doubling ladder

Aleksandr Argunov — Fri, 30 Oct 2026 14:35:00 +0000

I counted the CVEs published each month, straight from the CVE Program's own list. Then I marked the first month above 750, then above each doubled level. Each crossing came faster than the last: 12 years, 7 years, 2 years, then 5 months.

September 2026 alone had 14,934 new CVEs. All of 2017 had 14,642. Below is the script that produces these numbers, in standard-library Python.

What gets counted

The source is the cvelistV5 release cve_2026-10-23_0400Z (release). Its asset 2026-10-23_all_CVEs_at_midnight.zip.zip holds 413,350 records.
Each PUBLISHED record counts in the month of cveMetadata.datePublished. That's when the record entered the CVE list (record format).
The 18,630 REJECTED records are left out.
2026 runs through October 22. Four records from early on October 23 are left out.

So this measures publication volume. It doesn't count new bugs. A record published today can describe a flaw found years ago.

The ladder

Level	First month above it	CVEs that month	Time since the last level
750	February 2005	821	Start
1,500	April 2017	1,568	12 years 2 months
3,000	March 2024	3,299	6 years 11 months
6,000	March 2026	6,236	2 years
12,000	August 2026	12,260	5 months

"Above" means strictly above. The gaps are between calendar months, with no interpolated crossing day.

The script

The asset is a zip with one zip inside, cves.zip. The script extracts that inner zip, about 710 MB, to a temporary folder. Then it reads every record.

# count_cves.py: published CVE records per month, from a cvelistV5 release asset.
# Usage: python3 count_cves.py ASSET.zip.zip [CUTOFF]
import collections
import json
import sys
import tempfile
import zipfile

asset = sys.argv[1]
cutoff = sys.argv[2] if len(sys.argv) > 2 else "9999"  # e.g. 2026-10-23 skips that day on

per_month = collections.Counter()
with tempfile.TemporaryDirectory() as tmp:
    # The asset is a zip with one zip inside. Extract the inner one first.
    with zipfile.ZipFile(asset) as outer:
        inner = outer.extract(outer.namelist()[0], tmp)
    with zipfile.ZipFile(inner) as records:
        for name in records.namelist():
            if not name.rsplit("/", 1)[-1].startswith("CVE-"):
                continue  # folders, delta.json and deltaLog.json
            meta = json.loads(records.read(name))["cveMetadata"]
            # ISO timestamps sort as text, so a string comparison works.
            if meta["state"] == "PUBLISHED" and meta["datePublished"] < cutoff:
                per_month[meta["datePublished"][:7]] += 1

for month, count in sorted(per_month.items()):
    print(month, count)

# The doubling ladder: the first month above each level, starting at 750.
level = 750
for month, count in sorted(per_month.items()):
    while count > level:
        print(f"Above {level:,}: {month} ({count:,})")
        level *= 2

Pass a cutoff date to leave out the snapshot day's own records:

python3 count_cves.py 2026-10-23_all_CVEs_at_midnight.zip.zip 2026-10-23 > counts.txt
grep '^2026-09 ' counts.txt                         # 2026-09 14934
awk '/^2026/ {s += $2} END {print s}' counts.txt    # 85838
tail -5 counts.txt

The last five lines are the ladder:

Above 750: 2005-02 (821)
Above 1,500: 2017-04 (1,568)
Above 3,000: 2024-03 (3,299)
Above 6,000: 2026-03 (6,236)
Above 12,000: 2026-08 (12,260)

Without the cutoff, October shows 13,040 instead of 13,036. The extra four are the October 23 records.

NVD keeps its own database. Its CVE API gives a quick cross-check for one month:

curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?pubStartDate=2026-09-01T00:00:00.000&pubEndDate=2026-09-30T23:59:59.999&noRejected&resultsPerPage=1' \
  | python3 -c 'import json, sys; print(json.load(sys.stdin)["totalResults"])'

On October 23 it returned 14,933 for September (query). In three months checked, NVD differed from the CVE list by zero to two records. Count all non-rejected records there, not just enriched ones.

Pin the snapshot when you compare numbers. Records get rejected later. The CVE Program has also corrected historical dates (README). So a later snapshot will differ a little.

How solid the pattern is

It depends on the starting level. I picked 750. Here are the gaps from other starts, same data:

Start	Gaps between first crossings
500	12y 6m, 3y 10m, 5y 10m, 2y 2m (16,000 not reached yet)
750	12y 2m, 6y 11m, 2y, 5m
800	13y 2m, 5y 11m, 2y 2m, 4m
900	10y 9m, 5y 9m, 2y 2m, 3m
1,000	3y 10m, 5y 10m, 2y 2m (16,000 not reached yet)

800 and 900 give roughly the same shape, with different timings. 500 and 1,000 break it: the climb that ends in 2018 is shorter than the one after it.

The date field matters too. Group the same records by dateReserved instead. The gaps become 11y 9m, 4y 2m, 4y 3m, then 1y 5m. The third step is no faster than the second.

A smoother check agrees on the direction. Twelve-month rolling totals first passed 5,000 in July 2005. Then 10,000 in June 2017, 20,000 in December 2021, 40,000 in January 2025 and 80,000 in September 2026. The gaps were 11.9, 4.5, 3.1 and 1.7 years.

So the ladder describes this list, counted this way. It's not a law. It doesn't say when 24,000 comes.

Why the count is rising

In June, FIRST raised its 2026 forecast to about 66,000 CVEs (FIRST). Its February median had been 59,427. It named AI-assisted discovery, changes in reporting, and CNAs working through backlogs. A CNA is an organization allowed to assign CVE IDs.

My count passed 66,000 on September 16. By October 22 it was at 85,838. October 1–22 added 13,036 CVEs. Keeping that daily average would put October near 18,400. That's an extrapolation.

AI is part of why. Google's threat intelligence team (GTIG) says AI is measurably changing how fast vulnerabilities are found (GTIG). Half its likely AI-found vulnerabilities could allow remote code execution. That compares with 26% in its non-AI group. That covers January to August 2026, and the AI label is GTIG's own heuristic.

Some of the rise is bookkeeping. Kernel.org became a CNA in February 2024 (CVE Program). Its policy leans toward assigning a CVE to fixes that could be security-relevant. That happens automatically once the fix reaches a stable tree (kernel.org). Not every commit gets one. GTIG counted about 5,000 CVEs from January to August whose descriptions mention the Linux kernel.

Backlogs come in bursts. When old findings get published together, the month spikes. That spike isn't new bugs.

This count can't say how much of the rise each cause explains.

What to patch first

Since April 15, NIST's NVD enriches three groups first (NIST). Those are CVEs in CISA's KEV catalog, software the federal government uses, and critical software under Executive Order 14028. They're categories, not a severity cutoff. Other CVEs stay listed, as "Lowest Priority - not scheduled for immediate enrichment." You can still request enrichment.

Only about 1 in 431 of this year's CVEs had been seen exploited by August. That's GTIG's figure: 0.23% of 2026 disclosures, January to August, by the exploitation it observed. It isn't a lifetime probability.

This part is my opinion. Finding bugs got cheap. Fixing them didn't. Patching everything is no longer a plan. That's no reason to skip routine updates. It's a reason to decide what comes first.

The public guidance supports an order like this:

Start with what you actually run. A CVE in a package you don't deploy isn't on your list.
Known exploitation first. CISA's KEV catalog lists vulnerabilities known to be exploited in the wild. Its JSON feed had 1,754 entries on October 21. It isn't complete.
EPSS for likelihood. FIRST's EPSS gives a probability from 0 to 1. It estimates observed exploitation in the wild over the next 30 days. Version 5 has run since June 15, 2026 (FIRST). Scores update daily. A score isn't the chance your system gets breached. A percentile isn't the probability. A low score never overrules known exploitation.
SSVC for context. CISA's SSVC is a decision tree. It weighs exploitation, technical impact, automatability, mission prevalence and public well-being. It ends in Track, Track*, Attend or Act. Even Track means fixing within your normal update cycle.
CVSS severity as one input. FIRST's CVSS v4.0 FAQ says base scores describe technical severity. They shouldn't set patch priority on their own.

The maintained article is on argbe.tech. It has the yearly totals since 1999, the chart as a video and every source.

What an AI agent harness does, in one short TypeScript loop

Aleksandr Argunov — Fri, 30 Oct 2026 14:30:00 +0000

What is an AI harness? It might be the most used and least explained term in AI right now.

Here's my short answer. The model writes text. The agent harness turns that text into actions.

A model can't open a file, run a command or click a button by itself. It generates output, and part of that output can ask for a tool. So when Claude Code fixes a failing test, the model never touches your code directly. It asks for the tests to run, and the harness runs them. The model's choices still change your files.

The four jobs

Lists the tools. It tells the model which tools it may use. Each tool has a name, a description and an input schema (Anthropic).
Catches the calls. It reads the tool calls in the model's response and dispatches them. Over the API, calls arrive as structured blocks. Nobody has to search the answer text for them (Anthropic).
Runs them. It checks that each call is allowed. Then it hands the call to the code that executes it. It can also say no (Agent SDK).
Returns the results. It feeds each result back to the model and loops. The run ends with a final answer. Or something else stops it: a limit, an error, a refusal or a cancel (Anthropic).

What a real tool call looks like

The tape in the animation says <bash cmd="npm test">. That's shorthand. It isn't Anthropic's or OpenAI's format. The model generates the request, and the API hands it to you as structured data.

Say your harness defines a tool called bash with a command input. On Anthropic's Messages API, the response then carries a tool_use block:

{
    "role": "assistant",
    "content": [
        {
            "type": "tool_use",
            "id": "toolu_01",
            "name": "bash",
            "input": { "command": "npm test" }
        }
    ],
    "stop_reason": "tool_use"
}

The ID is a placeholder. Thinking blocks and other fields are left out here. Your harness still sends them back.

The harness runs the command. It appends the assistant's whole content to the conversation. Then it adds a user message with a tool_result, matched by ID:

{
    "role": "user",
    "content": [
        {
            "type": "tool_result",
            "tool_use_id": "toolu_01",
            "content": "<what npm test printed>"
        }
    ]
}

Every call gets a result with its ID. Results come before any other text in that message (Anthropic). Then the harness sends the conversation again. When the model is done, stop_reason is end_turn (Messages API).

OpenAI's Responses API works the same way, with other names. A function_call item carries a call_id. Your harness answers with a function_call_output (OpenAI).

The loop

Here's the whole loop with Anthropic's client, @anthropic-ai/sdk. It has one harmless tool: a clock. It needs ANTHROPIC_API_KEY in the environment and runs as an ES module.

import Anthropic from '@anthropic-ai/sdk'

const client = new Anthropic() // reads ANTHROPIC_API_KEY

// Lists tools: what the model may ask for. One harmless tool here.
const tools: Anthropic.Tool[] = [
    {
        name: 'get_time',
        description: 'Get the current UTC date and time.',
        input_schema: { type: 'object', properties: {}, additionalProperties: false }
    }
]

// Runs code: only the names you handle can run.
function runTool(call: Anthropic.ToolUseBlock): Anthropic.ToolResultBlockParam {
    const input = call.input
    if (
        call.name !== 'get_time' ||
        input === null ||
        typeof input !== 'object' ||
        Array.isArray(input) ||
        Object.keys(input).length !== 0
    ) {
        return {
            type: 'tool_result',
            tool_use_id: call.id,
            content: 'Unknown tool or invalid arguments',
            is_error: true
        }
    }
    return { type: 'tool_result', tool_use_id: call.id, content: new Date().toISOString() }
}

async function runAgent(prompt: string): Promise<string> {
    const messages: Anthropic.MessageParam[] = [{ role: 'user', content: prompt }]

    for (let turn = 0; turn < 10; turn++) {
        const response = await client.messages.create({
            model: 'claude-opus-5-5',
            max_tokens: 16000,
            tools,
            messages
        })
        // Keep every block, thinking included, exactly as it came back.
        messages.push({ role: 'assistant', content: response.content })

        if (response.stop_reason === 'end_turn') {
            return response.content
                .flatMap((block) => (block.type === 'text' ? [block.text] : []))
                .join('')
        }
        if (response.stop_reason !== 'tool_use') {
            throw new Error(`Stopped: ${response.stop_reason}`)
        }
        // Catches calls: the tool_use blocks in the response.
        const calls = response.content.filter(
            (block): block is Anthropic.ToolUseBlock => block.type === 'tool_use'
        )
        // Returns results: one for each call, all in one user message.
        messages.push({ role: 'user', content: calls.map(runTool) })
    }
    throw new Error('Too many turns')
}

console.log(await runAgent('What time is it in UTC?'))

A few things matter here:

The whole content goes back. Claude Opus 5.5 always thinks (Anthropic). Its thinking blocks must go back unchanged. So the loop never rebuilds history from text (Anthropic).
It stops on anything unexpected. That covers max_tokens, refusal, and pause_turn if you add server tools. Text alone doesn't mean the job is done. The stop_reason says so (Anthropic).
There's no temperature. API version 2026-10-21 rejects it, along with top_p and top_k (Anthropic). The client sends that version by default (TypeScript SDK).
The turn cap bounds requests. It doesn't bound time or cost.

The loop follows Anthropic's documented request and response shapes. It type-checks in strict mode against @anthropic-ai/sdk 1.1.0. It also runs against a local mock of the API. It hasn't run against the live API.

Who runs the tool

Not every tool runs inside your harness. Anthropic separates client tools from server tools (Anthropic).

Client tools run in your application's environment. Your harness executes them. The clock above is one.
Server tools run on the provider's infrastructure. OpenAI's Code Interpreter is one example: OpenAI runs the code for you.
MCP tools run in an MCP server. The harness reaches them through an MCP client.

Where MCP fits

An MCP server offers tools, resources and prompts (MCP). It can run on your machine or on another one. A local server usually runs as a subprocess over stdio. A separately running server can use Streamable HTTP, remote or on localhost.

The host application runs one MCP client per server (MCP architecture). That client calls the server's tools and hands the results back to the loop. To the model, an MCP tool can look like any other tool. The harness still handles the protocol, the login and the rules.

In the animation, that's the GitHub call that leaves the plate. MCP is optional, though. The loop above uses none.

What production harnesses add

The clock loop lacks compaction, approval controls and a sandbox. Coding-agent harnesses can provide these:

Context. It decides what the model sees on each turn. The Claude Agent SDK compacts old history automatically near the context limit (Agent SDK).
Permissions and approvals. It decides which calls run alone and which wait for a person.
Sandboxing. It limits what a command can reach. Codex documents how it enforces sandbox and approval rules (OpenAI).

Adding a shell means adding those limits too. Approvals aren't a detail. My coding agent once opened a public tunnel without asking.

Two products show the same split between interface and harness.

Claude Code. Its terminal app is the interface. The agent runtime under it is the harness. Anthropic ships the same tools and agent loop as the Claude Agent SDK, for Python and TypeScript (Agent SDK overview). Anthropic calls it a harness too (Anthropic). The TypeScript package is @anthropic-ai/claude-agent-sdk (quickstart). The loop above uses the separate Messages API client.

Codex. OpenAI calls the shared loop behind the Codex CLI, IDE extension and apps "the Codex harness" (OpenAI, February 4, 2026). Clients reach it through the App Server. That's a long-running process with a two-way JSON-RPC protocol (App Server docs).

LLM + harness = agent

That's my shorthand. It's a teaching model, not a formal definition. Here, an agent is a model running in a harness. The harness manages context and tools. The model picks each next step. Anthropic draws a similar line between agents and fixed workflows (Anthropic).

My take: two "different" agents are often one model with different tools, instructions and MCP servers. OpenAI's Agents SDK builds an agent from those parts: instructions, a model and tools (OpenAI Agents SDK).

The maintained article is on argbe.tech. It has the animation as a video and every source.

Zaraz consent with your own prompt: the Consent API, Google Consent Mode and PostHog via Custom HTML

Aleksandr Argunov — Thu, 29 Oct 2026 14:01:00 +0000

Cloudflare Zaraz can run your consent without its own dialog. Set consent.hideModal: true, ask with your own UI, and record the answers with zaraz.consent.set(). Zaraz still decides which tools run.

That's how my site works now. I really like the new consent prompt. It asks two questions, one at a time, and a small bot reacts to each answer. I think it's a better solution than the general static forms most sites show.

Behind it: GA4, PostHog, Google Ads and Microsoft Advertising, all gated by Zaraz. The site is Astro 7 on Cloudflare Workers. The code below is a minimal, generic version of what runs there, and it says what it leaves out.

Why a prompt instead of a form

A static consent form shows everything at once: legal text, toggles, a row of buttons. The EDPB's cookie banner taskforce listed what goes wrong: no refusal on the first layer, pre-ticked boxes, misleading refusal links, colours and contrast that push one answer (report). My prompt:

Asks one question at a time, in plain words and in the page's language: "Can I see how you use the site?", then "Can ad platforms count visits that came from an ad?"
Shows No and Yes as the same button, same size, side by side, No first. Each question takes one click, so refusing everything takes two, the same as accepting everything. A Reject all banner does it in one. CNIL says refusing should be as easy as accepting (CNIL).
Is a non-modal card docked at the bottom. The page stays usable while it asks.
Has a bot that looks at No and Yes with the same interest while you decide and is never sad about a No. A Yes gets a smile, a No a calm face. At the end it waves if anything was allowed and nods if both answers were No.
Says what it saved and where to change it.
Keeps no consent of its own. Zaraz stays the only consent authority.

How Zaraz consent works

Zaraz is Cloudflare's third-party tool manager, on every plan (docs). Catalog tools run as Managed Components, and the browser loads a lightweight loader from your domain, /cdn-cgi/zaraz/i.js (manual loading). It isn't all server-side: a component can ask the browser to run JavaScript, make requests or set cookies (Managed Components).

Consent works by purpose (consent management):

You create purposes and assign each tool to one.
A tool waits until its purpose is granted.
A tool with no purpose skips consent checks. Adding a tool doesn't give it a consent requirement.
Choices live in a first-party cookie mapping purpose IDs to true or false. The cookie name is configurable; Cloudflare's example uses cf_consent.
By default, Zaraz shows its modal to anyone who hasn't chosen. consent.hideModal: true in the root consent object of the configuration stops that, and the Consent API keeps working (config schema).

The Consent API

All of it (Consent API):

zaraz.consent.APIReady // boolean, read-only
zaraz.consent.purposes // read-only: id, name, description, order
zaraz.consent.get(purposeId) // true, false, or undefined for an unknown purpose
zaraz.consent.getAll() // every purpose's state
zaraz.consent.set({ [purposeId]: true }) // updates only the purposes you pass; returns undefined
zaraz.consent.setAll(false) // updates every purpose
zaraz.consent.sendQueuedEvents() // sends pageview-based events withheld for lack of consent
zaraz.consent.modal = true // opens Zaraz's own modal

document.addEventListener('zarazConsentAPIReady', onReady)
document.addEventListener('zarazConsentChoicesUpdated', onChange)

Two things to know. The setters return undefined, not a receipt. And sendQueuedEvents() only sends the withheld pageview-based events. It isn't documented to replay zaraz.track() calls from before the answer.

A two-question prompt

The markup. transition:persist is Astro's; drop it elsewhere:

<!-- In the layout, so it's on every page -->
<section id="consent" aria-label="Privacy choices" hidden transition:persist>
    <div aria-live="polite">
        <p id="consent-text" tabindex="-1"></p>
        <p id="consent-detail"></p>
    </div>
    <p id="consent-error" role="alert"></p>
    <div id="consent-answers">
        <!-- One element and one class for both answers: No is never the smaller option -->
        <button type="button" class="consent-answer" data-answer="no">No</button>
        <button type="button" class="consent-answer" data-answer="yes">Yes</button>
    </div>
</section>

<!-- In the footer -->
<button type="button" data-privacy-preferences>Privacy preferences</button>

The script is one module, in four parts. Purpose IDs and two helpers:

const ANALYTICS = 'your-analytics-purpose-id'
const ADS = 'your-ads-purpose-id'
const COOKIE = 'cf_consent' // the consent cookie name in your Zaraz settings
const $ = (id) => document.getElementById(id)

function whenConsentReady(fn) {
    if (window.zaraz?.consent?.APIReady) fn()
    else document.addEventListener('zarazConsentAPIReady', fn, { once: true })
}

// Ask only when no choice is stored yet
function hasChoice() {
    return document.cookie.split(';').some((part) => part.trim().startsWith(`${COOKIE}=`))
}

Google Consent Mode v2

Zaraz supports Consent Mode v2 for GA4 and Google Ads (docs). Set denied defaults in the dashboard (Set Google Consent Mode v2 state) so they apply before tools load. Purposes don't map to Google's categories on their own, so send the stored choice yourself: when the API is ready, so a returning visitor's choice reaches Google, whenever the choice changes, and right after a save.

let lastGoogleState = ''

function syncGoogleConsent() {
    const all = zaraz.consent.getAll()
    const analytics = all[ANALYTICS] === true
    const ads = all[ADS] === true
    const state = {
        analytics_storage: analytics ? 'granted' : 'denied',
        ad_storage: ads ? 'granted' : 'denied',
        ad_user_data: ads ? 'granted' : 'denied',
        ad_personalization: 'denied' // this example's policy: no question covers personalized ads
    }
    const key = JSON.stringify(state)
    if (key === lastGoogleState) return // send only real changes
    lastGoogleState = key
    zaraz.set('google_consent_update', state)
}

Hardcoding ad_personalization to denied is this example's policy: neither question covers personalized ads. The Google state is a signal. The purpose gate is what stops a tool from running. You need both.

Asking and saving

Answers stay in memory until the second question, then go to Zaraz in one call. A failed save shows a message and keeps the last question open:

const QUESTIONS = [
    {
        purpose: ANALYTICS,
        text: 'Can I see how you use the site?',
        detail: 'Name the analytics tools and what they store.'
    },
    {
        purpose: ADS,
        text: 'Can ad platforms count visits that came from an ad?',
        detail: 'Name the ad platforms and what they store.'
    }
]
let step = 0
let answers = {}
let opener = null
let closeTimer = 0

function ask(index) {
    step = index
    $('consent-text').textContent = QUESTIONS[index].text
    $('consent-detail').textContent = QUESTIONS[index].detail
}

function openPrompt(byUser) {
    clearTimeout(closeTimer)
    answers = {}
    opener = byUser ? document.activeElement : null
    $('consent-error').textContent = ''
    $('consent-answers').hidden = false
    $('consent').hidden = false
    ask(0)
    if (byUser) $('consent-text').focus()
}

function save() {
    try {
        zaraz.consent.set(answers) // both answers in one call
    } catch {
        return false
    }
    syncGoogleConsent() // Google's state first, then the held-back pageviews
    if (Object.values(answers).includes(true)) zaraz.consent.sendQueuedEvents()
    return true
}

function answer(yes) {
    answers[QUESTIONS[step].purpose] = yes
    if (step < QUESTIONS.length - 1) return ask(step + 1)
    if (!save()) {
        // Nothing was recorded: say so, and let the last answer be given again
        $('consent-error').textContent = "Your choice wasn't saved. Please answer again."
        return
    }
    const hadFocus = $('consent').contains(document.activeElement)
    $('consent-text').textContent = 'Saved. Change it any time under Privacy preferences.'
    $('consent-detail').textContent = ''
    $('consent-error').textContent = ''
    $('consent-answers').hidden = true
    if (hadFocus) $('consent-text').focus()
    closeTimer = setTimeout(() => {
        const focusInside = $('consent').contains(document.activeElement)
        $('consent').hidden = true
        if (focusInside) (opener ?? document.querySelector('[data-privacy-preferences]'))?.focus()
    }, 2500)
}

Wiring it into Astro

// Astro runs a component's bundled script once per full page load, so these listeners never pile up
document.addEventListener('click', (event) => {
    const target =
        event.target instanceof Element &&
        event.target.closest('[data-answer], [data-privacy-preferences]')
    if (!target || !window.zaraz?.consent?.APIReady) return
    if (target.hasAttribute('data-privacy-preferences')) openPrompt(true)
    else answer(target.dataset.answer === 'yes')
})
// A change made anywhere, Zaraz's own modal included
document.addEventListener('zarazConsentChoicesUpdated', syncGoogleConsent)

// After the first load and after every client-side navigation
document.addEventListener('astro:page-load', () =>
    whenConsentReady(() => {
        syncGoogleConsent()
        if (!hasChoice() && $('consent').hidden) openPrompt(false)
    })
)

With <ClientRouter />, the document isn't replaced on navigation. astro:page-load fires after the first load and after each client-side navigation, and transition:persist keeps an open question on screen across one (view transitions). Outside Astro, run that callback once on load.

Left out: the bot and its animation, a summary naming what was turned on, and stepping aside while Zaraz's own modal is open, which only matters if that modal can still open. If Zaraz doesn't load, the prompt never appears and nothing optional runs.

Getting events to each tool

Consent and delivery are separate. A purpose decides whether a tool may run; a trigger and an action decide what it receives (triggers, actions).

Tool	Purpose	Set up in Zaraz	What it receives
GA4	Analytics	Catalog tool, with your measurement ID (`G-XXXXXXXXXX`)	Page views and events, through actions
PostHog	Analytics	Custom HTML tool with the loader below	The SDK's own capture calls
Google Ads	Advertising measurement	Catalog tool, with your Google Ads conversion ID	A pageview action
Microsoft Advertising	Advertising measurement	Catalog tool listed as Bing, with your UET tag ID	A pageview action

Page views come from Zaraz's built-in Pageview event: give each catalog tool a pageview action on the Pageview trigger. Don't mix up Pageview (Zaraz's event), zaraz.track('page_view') (a custom event you named) and the pageview action type. GA4 turns a pageview action into page_view; Bing turns it into pageLoad, and an event action into custom (Bing component).

A custom event goes through zaraz.track(name, props) with a flat props object (Track API). PostHog's SDK doesn't see that call, so capture it through PostHog's SDK too:

function track(name, props) {
    zaraz.track(name, props)
    if (zaraz.consent.get(ANALYTICS) === true) window.posthog?.capture(name, props)
}

track('signup_click', { location: 'header' })

Then a trigger matches it by name and an action on the tool maps the fields (create a trigger):

Trigger          Signup click
  Rule           {{ client.__zarazTrack }}  equals  signup_click

GA4 action
  Action type    Event
  Firing trigger Signup click
  Event name     signup_click
  Field          location = {{ client.location }}

{{ client.__zarazTrack }} is the event name and {{ client.location }} its location property (context). Match the name exactly: a hostname or path rule alone matches every event on the page.

GA4. Pass flat fields. The component adds the ep./epn. prefixes itself, so pre-prefixing risks doubles (request builder). Check two settings: originating-IP forwarding (hideOriginalIP) and ga-audiences. Audiences can make the browser call Google's ad endpoints (listeners).

Google Ads and Bing. With advertising consent they get a page signal, so a later lead can be tied to its ad click through gclid or msclkid. The Ads component can run its conversion linker on a pageview without sending a conversion (Ads component). The Bing component builds UET requests and sends them with client.fetch, from the browser. On my site, that page signal is all they get from browsing.

PostHog. It isn't in the Zaraz catalog (supported tools). I run it as a Custom HTML tool assigned to Analytics, so consent stays in one place. Custom HTML executes in the browser (source), so this is the regular JS SDK. Give the tool an action on the Pageview trigger, with this loader:

<script>
    ;(() => {
        // Zaraz can inject Custom HTML again on client-side pageviews: set up once, then only re-sync
        if (window.__posthogConsent) return window.__posthogConsent()

        const ANALYTICS = 'your-analytics-purpose-id'
        const allowed = () => window.zaraz?.consent?.get(ANALYTICS) === true

        // Paste only the first statement of PostHog's web snippet here, the minified
        // !function(...) bootstrap. Leave out its <script> tags and its posthog.init() call.

        let ready = false
        function sync() {
            if (!ready) return // loaded() runs the first sync
            if (allowed()) {
                if (!posthog.has_opted_in_capturing()) posthog.opt_in_capturing()
            } else {
                posthog.stopSessionRecording()
                posthog.opt_out_capturing()
            }
        }
        window.__posthogConsent = sync

        posthog.init('<project token>', {
            api_host: 'https://ph.example.com', // your first-party reverse proxy
            ui_host: 'https://eu.posthog.com',
            opt_out_capturing_by_default: true, // nothing is captured until sync() opts in
            before_send: (event) => (allowed() ? event : null), // check consent per event; null drops it
            loaded: () => {
                ready = true
                sync() // the choice can change while the SDK downloads
            }
        })

        document.addEventListener('zarazConsentChoicesUpdated', sync)
    })()
</script>

There's one posthog.init(), and the SDK starts opted out; loaded runs the first sync, and each change runs it again (config). before_send can edit or drop an event (usage). Withdrawal opts out and stops session recording, if you turned it on. No cookieless_mode here, so a No means no PostHog capture, not cookieless measurement. Pick persistence deliberately: memory isn't the cookieless mode. api_host points at your proxy and ui_host at the PostHog app (proxy); EU Cloud is hosted in Frankfurt (data storage). Zaraz's Ignore SPA option is the other way to stop repeat injection (FAQ).

Shipping Zaraz changes

Zaraz applies dashboard changes in real time by default. Turn on the Preview & Publish workflow and changes stage in a preview instead. zaraz.preview('<debug key>') in the console reloads the page with the debugger and the preview config (Preview & Publish). History lists versions with date, user and description; restore one, then publish it (versions). zaraz.debug('<debug key>') shows events, triggers and component requests, which tells you what Zaraz did, not what the vendor accepted (debug mode).

Cloudflare's official cf CLI, in open beta since 28 September 2026 (launch), wraps the Zaraz API (API):

# Find a command by describing the task
cf cli search "export zaraz configuration"

# "preview" stages changes; "realtime" publishes them at once
cf zaraz workflow get -z example.com

# The export contains secret values: keep it out of git, logs and chat
cf zaraz export get -z example.com > private/zaraz-export.json

# The versions you can restore
cf zaraz history list -z example.com

cf zaraz config update is a PUT of the whole configuration, not a patch, and it has --dry-run. cf zaraz publish create publishes the preview. cf zaraz history update restores a version by ID. Check the workflow first: in realtime, an update is live immediately. The CLI is a wrapper, not a safety net.

On my site, an agent prepares the Zaraz change set, I approve the exact diff before anything is written to Cloudflare, and then it's published.

Testing a change

In the preview, with no consent cookie:

Answers	Expect
None yet	No GA4, Google Ads, Bing or PostHog requests
No, No	Still none
Yes, No	GA4 and PostHog only
No, Yes	Google Ads and Bing only
Yes, Yes	All four

Repeat after a hard reload (the choice holds, no prompt) and a client-side navigation (nothing loads twice). Withdraw Analytics under Privacy preferences and check that GA4 and PostHog stop; grant it again and check that both resume.

The Zaraz debugger shows triggers, actions and component requests. The Network panel shows what the page sends itself, including PostHog's SDK, which the debugger doesn't cover. Each vendor's event view shows what arrived. On Google's requests, read the consent values in gcd, not just its presence.

What's still on you

The Zaraz loader and Consent API run before anyone answers. They have to, to record the first answer. "No JavaScript before consent" isn't true for this design.
With a custom prompt, its fairness is on you, not Cloudflare. The EDPB calls visuals that make one choice feel rewarding and the other guilty "emotional steering" (guidelines, written for social media interfaces).
After a yes, PostHog's SDK runs in the browser and Ads and Bing send requests from it. Masking in session recordings needs more than maskAllInputs (replay privacy).
Withdrawal stops future capture. It can't recall what was already sent.
Every new tool needs a purpose, or it skips consent.
Zaraz includes 1,000,000 events per account a month. Without paid usage, going past that turns Zaraz off until the next billing cycle (pricing).
If you need IAB TCF, Zaraz has an optional TCF-compliant modal (TCF). A two-question prompt isn't a TCF interface.
None of this is legal advice.

The maintained article, with the looping recording, every source and the last-checked date, is on argbe.tech.

Denial of wallet: what a hard budget cap actually stops

Aleksandr Argunov — Mon, 26 Oct 2026 14:11:00 +0000

Simon Willison wrote on 2026-10-03 that we need default hard budget caps on pretty much everything. I agree.

Firebase has spend caps for some services. But its docs say they can take several minutes to kick in. Whatever gets spent in that time is still your bill.

So you set a limit, but you're still not fully in control. That's terrifying.

What denial of wallet means

Denial of wallet is when someone runs up your usage on purpose, so that the bill breaks before the service does. OWASP lists it under unbounded consumption for LLM applications: attackers "exploit the cost-per-use model of cloud-based AI services." A retry loop or a misconfigured deployment can run up the same bill without any attacker.

OWASP's mitigations include rate limits, quotas and timeouts. They slow the spending down. A hard cap is what stops it, at a number you chose.

What I want from a cap

I think financial control should belong to the user. Let me set a real ceiling. Stop spending when I reach it. Let me choose automatic or manual top-ups.

When I see "spend cap", I expect a hard limit. Firebase's docs explicitly say otherwise: its spend caps "are not 'hard caps'", and anything spent during the delay is billed as normal. If a provider calls it a cap and enforces it late, I think the provider should cover the difference.

Agents make this even more important. They can help you deploy an app without explaining everything that can generate a bill. They can miss details and make mistakes too. Sometimes they act without asking, like the tunnel my coding agent opened to get files into Google Slides.

Simon goes a step further: an agent that recommends a cloud provider should prefer ones with hard caps and warn inexperienced builders away from the rest.

What providers actually stop

Checked on 2026-10-21. These controls change often, so read the linked docs before relying on one.

Control	What happens at the limit	What it doesn't cover
Firebase and Google Cloud spend caps	New usage of the capped service pauses for the rest of the month, after a delay that can be several minutes	Firebase: AI Logic, App Hosting, Cloud Functions and Extensions only, in Preview on the Blaze plan. Google Cloud: Gemini API, Agent Platform, Cloud Run and Cloud Run functions. Usage during the delay is billed, and fixed compute and storage keep billing
AWS project spend limits	A project's resources stop when its pre-tax monthly cost reaches the limit	Limited rollout, not every account. At most 10 projects, and the limit can't go below $20 or AWS's own estimate, whichever is higher. Data in a project left paused for 90 days is deleted
Vercel Spend Management	Production deployments pause, if you turn that option on. A budget on its own only notifies	Pro and eligible Enterprise teams. Usage is checked every few minutes, so charges can pass the threshold. AI Gateway, v0 and stored resources can keep billing
Supabase Spend Cap	Covered usage past the plan quota is blocked, and the docs say it isn't charged	Pro plan only. It follows the plan quota, not a dollar amount you pick. Compute, branching, read replicas and add-ons are excluded
Netlify credit-based plans	When credits run out, projects, deploys, requests and form submissions pause	Auto recharge keeps buying credits until you turn it off. Legacy plans work differently
OpenAI API spend limits	Requests get a 429 error once an organization or project limit is reached, if you choose enforcement instead of alerts	Enforcement isn't instant, and OpenAI says spend can slightly exceed the limit
Claude API spend limits	The Start, Build and Scale tiers each have a monthly cap that pauses API usage, and you can set lower limits per organization or workspace	The Custom tier has no monthly cap; limits are arranged with the account team. The default workspace can't have its own limit. Claude subscriptions and billing through cloud providers are separate
Cloudflare Workers Free	Worker requests past 100,000 a day get an error until midnight UTC, or skip the Worker if the route fails open	Other Cloudflare products have their own limits. Workers pricing lists a CPU limit per request for paid Workers, not an account-wide dollar cap

Several of these really do stop spending. Each one stops a defined set of things, though, and the right-hand column is where the bill can still grow.

What I chose for my own site

My site, argbe.tech, runs on a plan with no paid overage, and the parts that agents or the public can trigger have hard daily limits and an off switch. Choosing that means a flood shows up as errors and unavailability rather than a bill.

That lowers my cost exposure. It doesn't remove risk: the site can still be made unavailable or abused, and the caps don't cover everything.

If you're adding an agent to a business workflow, give everything it can trigger a hard limit and a way to switch it off.

Before you deploy

Check what your limit actually covers, what keeps billing after a shutdown, and how the provider handled past incidents. In more detail:

Scope. Write down the account, plan, project and services the limit applies to, and whether it's in preview, in a limited rollout or switched on at all.
Every billable line. List what can bill: seats, requests, compute, database reads and writes, storage, egress, logs, backups, AI tokens and third-party APIs. Match each one to its own control. A paused frontend doesn't stop an API key used somewhere else.
The action at the limit. An email, a webhook, a paused project and a rejected request are different things. A budget number on its own proves little.
The delay. Find out how long enforcement takes and what keeps running meanwhile. Set the cap below what you can afford to lose: a lower threshold buys headroom, not a guarantee.
Top-ups and resets. Check auto recharge, who can raise or remove the limit, and whether service comes back on its own next month.
What users see. Decide what happens at the limit: an error page, a queued order, a retry. Try it in a cheap test environment before real traffic finds it.
What keeps billing after a shutdown. Storage, fixed compute and subscriptions often continue. Check when paused data gets deleted: AWS deletes it after a project sits paused for 90 days.
Past incidents. Read how the provider handled earlier surprise bills in its own incident reports and refund terms, not in a thread about them.
If an agent deployed it. Ask for a list of everything it created and what each item bills for, then check that list against the provider's console.

A shorter version of this first appeared on LinkedIn on 2026-10-04. The maintained version, with every source and the date I last checked the provider limits, is on argbe.tech.

Affinity MCP vs code: why I make my thumbnails with a script

Aleksandr Argunov — Sat, 24 Oct 2026 22:00:00 +0000

Failing is hard. Especially when the tutorial is already recorded.

I wanted to show how an agent can make a good thumbnail with Affinity MCP. I tried it multiple times. It didn't work as expected.

Affinity's September 2026 update added in-app scripting and an AI Connector for Claude. Affinity's pitch is that you describe a process once, and Claude builds a reusable script. I connected it to Claude Code as an MCP server and asked for a finished thumbnail.

Using Sonnet 5.5 with high reasoning was better. Opus 5.5 on xHigh was just thinking the whole time, so slow that I even cancelled it.

The prompt

Here is the prompt I used.

Create an exceptional, finished, polished 1920 × 1080 LinkedIn video thumbnail in Affinity through MCP. Aim for award-winning, résumé-showreel quality. Go all out.

Create assets with codex imagen. You can reimagine my pose and restyle myself as needed, angle, camera, appearance. But make me look happy and smiling. And look at the user. Create the new asset together with details for max conversions. But keep in mind to request transparent background.

For other details use programmatic approach to make the scene complete.

Headline: "I hate making thumbnails."
Subtitle: "Made with Claude Code + Affinity MCP"
Subtle branding: favicon + "argbe.tech".

Add requirements graph.

- Affinity Studio
- Affinity MCP enabled
- Claude Code Affinity MCP enabled

You have 5 minutes. Fix obvious issues only; skip minor adjustments.

Code first

I was so exhausted with the Affinity approach that I just tried code first. Same prompt, only the copy updated. And it worked much better.

Code first means Claude Code writes a small Node script that builds the whole thumbnail as one SVG: the background, the headline, the branding and the photo of me as an embedded image. A command-line renderer then turns the SVG into a PNG. When I need extra assets, I create them with ChatGPT Image.

A shortened version of the script from that run:

import fs from 'node:fs'
import { execSync } from 'node:child_process'

const cut = fs.existsSync('code-only/assets/alex-point.png')
    ? 'code-only/assets/alex-point.png'
    : 'assets/alex-cutout.png'
const img = fs.readFileSync(cut).toString('base64')

const svg = `<svg width="1920" height="1080" viewBox="0 0 1920 1080"
  xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <rect width="1920" height="1080" fill="#100C24"/>
  <image x="950" y="10" width="1120" height="1120"
    xlink:href="data:image/png;base64,${img}"/>
  <text x="84" y="536" font-family="Helvetica Neue, Arial, sans-serif"
    font-weight="800" font-size="196" fill="#fff">thumbnails.</text>
  <!-- glows, grid, the rest of the headline, subtitle, favicon and "argbe.tech" -->
</svg>`

fs.writeFileSync('code-only/scene.svg', svg)
execSync(
    'rsvg-convert -w 1920 -h 1080 code-only/scene.svg -o code-only/thumbnail-code-only-1920x1080.png'
)

The script is text. Claude Code can read all of it, change one coordinate, run it again and get the same image every time.

The link previews on my site come from code too: a script renders one for each page when the site builds. If your product needs images like that, it's a small piece of software, not a design job.

What I noted

Affinity MCP took twelve prompts and seventeen minutes of active work. Code only took six prompts and three minutes fifty-four seconds.

Those are my notes from these sessions, not a benchmark. The copy changed between the runs, and I tried more than one model on the Affinity side.

The result is better than the original one. It finally generated me from a different angle. The proportions are still off. But at least it was fast.

YouTube got there first

I hate making thumbnails. But we are almost at the point where they are created automatically.

When I first posted this, I predicted YouTube would soon offer it as a feature. It already had. On 2026-09-23, two weeks before my post, YouTube announced that creators can generate channel-matched thumbnails, and that Ask Studio can review older videos and suggest and test refreshed thumbnails. The announcement doesn't say who gets these features or when.

A shorter version of this first appeared on LinkedIn on 2026-10-07. The maintained version, with every source and the date I last checked them, is on argbe.tech.

JavaScript number precision for large IDs, and ten new features for agent code

Aleksandr Argunov — Sat, 24 Oct 2026 13:07:00 +0000

A long numeric ID can come out of JSON.parse as a different number, and nothing throws.

const text = '{"id":1234567890123456789}'
const { id } = JSON.parse(text)
BigInt(id) // 1234567890123456768n
JSON.stringify({ id }) // '{"id":1234567890123456800}'

JavaScript numbers are 64-bit floats. Every whole number up to 9,007,199,254,740,991 (Number.MAX_SAFE_INTEGER) is exact. Above that, only some whole numbers fit, and among 19-digit numbers they're 128 to 2,048 apart. JSON.parse rounds the ID to the nearest one that fits (MDN, ECMA-262).

So the ID changes twice. Parsing rounds it, which BigInt(id) shows: the original digits are gone, and no conversion brings them back. Then JSON.stringify writes the fewest digits that identify the float and fills the rest with zeros (ECMA-262). Even an ID that fits exactly can change that second way. Whatever reads the text next, the model or another API, gets a different ID.

Which APIs send long IDs

LinkedIn, X and Discord IDs can run to 19 digits. X and Discord send them as strings (X, Discord). Discord’s docs say why: its IDs are up to 64 bits, which would overflow as numbers in some languages. At 64 bits, an ID can even reach 20 digits. LinkedIn’s API uses strings as well, both for plain IDs and for URNs like urn:li:share:1234 (LinkedIn).

In March, a bug report against Claude Code (#37707) said its official Discord plugin turned channel IDs into numbers, and fetching messages failed. It was closed for inactivity on 20 April, so it neither confirms the cause nor shows a fix.

So keep IDs as strings end to end: in your types, your schemas and the text you hand the model. The same goes for any integration that passes records between two systems, not only agent tools.

When an API sends numbers anyway

JavaScript now has a fix. A JSON.parse reviver gets a third argument with each number’s original source text:

const text = '{"id":1234567890123456789}'
const data = JSON.parse(text, (key, value, { source }) =>
    key === 'id' && typeof value === 'number' ? source : value
)
data.id // '1234567890123456789'

Three limits (MDN):

It needs the raw response text. If an SDK has already parsed the response, a large ID may already be rounded, and BigInt() on that number returns the rounded value, not the ID.
Match the ID fields your schema names, not every number, and check the string against your ID format. JSON numbers can also be fractions or exponents like 1e21.
It needs Chrome 114, Firefox 135, Safari 18.4 or Node 21 and later (compat data). On older runtimes the third argument is missing, and this callback throws.

This source-text reviver is the first of ten new features that shorten agent code. Five are in the language now, two are finished and expected in ES2027, and three are still proposals. Versions below are the first releases that support each feature, from MDN’s compatibility data.

Ships now: ES2025 and ES2026

1. Numeric IDs from other APIs

JSON.parse source text · ES2026 · Chrome 114, Firefox 135, Safari 18.4, Node 21 (compat data).

Before: JSON.parse(text), with the problem above. After: the reviver above.

2. Images for a model API

Uint8Array.prototype.toBase64() · ES2026 · Chrome 140, Firefox 133, Safari 18.2, Node 25 (compat data).

Before, which can hit the engine’s argument limit on large images:

// bytes: Uint8Array
const base64 = btoa(String.fromCharCode(...bytes))

After:

const base64 = bytes.toBase64()

3. State per agent run

Map.prototype.getOrInsert() · ES2026 · Chrome 145, Firefox 144, Safari 26.2, Node 26 (compat data).

Before:

// runs: Map<string, string[]>
if (!runs.has(id)) runs.set(id, [])
runs.get(id).push(step)

After:

runs.getOrInsert(id, []).push(step)

4. Missing permissions

Set.prototype.difference() · ES2025 · Chrome 122, Firefox 127, Safari 17, Node 22 (compat data).

Before:

// needed, granted: Set<string>
const missing = new Set([...needed].filter((s) => !granted.has(s)))

After:

const missing = needed.difference(granted)

It finds what’s missing. Granting it is still your code’s decision.

5. Model text inside a regex

RegExp.escape() · ES2025 · Chrome 136, Firefox 134, Safari 18.2, Node 24 (compat data).

Before: a copied escape pattern, or none.

const text = '$4.99+tax?' // from the model
new RegExp(text).test('Total: $4.99+tax?') // false

After:

new RegExp(RegExp.escape(text)).test('Total: $4.99+tax?') // true

Finished, expected in ES2027

Both are finished proposals at Stage 4, due in the 2027 edition (TC39). Stable Safari doesn’t have them yet, only Safari Technology Preview.

6. Closing the browser when a tool call throws

await using · Chrome 134, Firefox 141, Node 24 (compat data).

Before:

const browser = await chromium.launch()
try {
    await runTool(browser)
} finally {
    await browser.close()
}

After:

await using browser = await chromium.launch()
await runTool(browser)

Why: miss the finally, and a failed browser task can leave Chromium running on your server. Playwright’s browser closes itself when the scope exits, even on a throw (Playwright).

7. Dates across time zones

Temporal.ZonedDateTime.prototype.add() · Chrome 144, Firefox 139, Node 26 (compat data).

Before:

// t: epoch milliseconds for 15:00 on 21 October 2026 in Berlin
const due = new Date(t + 7 * 864e5) // 14:00 on 28 October in Berlin

After:

const start = Temporal.ZonedDateTime.from('2026-10-21T15:00[Europe/Berlin]')
const due = start.add({ days: 7 }) // 2026-10-28T15:00:00+01:00[Europe/Berlin]

Seven days of milliseconds is 168 hours, and Berlin’s clocks go back on 25 October, so 3pm becomes 2pm. Temporal adds calendar days and keeps 3pm (tz database).

Still proposals

These can still change. Some browsers already ship two of them.

8. Parallel tool calls

Promise.allKeyed · Stage 3 · Firefox 155; not yet in Chrome, Safari or Node (compat data).

Before, with results matched by position:

const [user, orders] = await Promise.all([getUser(id), getOrders(id)])

After, with results by name:

const { user, orders } = await Promise.allKeyed({
    user: getUser(id),
    orders: getOrders(id)
})

Why: add a tool call to Promise.all, miss the destructuring, and results land in the wrong variables. How parallel calls to one API share a connection is a separate question, covered in which web standard fits which job.

9. Prompts as files

Import Text · Stage 3 · Chrome 155, Firefox 153, Bun 1.1.5, Deno 2.8; not yet in Safari or Node (compat data).

Before:

import { readFileSync } from 'node:fs'

const prompt = readFileSync(new URL('./prompt.md', import.meta.url), 'utf8')

After:

import prompt from './prompt.md' with { type: 'text' }

10. One trace per agent run

AsyncContext · Stage 2, the least mature of the three.

Before: a runId passed through every call, or Node’s AsyncLocalStorage.

import { AsyncLocalStorage } from 'node:async_hooks'

const runId = new AsyncLocalStorage()
runId.run(id, () => agent.start())
// anywhere deeper: log(runId.getStore(), message)

After: AsyncContext, the same idea, meant for every runtime.

const runId = new AsyncContext.Variable()
runId.run(id, () => agent.start())
// anywhere deeper: log(runId.get(), message)

Why: without a run ID on each log line, you can’t tell which run failed. For now it’s a direction to watch, not something to ship.

Runtimes and types

Node 26 runs features 1 to 7 and is scheduled to become LTS on 28 October 2026 (Node.js). Safari has 6 and 7 only in Technology Preview. TypeScript 7.1 beta, announced on 20 October, adds the ES2026 types (TypeScript). Set TypeScript’s lib to what your runtime has, not higher: the types don’t add the features.

Then write your runtime and preferred APIs into CLAUDE.md or AGENTS.md, so your coding agent knows them:

## Runtime

- Node 26. Use Map.prototype.getOrInsert, Set methods, RegExp.escape and Temporal.
- Keep IDs from external APIs as strings.

I first posted this on LinkedIn on 21 October 2026. The maintained version, with every source and the date I last checked the support data, is on argbe.tech.

WebMCP vs MCP: when an agent should go through the browser

Aleksandr Argunov — Fri, 23 Oct 2026 13:47:00 +0000

I've built a few WebMCP integrations, and I'm still not sure about it.

The short version: WebMCP only makes sense to me when the agent is part of the browser, where you can watch and step in. When you work through chat, it feels unnatural. Why keep a browser involved when the agent can call the service directly? For a chat app, a desktop client, code or a job nobody watches, build a direct MCP connection. Shopify draws roughly the same line for its checkout.

WebMCP, browser-control tools and server MCP

WebMCP is a proposed web standard. The page registers tools, and the browser's built-in agent calls them, so the agent doesn't have to guess what a button does. Chrome runs it as an origin trial from Chrome 149, with a flag for local development, and says the API may still change.

Browser-control MCP tools are MCP servers that operate a browser by clicking and typing. The site declares nothing, so the agent reads the page and works out what each element is for. Chrome calls this actuation and describes WebMCP as the more reliable option.

Server MCP means the service exposes its own tools, for example over MCP's Streamable HTTP transport, which streams with SSE. No browser is involved. An MCP client such as ChatGPT Desktop or Claude Code calls the service directly, from a chat or from code.

Chrome's own comparison is clear that WebMCP doesn't replace MCP. WebMCP tools exist only while the page is open. An MCP server is there whenever a client calls it.

What I found building both

The latest WebMCP integration I built let agents work on screenplay projects in a video web service, using the interface and the functions behind it.

It worked. But I ended up replacing it with a direct MCP connection. I could control projects from ChatGPT Desktop or Claude Code without keeping the web interface in the loop. In my workflow, I found it faster, and it used fewer tokens. Without the browser, it was also much easier to build automated agent workflows in code. I haven't gone back to the WebMCP version.

The automation part follows from the design: code can reach WebMCP tools only through a browser that has the page loaded. A server MCP has no page to keep open.

Shopify checkout: two ways in

Shopify added WebMCP support to checkout on 2026-09-28. Browser agents can now read and update eligible checkouts, and submit them once the buyer confirms. Shopify's docs describe this and a server option side by side.

Checkout WebMCP works on the checkout open in the buyer's tab. It registers get_checkout, update_checkout and complete_checkout, plus navigate_to_storefront when the store has an online storefront. Before calling complete_checkout, the agent has to show the buyer the order and total and get their permission. Shop Pay login and payment challenges stay with the buyer, on the page. (Checkout WebMCP reference)

The tools only appear on eligible checkouts. Shopify lists the exceptions: B2B checkouts, embedded and mobile-SDK checkouts, checkouts with another shop's merchandise, draft orders, order edits, payment collection, and the standard three-page checkout unless the buyer uses Shop Pay. update_checkout also leaves line items alone; the buyer changes those on the page. If you build on Shopify, check that list against your store's checkout before planning around WebMCP.

Checkout MCP runs from your agent's server and doesn't depend on the buyer's browser. It's a JSON-RPC endpoint at https://{shop-domain}/api/ucp/mcp, and every request needs authentication or a signed request. When the buyer has to enter something or review the order, the agent hands them a checkout link to finish there. (Checkout MCP reference)

Shopify's docs recommend Checkout MCP unless the agent has to run in the buyer's browser. Either way, the buyer still approves the purchase.

Where this is heading

Long term, I think agent-native will become the standard. The UI, WebMCP and direct MCP should all work with the same underlying logic and state. People and agents can then use whichever interface fits, without rebuilding the workflow for each one.

Looks like Shopify is going this way too. Its WebMCP tools use the same state as the checkout UI, and both MCP options use the same checkout object. That's the direction I'm most interested in.

A shorter version of this first appeared on LinkedIn on 2026-09-30. The maintained version, with the date I last checked Chrome's and Shopify's docs, is on argbe.tech.

SSE vs WebSockets for AI apps: ten web standards and two patterns

Aleksandr Argunov — Thu, 22 Oct 2026 13:21:00 +0000

Out of the box, the official OpenAI and Anthropic Python SDKs talk HTTP/1.1, a protocol from 1997 (RFC 2068). Both build on HTTPX2, which leaves HTTP/2 off unless you turn it on (OpenAI SDK, Anthropic SDK, HTTPX2).

Streaming answers? When they stream over HTTP, both APIs use Server-Sent Events, a W3C standard since 2015 (OpenAI, Anthropic, W3C). Live voice? OpenAI recommends WebRTC for browser and mobile clients (OpenAI). Even MCP’s Streamable HTTP transport, which remote MCP servers use, sends HTTP POST requests, with SSE for streaming. Since the 2026-07-28 revision, each POST gets back either JSON or its own SSE stream, and the old always-open GET stream is gone (MCP).

Here are ten web standards and two patterns, with what each is good for in AI and where it falls short. Years mark standardization, not adoption. They don’t all compete: some are HTTP versions, others are transports, browser APIs or an authentication scheme, and several stack. HTTP/3 runs on QUIC (RFC 9114), and SSE works over any HTTP version.

SSE or WebSockets?

If only the server talks while an answer streams, SSE is often enough. Reach for WebSockets when both sides talk at once.

Feature	SSE	WebSocket
Direction	Server to client	Both ways
Data	UTF-8 text	Text and binary frames
Runs over	An ordinary HTTP response	Its own protocol, after an HTTP upgrade
Use it for	Streamed answers, progress, notifications	Live sessions where both sides talk
Standardized	WHATWG HTML, W3C since 2015	RFC 6455, in 2011

With SSE, the client still talks back, just with separate HTTP requests. Binary data has to be encoded as text first.

Pick by job

You need to	Start with	Spec
Make one API or tool call at a time	HTTP/1.1 is fine	RFC 9112
Stream a model’s answer, progress or notifications	SSE	WHATWG HTML
Run a live session where both sides talk	WebSocket	RFC 6455
Add live voice or camera from a browser or phone	WebRTC	W3C
Make several API or tool calls at once to one origin	HTTP/2, or HTTP/3 on lossy networks	RFC 9113, RFC 9114
Run a complex read-only search with a body	HTTP QUERY, once every hop supports it	RFC 10008
Mix must-arrive results with droppable live updates	WebTransport	W3C CR
Show a site which agent is calling	Web Bot Auth	IETF draft
Follow a long job	Polling, or a webhook to your server	MCP Tasks, OpenAI

Established

HTTP/1.1

1997 · Simple requests and responses, first specified in RFC 2068. RFC 9112 is the current version.

Good for: single API calls and tool calls.
Falls short: no multiplexing. Parallel requests usually need several connections, and pipelined responses still come back in order.

WebSocket

2011 · A two-way connection kept open, carrying text or binary frames (RFC 6455).

Good for: live sessions where both sides talk, like server-side voice agents.
Falls short: for one-way text streaming, SSE is often enough.

SSE

2015 · Text pushed from server to client over HTTP (WHATWG HTML).

Good for: streamed answers, progress updates and notifications.
Falls short: no binary messages, and no two-way traffic on the same stream.

HTTP/2

2015, updated 2022 · Many streams over one TCP connection. RFC 9113 replaced the original RFC 7540.

Good for: an agent making several API or tool calls at once to the same origin. Native gRPC uses it (gRPC).
Falls short: one lost TCP packet can delay every stream on that connection.

QUIC

2021 · Encrypted transport over UDP with independent streams (RFC 9000).

Good for: a connection can survive a device changing networks, if the server allows it (§9). A lost packet holds up only the streams with data in it, which can be several, while the rest keep going (§13).
Falls short: some networks block UDP. Fallback is up to the app (RFC 9114).

WebRTC

2021 · Real-time audio, video and data. It first became a W3C Recommendation in January 2021.

Good for: live voice and camera with a model, from a browser or phone.
Falls short: often unnecessary for text. It needs connection setup, and maybe a relay server.

HTTP/3

2022 · HTTP over QUIC instead of TCP (RFC 9114).

Good for: it can cut setup time and cross-stream delays on lossy networks.
Falls short: making the model faster.

New standard

HTTP QUERY

June 2026 · Like GET, but with a request body. It’s safe and idempotent (RFC 10008).

Good for: complex read-only searches like AI retrieval, with safe retries and caching where supported.
Falls short: relying on it before your whole stack supports it: client, CDN, proxies and server.

Still developing

WebTransport

W3C Candidate Recommendation · Reliable streams plus droppable datagrams. Major browsers have shipped it since March 2026; older ones and embedded webviews need a check (MDN).

Good for: results that must arrive next to live updates that can go stale.
Falls short: code that can’t absorb changes. The IETF protocol is still a draft (IETF).

Web Bot Auth

IETF draft · Signed requests that show a site which agent is calling.

Good for: telling real agents from bots posing as them. Cloudflare already checks these signatures (Cloudflare).
Falls short: deciding what an agent may do. It proves identity, not permission.

Patterns, not protocols

Polling

Asking the server again and again whether something changed.

Good for: long AI jobs where checking every few seconds is fine, like MCP tasks. Where client and server support the Tasks extension, each job gets a handle to poll, and a client can pick it up again after reconnecting.
Falls short: live updates. You either waste requests or lag behind.

Webhooks

An HTTP request a service sends you when something happens.

Good for: telling your system that a batch run or agent task has finished. OpenAI, for one, sends them for batch and background jobs (OpenAI).
Falls short: they can’t reach a browser tab directly. Receiving them is a small integration of its own: a server that verifies signatures, handles duplicate deliveries and passes the event on.

I first shared this list on LinkedIn on 20 October 2026. The maintained version, with the animated diagram, every source and the date I last checked them, is on argbe.tech.

AI-generated unit tests: two patterns that pass with the bug, and a red-green fix

Aleksandr Argunov — Thu, 22 Oct 2026 08:49:54 +0000

Two tests can pass while applyDiscount(100) returns 100 instead of the ticket's 90. One replaces the function with a mock. The other copies its boundary bug into the expected value.

Agents love to create a thousand unit tests. All green. Then review smashes the whole thing.

The agent already implemented a trash solution, and only then wrote generalized unit tests for it. Those tests describe the code it just wrote. So they all pass, bugs included.

When an agent writes both the code and its tests, don't count the green checks. Look at where each expected value comes from. If it comes from the agent's code, the test can repeat the agent's mistake instead of catching it. If it comes from the ticket, the spec or a real example, and the test runs the real code and failed because the behavior was missing, it checks something.

Two patterns that pass with the bug

Here are both in TypeScript with Vitest. Suppose an agent writes this for a discount ticket:

// pricing.ts. The ticket: orders of 100 or more get 10% off.
export function applyDiscount(total: number): number {
    return total > 100 ? total * 0.9 : total // bug: should be >=
}

A test that mocks the function it's supposed to test:

// mocked.test.ts
import { expect, it, vi } from 'vitest'
import { applyDiscount } from './pricing'

vi.mock('./pricing', () => ({ applyDiscount: () => 90 }))

it('gives 10% off at 100', () => {
    expect(applyDiscount(100)).toBe(90) // checks the mock, not the code
})

A test that calculates the expected value with the code's formula:

// same-formula.test.ts
import { expect, it } from 'vitest'
import { applyDiscount } from './pricing'

it('applies the discount', () => {
    const total = 100
    // the code's own formula, bug included
    const expected = total > 100 ? total * 0.9 : total
    expect(applyDiscount(total)).toBe(expected)
})

Both pass, and the code still charges 100 for an order of exactly 100. With the mock, the real applyDiscount never runs. Mocking a dependency, like a payment service, is a different and legitimate use (Software Engineering at Google). Copying the formula copies the bug. Google's testing blog shows the same trap in Don't Put Logic in Tests.

Researchers have measured a version of this. In a July 2026 study, 11 models in 13 model and mode setups wrote tests for 318 Java methods behind 233 real bugs. Averaged across those setups, 3.84% of the tests written from the buggy code passed on the bug and failed on the fix. Written from the fixed code, 0.46% did (Zhao, Zhou and Cohen).

More tests don't fix it

In a study first posted in February 2026 on 500 SWE-bench Verified tasks, pushing agents to write more tests barely changed how many they solved (Chen et al.). GPT-5.2 solved 359 tasks either way, and Gemini 3 Pro Preview went from 371 to 366. Telling Kimi K2 Thinking and DeepSeek v3.2 Reasoner not to write tests moved them from 317 to 304 and from 300 to 291. None of these changes was statistically significant.

The cost depended on the model: GPT-5.2 made more API calls and used more tokens without solving more, and the two models told to skip tests used fewer (results). It's one benchmark and one agent scaffold, mini-SWE-agent, and the study didn't test TDD or the workflow below.

Red and green slices, then review

In my experience, TDD with small red and green slices, and reviewers after, works much better:

Define what done means, in a way that can fail.
Take the expected values from something the agent didn't write: the ticket, the spec, a real example.
Write one failing test (red). It has to fail because the behavior is missing.
Write only enough code to pass it (green).
Next slice. Reviewers come in after green.

For the discount, the test takes its expected value straight from the ticket:

// spec.test.ts
import { expect, it } from 'vitest'
import { applyDiscount } from './pricing'

// From the ticket: an order of exactly 100 pays 90.
it('gives 10% off an order of exactly 100', () => {
    expect(applyDiscount(100)).toBe(90)
})

Run against the agent's code, it fails red with expected 100 to be 90. Change > to >= and it goes green. The mock test still passes, because it never ran the code. The formula test now fails: it was guarding the bug. Checked with Vitest 4.1.12: save the four blocks under their file names and run npx vitest run.

Matt Pocock's /tdd skill is his version of this workflow. One slice at a time, and writing all the tests up front is an anti-pattern there. Refactoring belongs to review. That part is a choice: Kent Beck's Canon TDD lets you refactor inside each cycle, after green.

Lauren Tan (poteto), the author of pstack, builds step 1 into it. Its /figure-it-out skill asks the agent to state what done means, in a way that can fail, before it starts the run.

TDD and /figure-it-out can work magic when you understand what you are doing.

What each check covers

Even good unit tests are one row of this chart. Here's what every row covers. The When column is my rough rhythm, not a rule.

Check	When	What it covers	Source
Unit	Every edit	A small unit of behavior, run fast. The unit can be one function or a few that work together.	Fowler
Mocks	In unit tests and narrow integration tests	Stand-ins for real collaborators, like a payment service. A mock also checks how it was called.	Fowler
Smoke	Every build	Does it start, and do the critical basics work, before deeper testing?	ISTQB
Integration	Every PR	Do separately built parts work together once connected?	Fowler
Regression	Every PR	Did the change break something that used to work? Unit, integration and end-to-end tests can all do this job.	ISTQB
Review	After green	Someone other than the author reads the change: a person or a review model.	Google, GitHub
End-to-end	Before release	A whole user flow, start to finish, in production-like conditions.	ISTQB
Security	Throughout development	Whether the security controls hold. "Can someone get what isn't theirs?" is one question of many.	OWASP, framework
Mutation	Rarely	Change the code on purpose and see whether any test fails. A surviving change isn't always a real bug.	Stryker
Manual	By a human	A person uses the product and checks that it behaves as expected.	Atlassian

The maintained article, with the animated chart, source links and the last-checked date, is on argbe.tech.

AI coding security: the tunnel my agent opened without asking

Aleksandr Argunov — Wed, 21 Oct 2026 12:45:02 +0000

In October 2026, Claude Code opened a Cloudflare tunnel on my machine. The Google Slides connector couldn't import my media files, so the agent put them on a public URL and let Google fetch them from there.

It was a smart workaround, and it didn't ask for approval or warn me. The command just went by in its output, and I only caught it because I was reading along. While it ran, anyone with that link could reach those files on my machine.

That was one session, with my settings. But most people won't be reading along.

Why the agent wanted a public URL

Google's Slides API inserts an image from a URL only if the URL is publicly accessible. It fetches the image once, at insertion, and keeps its own copy. So the files only had to be public while Google fetched them.

A tunnel is a quick way to get a public URL. Cloudflare's quick tunnels give a local service a temporary address, and by default anyone with that address can reach the service until the cloudflared process stops.

The workaround wasn't the problem. Doing it without asking was. Files only my machine could read became reachable from the internet, and the only notice was a line in the output.

What to check before an agent can expose anything

Make the agent ask before anything that opens your machine. Tunnels, port forwarding, public share links and public buckets all turn something private into something reachable.
Keep exposure as short as the job. If a service needs to fetch a file once, the tunnel can close right after; stopping cloudflared ends access for everyone.
Before an agent connects your email, files or calendar to an MCP server, check who wrote the server and what it can reach. MCP's security best practices describe the authorization risks to look for.

Agents in a business workflow need the same rule: a person approves anything that matters.

Software isn't only prototyping

Prototyping slop is solved. Pieter Levels calls it "software is dead."

He's right that prototyping got cheap. But software isn't only prototyping. It takes time, effort, money and users before one approach is good enough for many people to reuse.

One developer has been publishing the Craft apps, an early-alpha suite for image editing, documents, slides and more, each written from scratch in Rust. Even one of them, PhotoCraft, stands on hundreds of open source libraries: its lockfile on 20 October listed 839 packages, counting its own crates and everything they pull in, and 803 of them came from crates.io. I don't think what a chatbot builds for you usually gets that far.

I think most people will just ask for something and let the agent in the chat handle it. Chat apps can already connect to files, email and calendars. For a lot of people the chat will be the only UI they use. They're about to own software and not know it.

Whose responsibility it is

Now picture your agent wiring your email to an MCP server some stranger wrote. A June 2026 TrendAI study found confirmed security issues in 2,259 of 9,695 MCP servers, even after setting aside the ones flagged only for missing authentication. The servers came from public MCP directories crawled between November 2025 and March 2026.

If that server leaks your inbox, that's on you. You connected it, even if the agent did it for you and you never noticed. It's the same thing as my tunnel, just with nobody reading the output.

By "on you" I mean responsibility, not legal liability: someone has to know what's connected and what it can reach. Who is liable after a leak is a legal question. It depends on contracts, jurisdiction and the facts, and I'm not answering it here.

Software isn't dying. More of it is moving to where people can't see it. And so is the responsibility for it.

A shorter version of this first appeared on LinkedIn on 2026-10-13. The maintained version, with every source and the date I last checked them, is on argbe.tech.