Last week, I got a LinkedIn mes­sage from a re­cruiter at a small crypto startup. We ex­changed a few mes­sages over a cou­ple of days, she de­scribed a bro­ken proof-of-con­cept they needed a lead en­gi­neer for, and then sent me a pub­lic GitHub repo to re­view. Specifically, she asked me to “check out the dep­re­cated Node mod­ules is­sue.”

It’s not un­com­mon to ask for a re­view of an ex­ist­ing code­base, but some­thing felt off and raised an alarm in my head, so I de­cided to get a bit ex­tra para­noid.

Instead of cloning and in­stalling de­pen­den­cies, I spun up a throw­away VPS on Hetzner, cloned the repo there, and pointed Pi at it in read-only mode, with only file-read­ing tools en­abled:

pi –tools read,grep,find,ls

I asked the agent to re­view the code­base and flag any­thing sus­pi­cious. It stopped al­most im­me­di­ately at app/​test/​in­dex.js.

The back­door

The repo felt like a React fron­tend with a Node back­end. The trap was in app/​test/​in­dex.js, about 250 lines dis­guised as a test suite. Inside, a URL is as­sem­bled from frag­ments:

const pro­to­col = “https”, do­main = “store”, sep­a­ra­tor = ”://”, path = “/icons/”, to­ken = “77″, sub­do­main = “rest-icon-handler”, bear­rto­ken = “logo”;

These com­bine into https://​rest-icon-han­dler.store/​icons/​77.

Then, buried be­tween walls of com­mented-out tests, the pay­load runs any­thing the server sends back to your ma­chine.

The pay­load on line 225, hid­ing in plain sight be­tween com­mented-out tests.

How it trig­gers

The file does­n’t wait for the tests to run. app/​in­dex.js it­self ex­e­cutes const test = re­quire(‘./​test’), which loads and runs app/​test/​in­dex.js.

pack­age.json wires app/​in­dex.js into startup:

pre­pare runs app:pre, which is node app/​in­dex.js.

The pre­pare script is the im­por­tant one. npm runs pre­pare au­to­mat­i­cally af­ter npm in­stall, so just in­stalling de­pen­den­cies ex­e­cutes the back­door.

The in­struc­tion to “check out the dep­re­cated Node mod­ules is­sue” was bait to get me to run npm in­stall.

I could have let the pay­load run in the sand­box and watched what the server sent back as the sec­ond stage, but I stopped there. A repo that runs what­ever a server hands it was enough ev­i­dence.

A bor­rowed iden­tity

The com­mits in the repo were au­thored un­der the name and email of a real de­vel­oper, a full-stack en­gi­neer with an or­di­nary LinkedIn pro­file, a per­sonal web­site, and a GitHub ac­count with a long his­tory. I mes­saged him, pre­tend­ing I’d in­her­ited the code­base and had a few im­ple­men­ta­tion ques­tions, to see how he’d re­act.

He told me he’d never worked for them. He’d been im­per­son­ated on GitHub be­fore and had a repo taken down over it, and he had noth­ing to do with this one. He was re­port­ing these re­pos too.

The whole com­mit his­tory, 39 com­mits, at­trib­uted to one de­vel­oper who’d never touched the repo.

A sec­ond bor­rowed iden­tity

The re­cruiter’s pro­file be­longed to a real arts jour­nal­ist, a well-known one I looked up later, with a long cul­tural back­ground and noth­ing tech­ni­cal on it. When I played along and told her I could­n’t get the pro­ject to in­stall, the jour­nal­ist in­stantly turned into an ex­pert on npm and Node ver­sions. It was quite amus­ing, I’d say.

The non-tech­ni­cal re­cruiter, sud­denly de­bat­ing Node ver­sions and push­ing me to run npm in­stall.

This can hap­pen to any­one

I’ve heard of these at­tacks and read about them on HN, but when one came af­ter me it still caught me a bit off guard. I sus­pected some­thing from the first few mes­sages, but on a more tired or rushed day, I could eas­ily have run npm in­stall be­fore think­ing it through. So, if you get a LinkedIn mes­sage ask­ing you to re­view a repo, a bit of para­noia and good se­cu­rity hy­giene never hurts.

Another take­away is that re­view­ing the code with a read-only agent turned out more pro­duc­tive than read­ing it my­self. The back­door was dressed up as sloppy be­gin­ner code, but the agent flagged it in sec­onds.

I re­ported the repo to GitHub and the re­cruiter to LinkedIn. So far noth­ing has changed and the code is still up.

I’ve been work­ing with lo­cal mod­els since they came out, and fi­nally, they’re sur­pris­ingly good now.

I have a 2022 M2 Mac with 64 GB RAM and 1TB stor­age and I’ve used

Mistral 7B

Gemma 3

OpenAI OSS-20B

Qwen 3 MOE, as well as a num­ber of other Qwen vari­ants like Qwen 2.5 Coder

across a lot of dif­fer­ent sys­tem se­tups like

raw llama.cpp with Open WebUI

llama-cpp-python

Ollama

lla­mafiles and

LM Studio

Where are lo­cal mod­els now?

Early on, mod­els were slow, hard to use, and just not that ac­cu­rate for most pro­gram­ming tasks. The idea that lo­cal mod­els were se­verely lag­ging be­hind was largely true un­til, for me, the re­lease of GPT-OSS. I have no con­crete sci­en­tific ev­i­dence of this - my own per­sonal vibe met­ric of “is a model good enough” is, “do I have to dou­ble-check it against an API model”, and GPT-OSS was the first one where I started do­ing that a lot less of­ten.

As a re­sult, I’ve mostly been us­ing lo­cal mod­els as fast, per­son­al­ized Google for de­vel­op­ment ques­tions that don’t re­quire re­cency.

But with the most re­cent re­leases from Google in the Gemma 4, fam­ily, I’ve fi­nally been able to do agen­tic cod­ing lo­cally and have loops work at about ~75% the ac­cu­racy/​speed of fron­tier mod­els, which is in­cred­i­ble.

I’ve so far been us­ing gemma-4 – 26b-a4b LM Studio im­ple­men­ta­tion as my de­fault lo­cal model. I’ve used the lo­cal setup so far to: Refactor a Python script that was a note­book into a repo of 5 – 6 mod­ules, lint that mod­ule to use cor­rect type hints for gener­ics (most fron­tier mod­els now do this au­to­mat­i­cally, but not al­ways).

I’ve also used it to proof­read some blog posts, write unit tests, and to boot­strap a repo that stands up a two-tower model for rec­om­men­da­tions just to see what the agent would do with a blank slate. Here’s what it gen­er­ated, which was pretty ba­sic but still be­yond the scope of any­thing I would have thought pos­si­ble last year:

Note that the en­vi­ron­ment is re­stricted be­cause I run all my agen­tic work­flows in a Docker con­tainer with lim­ited ac­cess to ex­e­cu­tion.

I’m also build­ing an app that sur­faces trend­ing top­ics from Arxiv pa­pers. Out of cu­rios­ity, I had Pi go through my past LM Studio ses­sion logs and fig­ure out what I was us­ing LM Studio for:

Unsurprisingly, since I’ve been work­ing on Rijksearch,

None of these are ground­break­ing tasks (again, a lot of per­son­al­ized Google/docs lookups), and work­ing on them does give my GPUs and RAM a work­out and the K-V cache grows to 64 GB RAM.

But, the larger story for me is that these kinds of tasks, even as sim­ple as they are, used to be im­pos­si­ble for lo­cal mod­els as re­cently as 6 months ago.

Gemma-4 – 12b-qat just came out but I’ve al­ready also re­ally been im­pressed with its per­for­mance rel­a­tive to its size. The model ar­chi­tec­ture it­self is re­ally in­ter­est­ing and pro­poses a bunch of in­ter­est­ing ques­tions like, “if we are con­strained by per­for­mance and price, what ar­chi­tec­tural trade­offs do we need to make?” a ques­tion that so far has not re­ally been asked in the mad to­ken gold rush.

Running agen­tic mod­els lo­cally to­day

But don’t take my word for any of this, try it out for your­self! You’ll need a lo­cal model in­fer­ence en­gine, an agen­tic har­ness, and the lo­cal model ar­ti­fact if you want to try to run lo­cal agen­tic flows. You’ll need to set up the har­ness to point at your lo­cal in­fer­ence end­point, the down­loaded model ar­ti­fact served via the in­fer­ence en­gine.

For my lo­cal setup, I’m cur­rently us­ing Pi as the agent har­ness and LM Studio as the in­fer­ence server, al­though it would likely be faster if I just used llama.cpp di­rectly - a po­ten­tial di­rec­tion for a fu­ture ex­per­i­ment.

This post was very easy to fol­low to set up agen­tic cod­ing with Pi and LM Studio, al­though I did make a few tweaks to the post’s setup.

Model: The post rec­om­mends Gemma 26B A4B , but gemma-4 – 12b-qat is more re­cent and smaller and faster, with­out much sac­ri­fice in ac­cu­racy.

Security: I run every Pi ses­sion in a Docker con­tainer and give it per­mis­sions only to bash so that it can’t run Python code or do web brows­ing, al­though I do plan to al­low curl in a dif­fer­ent im­age for some re­search work I’m do­ing.

Agent Harness Config: Since I run every­thing in Docker, I edited Pi’s mod­els.json in or­der to get Pi to talk to the model.

“lmstudio”: { “baseUrl”: “http://​host.docker.in­ter­nal:1234/​v1”, “api”: “openai-completions”, “apiKey”: “not-needed”, “models”: [ { “id”: “google/gemma-4 – 12b-qat”, “input”: [ “text”, “image” ] } ] }

Here’s my Docker Compose con­fig:

ser­vices: pi: build: con­text: . dock­er­file: Dockerfile im­age: pi-agent:0.74.0 init: true stdin_open: true tty: true ex­tra_hosts: - “host.docker.internal:host-gateway” en­vi­ron­ment: ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY:-} OPENAI_API_KEY: ${OPENAI_API_KEY:-not-needed} GEMINI_API_KEY: ${GEMINI_API_KEY:-} OPENAI_API_BASE: ${OPENAI_API_BASE:-http://​host.docker.in­ter­nal:1234/​v1} # note that you’ll need to spec­ify a base if you also use OpenAI to ac­cess OpenAI’s ac­tual com­ple­tions end­point WHATEVER_API_KEY: ${WHATEVER_API_KEY:-} vol­umes: - ${HOME}/.pi/agent/models.json:/config/models.json - ${WORKSPACE:-.}:/workspace - pi-con­fig:/​con­fig - pi-ses­sions:/​ses­sions work­ing_dir: /workspace

vol­umes: pi-con­fig: pi-ses­sions:

and here’s the bash script that runs pi .

#!/usr/bin/env bash

# Pi — Start the con­tainer­ized Pi agent.

# Directory con­tain­ing this script and the com­pose files. SCRIPT_DIR=“$(cd — “$(dirname “${BASH_SOURCE[0]}“)” && pwd)”

# Workspace to mount into the con­tainer. WORKSPACE_DIR=“${WORKSPACE:-$(pwd)}” case “$WORKSPACE_DIR” in /*) ;; *) WORKSPACE_DIR=“$(cd — “$WORKSPACE_DIR” && pwd)” ;; esac ex­port WORKSPACE=“$WORKSPACE_DIR”

sand­box=“${PI_SAND­BOX:-0}” pi_args=()

while (($#)); do case “$1” in

–sandbox) sand­box=1 ;; –no-sandbox) sand­box=0 ;; *) pi_args+=(“$1”) ;;

esac shift done

com­pose_­files=( -f “$SCRIPT_DIR/docker-compose.yml” ) if [[ “$sandbox” == “1” ]]; then # an even more se­cure sand­box com­pose_­files+=( -f “$SCRIPT_DIR/docker-compose.sandbox.yml” ) fi

# Derive a con­tainer name from the work­space di­rec­to­ry’s base­name. # Sanitize to char­ac­ters Docker ac­cepts: [a-zA-Z0 – 9][a-zA-Z0 – 9_.-]* re­po_s­lug=“$(base­name — “$WORKSPACE_DIR” | tr -c ‘a-zA-Z0 – 9_.-’ ‘-’ | sed ‘s/^-*//’)” [[ -z “$repo_slug” ]] && re­po_s­lug=“work­space” con­tain­er_­name=“pi-${re­po_s­lug}-$$”

api_key_args=( -e OPENAI_API_KEY -e DEEPSEEK_API_KEY -e ANTHROPIC_API_KEY -e GEMINI_API_KEY )

cmd=( docker com­pose –project-directory “$SCRIPT_DIR” “${compose_files[@]}” run –rm –name “$container_name” “${api_key_args[@]}” pi )

if ((${#pi_args[@]})); then cmd+=(“${pi_args[@]}“) fi

exec “${cmd[@]}”

I build the Docker con­tainer and make changes to the files in its own repo. Then, I run Pi in the repo I’m work­ing in, which spins up Docker so that Pi can’t wipe files or di­rec­to­ries by act­ing on my phys­i­cal hard drive. This also en­ables Pi run­ning in the con­tainer to see my cus­tom model json con­fig by ship­ping it into the con­tainer. All of this has been work­ing fairly well for my ex­per­i­ments.

There are still is­sues with lo­cal mod­els: in­fer­ence can be slow, con­text win­dows are small and lim­ited to your own hard­ware, and the ecosys­tem, al­though it’s made a ton eas­ier by tool­ing like LM Studio and HuggingFace’s Use This Model but­ton. Early re­leases suf­fer from prompt tem­plate mis­matches. But, these are usu­ally patched ex­tremely quickly. Needless to say, I’m not sure this is ready for pro­duc­tion soft­ware de­vel­op­ment quite yet.

The ben­e­fits, though, are nu­mer­ous and the ecosys­tem crit­i­cal to in­vest in, par­tic­u­larly now. One of the very cool parts of lo­cal mod­els is you can in­tro­spect al­most every­thing, like watch­ing the to­ken in­fer­ence process live,

and watch­ing to­kens in/​out.

You can do things like change the lo­cal con­text win­dow and watch per­for­mance im­prove or de­grade, and re­ally dig into how your to­kens are processed on the GPU. You can change the sys­tem prompt, the quan­ti­za­tions. You can pit mod­els against each other. You can also change and in­tro­spect the har­ness side.

The pos­si­bil­i­ties are end­less, and the tools only keep get­ting bet­ter.

It’s a sim­ple idea re­ally, and it’s the right ab­strac­tion for the fu­ture of the in­ter­net. IP ad­dresses can break, with­out warn­ing, and it’s out­side of your de­vice’s con­trol. Keys, how­ever, are cre­ated & con­trolled by you. They stay the same as your de­vice moves, and are yours to throw away, or not. IP ad­dresses can be pri­vate and in­ac­ces­si­ble be­hind fire­walls, but with iroh your de­vice can be se­curely ad­dress­able no mat­ter where it is.

We think this is how the in­ter­net should work, which is why iroh ex­ists, and to­day we’re de­lighted to an­nounce iroh ver­sion 1.0.

This is our first sta­ble re­lease, but the pro­ject has grown sig­nif­i­cantly over the 65 ver­sions that led to 1.0. iroh is al­ready used all over the place. The pub­lic re­lays we run have seen more than 200 mil­lion end­points cre­ated, in the last 30 days alone. Developers are us­ing iroh to stream video, train large lan­guage mod­els, talk to agents, se­cure chats, play games, send files, and many more things than we could jam into this list. Iroh is a fun­da­men­tal tech­nol­ogy aimed at a fun­da­men­tal shift in the in­ter­net, and it’s run­ning on mil­lions of de­vices to­day.

After more than 4 years of build­ing in the open, we have a foun­da­tion we’re both proud of.

We shifted onto open stan­dards, pre­fer­ring IETF drafts when­ever pos­si­ble

We built our own im­ple­men­ta­tion of QUIC mul­ti­path, so iroh can build & man­age mul­ti­ple routes within the same con­nec­tion, and hot swap paths as con­di­tions change

We im­ple­mented QUIC NAT tra­ver­sal, so we can es­tab­lish di­rect con­nec­tions while keep­ing con­nec­tion de­tails en­crypted

We added full lo­cal-first con­fig­u­ra­tions so iroh can find & con­nect to lo­cal de­vices, with­out in­ter­net ac­cess

We built & con­tin­u­ally check that iroh can com­pile to WASM & run in the browser

We worked with power users to add hooks, so you can in­ject logic to con­trol how con­nec­tions should work

We’ve even added sup­port for cus­tom trans­ports, so you can plug in tech­nolo­gies like Bluetooth Low-Energy (BLE), LoRa (under con­struc­tion), WiFi Aware, or even Tor to build con­nec­tions, and all of this fits un­der the same dial-by-key ab­strac­tion

The power of that key can’t be over­stated. We use it to se­cure the con­nec­tion. And be­cause all data that comes from the con­nec­tion is se­cured by that key, we can build up from that same key into iden­tity, per­mis­sions, and at­tri­bu­tion. We can also use that same key as an ad­dress we can dial, no mat­ter where it is in the world. It turns the in­ter­net into a se­cure lo­cal­host.

Iroh con­nec­tions are also far more ef­fi­cient. It’s nor­mal to see 95% of data trans­ferred in a con­nec­tion pass di­rectly be­tween de­vices. Going di­rect means fewer hops through the cloud, which low­ers your egress bill. It’s also fewer hops through routers, which means the in­ter­net is more ef­fi­cient over­all.

We pre­vi­ously paused FFI sup­port be­cause of main­te­nance over­head with API churn and promised to bring it back with a sta­ble 1.0 API. Now we’re foll­wing through on this promise: In ad­di­tion to the Rust crate, we now of­fi­cially sup­port Python, Node.js, Swift, and Kotlin. This makes your ap­pli­ca­tion use case even eas­ier, mak­ing it pos­si­ble to em­bed iroh into your swift iOS ap­pli­ca­tion or your Kotlin Android app. Check out the doc­u­men­ta­tion and gen­er­ated API docs.

Iroh ver­sion 1.0 as­serts sta­bil­ity for both the wire pro­to­col and lan­guage APIs: an iroh v1 end­point will be able to com­mu­ni­cate with an­other iroh v1 end­point, re­gard­less of mi­nor ver­sion or lan­guage.

In the fu­ture we may ver­sion these two as­pects in­de­pen­dently, for ex­am­ple: we may re­lease ver­sion 2 of a given lan­guage API, but keep com­pat­i­bil­ity over the wire. Any change that af­fects the wire sta­bil­ity of iroh will al­ways co­in­cide with a ma­jor re­lease.

Version 1.0 is the first ma­jor re­lease of iroh, which we’re an­nounc­ing in con­junc­tion with our sup­port sched­ule for cus­tomers: Read our sup­port sched­ule

In short:

Major and mi­nor ver­sions af­ter 1.0 are sup­ported on a sched­ule.

The 0.35 mi­nor ver­sion won’t re­ceive fur­ther re­leases. Public re­lay sup­port for 0.35x con­tin­ues through Dec 31, 2026, more on that in the sec­tion be­low.

We do not plan to sup­port ca­nary (0.9x) and re­lease can­di­dates (1.0.0-rcX) af­ter to­day.

It’s im­por­tant to note there are a sig­nif­i­cant num­ber of bug fixes and im­prove­ments in 1.0, so if you en­counter an is­sue on an ear­lier re­lease we want you to try up­dat­ing to the 1.0 to en­sure it is still an is­sue there be­fore open­ing a bug re­port.

We main­tain a set of pub­lic re­lays, most com­monly ac­cessed via the “n0” pre­set for build­ing an end­point.

We will bump pub­lic re­lays to their lat­est ver­sion shortly af­ter each re­lease, usu­ally within 24 hours. Wire-breaking re­lay changes will get new URLs so older clients keep work­ing.

As al­ways, re­lay bi­na­ries them­selves are open source, and we of­fer hosted re­lays through iroh ser­vices. Public re­lays are rate-lim­ited for re­layed traf­fic, which can change at any time.

The in­ter­net should be built on di­al­ing keys. On con­nec­tions that just work. On con­nec­tions that are se­cure, and de­fault to be­ing di­rect. With 1.0 you now have a ma­ture net­work­ing stack that you can put into your app with con­fi­dence. Now is the time to come build on iroh, and we can’t wait to see what you come up with.

Check out the iroh quick­start guide for ap­pli­ca­tion de­vel­op­ers.

Join the dis­cus­sion on red­dit | hack­ernews | bluesky | x.com

Iroh is a dial-any-de­vice net­work­ing li­brary that just works. Compose from an ecosys­tem of ready-made pro­to­cols to get the fea­tures you need, or go fully cus­tom on a clean ab­strac­tion over dumb pipes. Iroh is open source, and al­ready run­ning in pro­duc­tion on hun­dreds of thou­sands of de­vices.To get started, take a look at our docs, dive di­rectly into the code, or chat with us in our dis­cord chan­nel.

Maintained by Epic Games, Lore is de­signed for un­prece­dented scal­a­bil­ity of both data and teams. It’s op­ti­mized for pro­jects—in­clud­ing games and en­ter­tain­ment—that com­bine code with large bi­nary as­sets, and caters for the needs of de­vel­op­ers and artists alike.

Key find­ings

74%

con­sumers say the in­ter­net feels less hu­man than 10 years ago

40 min

av­er­age time be­fore con­sumers ex­pe­ri­ence “bot fa­tigue”

61%

con­sumers can’t name a brand us­ing AI well in its mes­sag­ing

16.6

av­er­age weekly hours en­ter­prise teams spend im­prov­ing AI vis­i­bil­ity

Brands have been chas­ing AI vis­i­bil­ity for two years. You’ve spent time and bud­get on it, yet your au­di­ence can’t name a sin­gle com­pany they think is do­ing it well. The brands build­ing for the next phase treat their web­site as the place where AI gets clean data and hu­mans get some­thing worth their time.

A less hu­man web costs you read­ers.

Your au­di­ence can sense when a ma­chine is talk­ing to them. Most are check­ing out be­fore they’ve de­cided whether they care. Bot fa­tigue sets in when the in­ter­net stops feel­ing hon­est. The small mo­ments that used to make the web worth vis­it­ing are dis­ap­pear­ing.

The AI web

7/10

con­sumers say the in­ter­net feels less hu­man than it did 10 years ago

Feels less hu­man

Still hu­man

40 min

the av­er­age time to “bot fa­tigue,” when in­ter­ac­tions start to feel syn­thetic

Can your con­tent in­fra­struc­ture mea­sure this shift and re­spond to it? We’ll cover how en­ter­prise teams re­struc­ture con­tent for AI dis­cov­ery with­out los­ing what feels hu­man in our up­com­ing we­bi­nar.

What is AI brand vis­i­bil­ity?

AI brand vis­i­bil­ity is how of­ten a brand ap­pears in an­swers gen­er­ated by AI en­gines like ChatGPT, Perplexity, Claude, and Gemini. It’s a dif­fer­ent prob­lem from search en­gine vis­i­bil­ity, which mea­sures rank­ings on re­sult pages. A brand can rank at the top of Google and not ap­pear in­side ChatGPT at all. As of 2026, no sin­gle dash­board tracks AI brand vis­i­bil­ity across every en­gine, and the cat­e­gory has no es­tab­lished leader.

Nobody has won AI brand vis­i­bil­ity yet.

Every an­swer in our con­sumer sur­vey pointed the same way: Nobody has done it well yet. Brands have spent the past year fund­ing AI strat­egy, but con­sumers can’t point to a sin­gle com­pany they think is get­ting it right.

The cat­e­gory has no in­cum­bent, and no tem­plate to copy. The brand that builds that recog­ni­tion first gets to de­fine the stan­dard.

Brand vis­i­bil­ity

61%

of con­sumers can’t name a brand that uses AI well in its mes­sag­ing

16%

say no brand is us­ing AI well at all

60%

say AI in a brand’s mes­sag­ing is a turnoff, not a fea­ture

“No cus­tomer or user wakes up and says, ‘I hope I get to talk to a chat bot or an AI agent to­day.’ Human-centered de­sign is truer to­day with ar­ti­fi­cial in­tel­li­gence. Ironically, the an­swer is us­ing AI to be more hu­man.”— Brian Solis, Head of Global Innovation, ServiceNow

“No cus­tomer or user wakes up and says, ‘I hope I get to talk to a chat bot or an AI agent to­day.’ Human-centered de­sign is truer to­day with ar­ti­fi­cial in­tel­li­gence. Ironically, the an­swer is us­ing AI to be more hu­man.”

Build for both au­di­ences at once.

AI needs to find the con­tent and a per­son needs a rea­son to stay once they ar­rive. The sec­ond part is harder, and most en­ter­prises are still guess­ing at it. The brands worth watch­ing are bet­ting that “staying” comes from giv­ing peo­ple some­thing to do: in­ter­ac­tive con­tent, dy­namic ex­pe­ri­ences, the small mo­ments a flat AI sum­mary can’t de­liver.

The web­site is the only place where both jobs run to­gether. AI gets struc­tured con­tent it can cite, and the reader gets some­thing worth their time. That’s the foun­da­tion you get on WordPress VIP.

The guide for build­ing that dual-pur­pose site is in Future-Proof Your Brand for the AI-Native Web, a frame­work for prepar­ing your web plat­form.

How en­ter­prises are mea­sur­ing AI brand vis­i­bil­ity

The cat­e­gory is barely two years old and the toolset is still set­tling. No sin­gle dash­board tracks every AI sur­face. No shared de­f­i­n­i­tion of “good” ex­ists yet. Pricing across the cat­e­gory swings from free to six fig­ures de­pend­ing on cov­er­age and cus­tomiza­tion. What en­ter­prises are us­ing right now sorts into five cat­e­gories, with real tools in­side each.

This is a snap­shot since the spe­cific prod­ucts will shift in the next 12 months. The cat­e­gories will out­last them, which is why the sec­tion is or­ga­nized around what the tools do.

This is the newest cat­e­gory, built specif­i­cally to track how of­ten a brand ap­pears in ChatGPT, Perplexity, Claude, and Gemini an­swers. These tools sim­u­late queries at scale and sur­face ci­ta­tion fre­quency and sen­ti­ment over time.

Tools in this cat­e­gory: Profound, BrightEdge, brand­vis­i­bil­ity.ai, Tryevergreen, and a hand­ful of smaller com­peti­tors that emerged in late 2025.

Best for: Teams that need to con­nect AI vis­i­bil­ity to busi­ness out­comes. AI ci­ta­tions are top-of-fun­nel. This cat­e­gory mea­sures what those ci­ta­tions turn into. The brands that fig­ure out which AI-referred vis­i­tors con­vert can de­fend their AI strat­egy spend.

Watch for: Pricing mod­els are still set­tling. Most plat­forms re­quire four to six weeks of data col­lec­tion be­fore bench­marks are mean­ing­ful. Sample-based query sim­u­la­tion has gaps, and tools that promise “complete cov­er­age” of every AI an­swer are over­stat­ing their method­ol­ogy.

These are the es­tab­lished SEO plat­forms that ex­tended into AI track­ing start­ing in 2024. These tools layer AI ci­ta­tion data on top of tra­di­tional search met­rics, which makes them use­ful for teams al­ready run­ning SEO work­flows.

Tools in this cat­e­gory: Similarweb (AI Intelligence), Semrush (AI Toolkit), Ahrefs (Brand Radar).

Best for: SEO teams that want AI vis­i­bil­ity data with­out a new ven­dor re­la­tion­ship. The in­te­gra­tion with ex­ist­ing search re­port­ing is the main value; it lets a team see or­ganic and AI traf­fic in the same view.

Watch for: AI cov­er­age in this cat­e­gory is gen­er­ally nar­rower than in ded­i­cated AI ci­ta­tion plat­forms. The tools were built for search and are still catch­ing up on the AI side. AI num­bers here have to be treated as di­rec­tional.

In this cat­e­gory: the an­a­lyt­ics plat­forms that de­tect and seg­ment traf­fic ar­riv­ing from AI en­gines. These are the ci­ta­tion mon­i­tor­ing tools that tell a brand it’s be­ing men­tioned. This cat­e­gory tells a brand what hap­pens af­ter.

Tools in this cat­e­gory: Parse.ly (part of the WordPress VIP prod­uct fam­ily), Plausible, Fathom Analytics, and most en­ter­prise an­a­lyt­ics plat­forms (Google Analytics 4) with cus­tom seg­men­ta­tion.

Best for: Teams that need to con­nect AI vis­i­bil­ity to busi­ness out­comes. AI ci­ta­tions are top-of-fun­nel. This cat­e­gory mea­sures what those ci­ta­tions turn into. The brands that fig­ure out which AI-referred vis­i­tors con­vert can de­fend their AI strat­egy spend.

Watch for: AI re­fer­rer de­tec­tion still varies by plat­form. Some AI en­gines pass clean re­fer­rer head­ers, oth­ers rely on UTM tag­ging. Coordination be­tween con­tent and an­a­lyt­ics teams is usu­ally re­quired to get clean data.

Broader brand mon­i­tor­ing plat­forms that added AI sur­face track­ing to ex­ist­ing so­cial lis­ten­ing and PR mon­i­tor­ing ca­pa­bil­i­ties. These cover AI en­gines as one in­put along­side so­cial and tra­di­tional me­dia men­tions.

Tools in this cat­e­gory: Brandwatch, Talkwalker, Meltwater.

Best for: Communications and PR teams that al­ready use these plat­forms for cri­sis mon­i­tor­ing and share-of-voice track­ing. The AI cov­er­age is an ex­ten­sion of an ex­ist­ing work­flow.

Watch for: AI cov­er­age in this cat­e­gory tends to be lighter than in ded­i­cated AI ci­ta­tion tools. Useful for a 30,000-foot view, less use­ful for gran­u­lar ci­ta­tion analy­sis.

This is what en­ter­prises with en­gi­neer­ing ca­pac­ity are build­ing them­selves. These so­lu­tions use LLM APIs to query AI en­gines on a sched­ule and sur­face re­sults in a dash­board the team con­trols. Pew Research Center’s work with WordPress VIP, cov­ered in Chapter 2, is one ex­am­ple of this ap­proach.

Best for: Enterprises with en­gi­neer­ing re­sources who want to de­fine their own queries and con­trol their own data. Ideal when the brand’s AI vis­i­bil­ity strat­egy de­pends on niche or in­dus­try-spe­cific queries that off-the-shelf tools don’t cover well.

Watch for: Maintenance bur­den. LLM API ac­cess is now sta­ble, though pric­ing and rate lim­its change fre­quently. Custom dash­boards re­quire on­go­ing en­gi­neer­ing at­ten­tion to keep cur­rent.

AI brand vis­i­bil­ity tools at a glance

How to choose

Match the tool cat­e­gory to the ques­tion the team needs to an­swer:

“Are we be­ing cited?” Use an AI ci­ta­tion mon­i­tor­ing plat­form.

“Are we be­ing cited rel­a­tive to our search per­for­mance?” Use search an­a­lyt­ics with AI over­lays.

“What hap­pens af­ter we’re cited?” Use web an­a­lyt­ics with AI re­fer­ral track­ing.

“How does AI fit into our broader brand sen­ti­ment?” Use a brand in­tel­li­gence plat­form.

“We need to track some­thing none of the above can an­swer.” Build a cus­tom so­lu­tion.

Most en­ter­prises use two cat­e­gories to­gether. The most com­mon com­bi­na­tion is a tool from the AI ci­ta­tion mon­i­tor­ing cat­e­gory to know whether the brand shows up, and a tool from the web an­a­lyt­ics cat­e­gory to know what that vis­i­bil­ity is worth. The brands that fig­ured this out first are the ones whose 2027 AI vis­i­bil­ity bud­gets won’t be re-lit­i­gated in bud­get meet­ings.

Continue read­ing

Chapter 2

Brands chase AI vis­i­bil­ity. Consumers chase the source.

Chapter 3

Consumers are wary of gate­keep­ing. More than mar­keters are.

Chapter 4

The web­site is still the de­fault trust layer.

Chapter 5

The next web­site does­n’t look like a web­site.

FAQs about AI brand vis­i­bil­ity

Bot fa­tigue is the point at which on­line in­ter­ac­tions start to feel syn­thetic. WordPress VIP’s 2026 sur­vey of 1,200 U.S. con­sumers found the av­er­age per­son hits bot fa­tigue in about 40 min­utes. The broader pat­tern: 74% of con­sumers say the in­ter­net feels less hu­man than it did 10 years ago, which is the con­sumer-mood shift dri­ving most of what brands are now try­ing to solve in their AI strat­egy.

Not yet. The cat­e­gory is too new and the mea­sure­ment tools are too im­ma­ture. Platforms cite dif­fer­ent sources for dif­fer­ent queries, the ci­ta­tions change as mod­els up­date, and the met­rics en­ter­prise teams use to track AI vis­i­bil­ity aren’t stan­dard­ized across ven­dors. What’s clear is that no brand has built a durable AI pres­ence. The brand that de­fines what “AI brand vis­i­bil­ity done well” looks like will be the one that fig­ures out the mea­sure­ment layer be­fore the rest of the mar­ket does.

The web­site has two jobs now and they have to run on the same foun­da­tion. AI en­gines need struc­tured con­tent they can find and cite ac­cu­rately. Human vis­i­tors need a rea­son to stay once they click through from an AI sum­mary. The brands solv­ing for both are treat­ing the web­site as the place where AI ex­tracts data and a per­son has an ex­pe­ri­ence worth their time. This is the cen­tral ar­gu­ment of WordPress VIP’s 2026 State of the Open Web re­port.

Please en­able JS and dis­able any ad blocker

GrapheneOS Discussion Forum