KOReader is a doc­u­ment viewer for E Ink de­vices. Supported file­for­mats in­clude EPUB, PDF, DjVu, XPS, CBT, CBZ, FB2, PDB, TXT, HTML, RTF, CHM, DOC, MOBI and ZIP files. It’s avail­able for Kindle, Kobo, PocketBook, Android and desk­top Linux.

TurboFieldfare

Gemma 4 26B-A4B in­fer­ence in about 2 GB of RAM A cus­tom Swift + Metal run­time for any Apple Silicon Mac, even the 8 GB ones.

Quick start · Local server · Benchmarks · Contribute re­sults · How it works · Experiments · References

Memory got ex­pen­sive. So I gave a 26-billion-parameter model a ~2 GB bud­get.

TurboFieldfare runs the in­struc­tion-tuned Gemma 4 26B-A4B with­out load­ing the en­tire 14.3 GB model into mem­ory. It keeps the shared 1.35 GB core and FP16 KV cache in mem­ory, then streams only the ex­perts needed for each to­ken from SSD. This is what lets the model run on Macs with 8 GB of RAM.

The run­time, stream­ing in­staller, CLI, and na­tive Mac app are writ­ten in Swift and Metal. TurboFieldfare is model-spe­cific rather than a wrap­per around MLX or llama.cpp. The cu­rated ex­per­i­ment record sum­ma­rizes 103 mea­sured re­sults across ker­nels, caching, I/O, pre­fill, and de­code.

Try it

git clone https://​github.com/​dru­mih/​turbo-field­fare.git cd turbo-field­fare swift build -c re­lease .build/release/TurboFieldfareMac

On the first run, Swift Package Manager down­loads and builds the Swift pack­ages re­quired by the to­k­enizer. The com­plete re­lease build in­cludes the fore­ground Mac app and its sib­ling de­code-ser­vice ex­e­cutable.

When the app opens, choose Download and let TurboFieldfare fetch and repack the pinned model (about 15 GB). Once it is ready, choose Load Model, type your prompt, and press Generate.

At a glance

The mea­sured re­sult is a ref­er­ence point, not a per­for­mance ceil­ing. Prompt length, gen­er­ated length, page-cache state, and hard­ware all af­fect through­put. To help mea­sure an­other Apple Silicon Mac, fol­low the com­mu­nity bench­mark guide.

Using TurboFieldfare

TurboFieldfare pro­vides a na­tive Mac app, a com­mand-line in­ter­face, and an ex­per­i­men­tal loop­back OpenAI-compatible server. They use the same .gturbo model di­rec­tory, but only one model-own­ing prod­uct should run at a time.

The Swift pack­age ex­poses six prod­ucts:

Requirements

An Apple Silicon Mac; the val­i­dated tar­get is an 8 GB M2 MacBook Air

ma­cOS 26 with Metal 4

Xcode 26 and Swift 6.2 or newer

Enough free stor­age for the ~14.3 GB model in­stal­la­tion

An in­ter­net con­nec­tion for the first model in­stall

The pack­age is ar­m64-only. Older ma­cOS and Metal ver­sions are not sup­ported.

Prompting the model

The Mac app treats what you type as an in­struc­tion and han­dles Gemma’s chat for­mat­ting au­to­mat­i­cally. Just de­scribe the task and in­clude any con­text the model needs.

Generation de­faults to tem­per­a­ture 0.2, Top-K 64, and Top-P 0.95. Set tem­per­a­ture to 0 for de­ter­min­is­tic greedy out­put. The model can still re­peat it­self or give in­cor­rect an­swers, so check im­por­tant re­sults.

TurboFieldfare is text-only. The app and CLI sup­port user and model mes­sages plus op­tional sys­tem guid­ance; they do not ex­pose or ex­e­cute tools. The loop­back server ac­cepts func­tion-tool de­c­la­ra­tions and re­turns model-pro­duced tool calls for the client to au­tho­rize and ex­e­cute. Images, au­dio, and video are not sup­ported.

Mac app

Clone the repos­i­tory, then run the app from its root:

swift build -c re­lease .build/release/TurboFieldfareMac

Build the com­plete pack­age so the app and its sib­ling de­code ser­vice are both avail­able. When launched from this check­out, the app stores the model in scratch/​gem­ma4.gturbo.

Install the model

On first launch, the app checks the avail­able stor­age and shows the down­load and in­stalled sizes. Choose Download to be­gin.

The in­staller never ma­te­ri­al­izes the full source check­point. It streams the re­quired byte ranges from the pinned Hugging Face re­vi­sion and repacks them di­rectly into the .gturbo lay­out as they ar­rive. This avoids a sec­ond full check­point on disk and keeps scratch mem­ory bounded.

The first in­stal­la­tion trans­fers about 15 GB through bounded Hugging Face range re­quests. Network speed and Hugging Face re­sponse times vary, so it can take a while. The com­pleted .gturbo in­stal­la­tion oc­cu­pies about 14.3 GB and is ac­cepted only af­ter its man­i­fest and file hashes have been val­i­dated. Installation does not load the model into mem­ory.

Load and gen­er­ate

After in­stal­la­tion:

Choose Load Model.

Enter a prompt in the com­poser.

Choose Generate, or press Command+Return.

Use the stop but­ton or Escape to end gen­er­a­tion early.

The sta­tus bar shows gen­er­a­tion progress, de­code speed, and mem­ory use. Use the right pane to con­fig­ure sam­pling, con­text length, ex­pert-cache slots, and run­time op­tions. See Runtime con­trols for de­tails and de­faults.

Command-line in­ter­face

The CLI uses an ex­ist­ing .gturbo in­stal­la­tion. If you in­stalled the model through the Mac app, it is al­ready avail­able at scratch/​gem­ma4.gturbo. Otherwise, in­stall it from the com­mand line:

swift run -c re­lease TurboFieldfareRepack \ –output scratch/​gem­ma4.gturbo \ –overwrite

Continue a can­celled or in­ter­rupted down­load:

swift run -c re­lease TurboFieldfareRepack \ –output scratch/​gem­ma4.gturbo \ –overwrite \ –resume

Remove saved down­load state:

swift run -c re­lease TurboFieldfareRepack \ –discard-partial \ –output scratch/​gem­ma4.gturbo

The run­time ac­cepts only a com­pleted .gturbo di­rec­tory with a fi­nal man­i­fest.json.

Verify an ex­ist­ing in­stal­la­tion with­out load­ing the model:

swift run -c re­lease TurboFieldfareRepack \ –verify-install \ –input-gturbo scratch/​gem­ma4.gturbo

Instruction chat

Put chat mes­sages in a JSON ar­ray and pass it with –messages-file:

[ {“role”: “user”, “content”: “Explain why chun­ked pre­fill re­duces time to first to­ken while keep­ing mem­ory bounded.“} ]

swift run -c re­lease TurboFieldfareCLI \ –model scratch/​gem­ma4.gturbo \ –messages-file mes­sages.json

This for­mats mes­sages in the same way as the Mac app. The CLI re­sponse limit is set with –max-new, which de­faults to 1,024 to­kens. The Mac app can gen­er­ate un­til the se­lected con­text win­dow is full.

Raw com­ple­tion

–prompt is avail­able for raw com­ple­tion and re­pro­ducible com­par­isons. It passes the text di­rectly to the model with­out chat for­mat­ting. Use –messages-file for in­struc­tion-re­sponse con­ver­sa­tions.

swift run -c re­lease TurboFieldfareCLI \ –model scratch/​gem­ma4.gturbo \ –prompt “The cap­i­tal of France is” \ –max-new 64 \ –temperature 0

This ex­am­ple de­lib­er­ately re­quests a short greedy com­ple­tion.

Common gen­er­a­tion op­tions in­clude –max-context, –temperature, –top-k, –top-p, –repetition-penalty, –seed, and re­peat­able –stop strings. The pub­lic CLI uses pro­duc­tion run­time de­faults. Run the fol­low­ing com­mand for the com­plete op­tion list:

swift run -c re­lease TurboFieldfareCLI –help

Generated text goes to stan­dard out­put. Timing sta­tis­tics go to stan­dard er­ror; add –quiet to sup­press that footer in scripts.

Local OpenAI-compatible server

Build the server and point it at an in­stalled model:

swift build -c re­lease –product TurboFieldfareServer .build/release/TurboFieldfareServer \ –model scratch/​gem­ma4.gturbo

It lis­tens on http://​127.0.0.1:8080/​v1 and sup­ports Chat Completions, stream­ing, func­tion tools, and sin­gle-pre­fix prompt reuse. The client must au­tho­rize and run every tool call. Keep the server on loop­back; it has no re­mote au­then­ti­ca­tion or TLS.

See Local server for a test re­quest, Python and OpenCode setup, prompt reuse, tool han­dling, and the sup­ported API sub­set.

Test and con­tribute

Run the pub­lic test suite se­ri­ally:

Scripts/test.sh

Before start­ing a model run, close mem­ory-heavy apps and check mem­o­ry_­pres­sure -Q. If it re­ports lit­tle free mem­ory, post­pone the run. Run only one TurboFieldfare app, de­code ser­vice, CLI, server, test, or other lo­cal-model process at a time.

To con­tribute a com­pa­ra­ble per­for­mance re­sult, fol­low the com­mu­nity bench­mark guide.

How the in­fer­ence en­gine works

At each trans­former layer, Metal com­putes at­ten­tion and the router from res­i­dent weights. The CPU uses the router’s top-8 ex­pert IDs to plan against the lay­er’s 16-slot LFU cache, then fills misses with bounded par­al­lel pread calls into Metal-visible buffers. Metal com­putes the res­i­dent shared-ex­pert branch while those reads run, then com­bines the shared and routed out­puts.

Prompt pre­fill uses chunks of up to 128 to­kens so one fetched ex­pert can serve mul­ti­ple rows. Generation re­peats the routed layer loop one to­ken at a time. The in­staller ap­plies the same bounded-mem­ory rule: it repacks re­mote ranges di­rectly into .gturbo with­out stag­ing a full shard or ten­sor.

For a vi­sual in­tro­duc­tion to the model ar­chi­tec­ture, see Maarten Grootendorst’s A Visual Guide to Gemma 4.

System de­sign ex­plains the .gturbo lay­out, mem­ory own­er­ship, pre­fill, router hand­off, cb1/​io/​cb2 phases, Metal ker­nels, and cor­rect­ness in­vari­ants.

Status and scope

TurboFieldfare cur­rently in­cludes:

Remote stream­ing repack into the .gturbo model for­mat

Instruction-tuned Gemma 4 26B-A4B with ver­i­fied text-only chat for­mat­ting

4-bit MLX affine em­bed­ding, at­ten­tion, shared-ex­pert, and routed-ex­pert weights, with an 8-bit router

Custom Metal ker­nels for quan­tized GEMV, at­ten­tion, MoE, nor­mal­iza­tion, RoPE, sam­pling, and pro­duc­tion fu­sions

SSD-backed routed-ex­pert stream­ing with a bounded ex­pert cache

Chunked sin­gle-prompt pre­fill and to­ken-by-to­ken gen­er­a­tion

FP16 KV stor­age with bounded cir­cu­lar stor­age for 25 slid­ing-win­dow lay­ers and lin­ear stor­age for 5 full-at­ten­tion lay­ers

Exact split-K/​V de­code at­ten­tion with dis­tinct nor­mal­ized K and V paths

A Swift li­brary, stream­ing in­staller, com­mand-line in­ter­face, loop­back OpenAI-compatible server, and na­tive SwiftUI/AppKit Mac app with a one-shot lo­cal de­code ser­vice

Current scope is text-only in­fer­ence from the pinned Gemma 4 26B-A4B in­struc­tion check­point on Apple Silicon Macs with at least 8 GB of RAM.

Future work

Build iPhone and iPad apps, then mea­sure in­fer­ence speed and mem­ory use on mo­bile hard­ware.

Benchmark more Apple Silicon Macs, es­pe­cially the base 16 GB M4 Mac mini and other 8 GB mod­els.

Experiments and tech­ni­cal doc­u­men­ta­tion

The ex­per­i­ments that shaped TurboFieldfare ex­plain the largest wins, the plau­si­ble ideas that failed, and the early re­sults that re­versed un­der stronger val­i­da­tion. The de­tailed ex­per­i­ment record keeps all 103 au­dited en­tries as op­tional ev­i­dence.

Useful en­try points:

Local OpenAI-compatible server

System de­sign

Benchmarks

The ex­per­i­ments that shaped TurboFieldfare

A light­weight user­script that adds Hacker News dis­cus­sions to any ar­ti­cle.

HNewhere de­tects match­ing Hacker News sto­ries, loads com­ments into a side­bar, and lets you browse dis­cus­sions with­out leav­ing the page.

Install

Install a user­script man­ager:

Tampermonkey Violentmonkey Userscripts (Safari)

Install a user­script man­ager:

Tampermonkey

Violentmonkey

Userscripts (Safari)

Install HNewhere

Install HNewhere

Visit an ar­ti­cle with a Hacker News dis­cus­sion.

Visit an ar­ti­cle with a Hacker News dis­cus­sion.

Features

Automatically de­tects Hacker News dis­cus­sions for ar­ti­cles

Displays HN com­ments in a side­bar with­out leav­ing the page

Tracks sto­ries opened from Hacker News

Resizable side­bar with saved width

Collapsible com­ment threads with saved state

Highlights new com­ments since your last visit

Shows story text when avail­able

Marks orig­i­nal poster com­ments

Reply links open di­rectly to Hacker News

Requirements

A browser with user­script sup­port

Access to:

Hacker News API HN Algolia search API

Hacker News API

HN Algolia search API

License

MIT

We are build­ing the mul­ti­plexer for all work.

Building and op­er­at­ing soft­ware to­day spans lo­cal ma­chines, re­mote hosts, sand­boxes, ser­vices, and pro­duc­tion sys­tems. It has many modes of op­er­a­tion: in­ter­ac­tively with a hu­man de­vel­oper, au­to­mat­i­cally through CI and back­ground processes, and in­creas­ingly through agents work­ing in par­al­lel.

This work is all re­lated, yet to­day’s tools di­vide it into sep­a­rate sys­tems. Interactive tools as­sume a per­son at an in­ter­face. Automatic work dis­ap­pears into jobs and logs. And as the work moves to pro­duc­tion it lives be­hind sep­a­rate sys­tems and con­trols.

AI makes this frag­men­ta­tion more vis­i­ble and costly, but it did not cre­ate it. System ad­min­is­tra­tion, con­tin­u­ous in­te­gra­tion, re­mote de­vel­op­ment and col­lab­o­ra­tion have strained the same bound­aries for decades.

We be­lieve the miss­ing layer is a durable ses­sion around the work it­self: one that can span ap­pli­ca­tions and en­vi­ron­ments, pro­vide rel­e­vant con­text by de­fault, ex­pose struc­tured data and ac­tions, pre­serve his­tory, and be dri­ven by soft­ware while re­main­ing vis­i­ble and con­trol­lable by peo­ple.

What we’re build­ing

This is our plan to build a mul­ti­plexer for all work:

1 Build an in­cred­i­ble mul­ti­plexer.

2 Make every­thing in it com­pos­able.

3 Make it safe and op­er­a­ble in pro­duc­tion.

A mul­ti­plexer brings mul­ti­ple in­de­pen­dent streams to­gether through a com­mon in­ter­face. For us, that means in­ter­ac­tive work, au­to­matic work, and pro­duc­tion work would share one well-crafted un­der­ly­ing sys­tem in­stead of liv­ing in sep­a­rate tools.

We’ll be­gin with a ter­mi­nal mul­ti­plexer. It keeps mul­ti­ple ter­mi­nal blocks or­ga­nized in­side a long-lived ses­sion, so you can close the ap­pli­ca­tion, re­con­nect from an­other de­vice, and pick up ex­actly where you left off.

If you’re al­ready fa­mil­iar with ter­mi­nal mul­ti­plex­ers, you’ll feel right at home, but we’re bring­ing a more mod­ern touch. Sessions can be ac­cessed through the web and na­tive ma­cOS/​iOS ap­pli­ca­tions, and shar­ing a live ses­sion with other peo­ple is built in from the start. We’re also ad­dress­ing the most com­mon pa­per­cuts of ex­ist­ing tools, such as mak­ing scroll­back, se­lec­tion, and scrolling all work na­tively.

A ter­mi­nal mul­ti­plexer may sound like a nar­row place to start a com­pany. Our vi­sion is much larger, but ter­mi­nals con­nect de­vel­op­ers, agents, tools, and in­fra­struc­ture so it is the right foun­da­tion for every­thing that fol­lows. We will build a high-qual­ity ter­mi­nal mul­ti­plexer that re­mains ex­cel­lent at that job, even as it grows to sup­port the sec­ond and third parts of the plan. We’ll have more to say about those later.

Who we are

We’re a team that has spent our en­tire ca­reers build­ing some of the most widely used de­vel­oper tool­ing, in­fra­struc­ture soft­ware, and AI sys­tems. We care deeply about well-crafted soft­ware that is beau­ti­ful to use, re­li­able in prac­tice, and de­signed for oth­ers to build on.

Mitchell Hashimoto Creator of Ghostty. Co-founded HashiCorp and cre­ated Vagrant, Terraform, Vault, and more. Spent more than a decade as CEO and CTO from its ear­li­est days through its IPO.

Mitchell Hashimoto

Creator of Ghostty. Co-founded HashiCorp and cre­ated Vagrant, Terraform, Vault, and more. Spent more than a decade as CEO and CTO from its ear­li­est days through its IPO.

Jack Pearkes VP of Engineering and VP of R&D at HashiCorp, and its very first em­ployee. Helped to cre­ate HashiCorp’s first prod­ucts and hired and led the orig­i­nal en­gi­neer­ing team.

Jack Pearkes

VP of Engineering and VP of R&D at HashiCorp, and its very first em­ployee. Helped to cre­ate HashiCorp’s first prod­ucts and hired and led the orig­i­nal en­gi­neer­ing team.

Alasdair Monk Head of Experience at Poolside, VP of Design at Vercel, and a se­nior de­sign leader at HashiCorp and Heroku. Two decades spent de­sign­ing and build­ing in­ter­faces for de­vel­op­ers.

Alasdair Monk

Head of Experience at Poolside, VP of Design at Vercel, and a se­nior de­sign leader at HashiCorp and Heroku. Two decades spent de­sign­ing and build­ing in­ter­faces for de­vel­op­ers.

Hector Simpson Designed apps, ser­vices, and agen­tic ex­pe­ri­ences at Poolside. An in­ter­face de­signer and builder who has shipped de­vel­oper-first prod­ucts at Heroku, HashiCorp, Clearbit, and Vercel.

Hector Simpson

Designed apps, ser­vices, and agen­tic ex­pe­ri­ences at Poolside. An in­ter­face de­signer and builder who has shipped de­vel­oper-first prod­ucts at Heroku, HashiCorp, Clearbit, and Vercel.

Superlogical is funded by:

Get on the list for our first re­lease

We’ll let you know when our beta for the ter­mi­nal mul­ti­plexer is avail­able, and any OSS re­leases along the way.

Exploring the tools of the trade

July 2026

Ahh, the demo scene - a dig­i­tal art sub­cul­ture, a mot­ley gang of cre­ative nerds, and a favourite pas­time of mine. So much amaz­ing art, mu­sic and code has been pro­duced by sceners, and any­one who comes into con­tact with the scene might start to won­der ex­actly how - apart from hours of ded­i­cated grind, of course.

The scene has a long and sto­ried tra­di­tion of build­ing its own tools. Sometimes from scratch, some­times by steal­ing ideas or even code from ex­ist­ing of­fer­ings. In a com­bi­na­tion of teenage in­ex­pe­ri­ence, old habits, a pen­chant for ex­per­i­ment­ing and a de­sire to make things look cool, this has re­sulted in some rather pe­cu­liar user in­ter­faces.

A few of them are pre­sented be­low. Most of them are for the Amiga, but sev­eral other plat­forms are rep­re­sented as well.

Elite Sinus Producer

Not want­ing to be ac­cused of click­bait­ing, let’s start off with one of the main at­trac­tions: Elite Sinus Producer (sinus here is to be un­der­stood as sine), made by Ipec Elite for the Amiga. Demos are usu­ally de­scribed as “real time”, which is true in the sense that they’re (almost) never just an­i­ma­tion play­ers, and that demo ef­fects are pro­duced, frame by frame, from code. However, to achieve seem­ingly im­pos­si­ble tech­ni­cal feats, ex­ten­sive “cheating” is em­ployed. The most com­mon cheat is prob­a­bly the so called pre­calc, mean­ing that in­stead of do­ing com­plex maths on a 7 MHz (or even slower) CPU, lookup ta­bles are uti­lized. A plethora of tools for cre­at­ing such lookup ta­bles ex­ist. This is one of them.

When first start­ing Elite Sinus Producer, the user is met with this menu. Upon press­ing an F-key to make a se­lec­tion, the cor­re­spond­ing menu op­tion is high­lighted and a sam­ple of a cuckoo clock is played. Loudly.

Here I’ve se­lected the “Flower” op­tion. Pretty, no? This can then be saved to disk as (presumably) as­sem­bly source code. Any sprite would look nice when mov­ing along this path!

There’s also a handy help screen, which is so out­landish I had to grab a short film clip of it: Part of the back­ground con­sists of mov­ing blue raster bars, and the other part flashes be­tween red and cyan. This ob­vi­ously helps im­mensely when read­ing the text, dis­played in a font de­signed with noth­ing but leg­i­bil­ity in mind.

Text Based Interfaces

Plenty of scene re­lated tools are ei­ther com­mand line util­i­ties or pre­dom­i­nantly text based. First out, we have the as­sem­blers. There was a wide va­ri­ety of as­sem­blers for the Amiga, but the scene al­ways favoured Seka, Asm-One and other de­riv­a­tives of the same con­cept. There were so many dif­fer­ent ver­sions and hacks (Trash’m-one, for ex­am­ple) that the sprawl­ing fam­ily tree ri­vals that of Unix sys­tems.

Here’s Seka 2.0, and as we can see, it’s based on a com­mer­cial as­sem­bler. This type of as­sem­bler al­ways asks the user for the size of the work­ing mem­ory to be al­lo­cated. They then en­ter a com­mand line mode, which can be used to ex­am­ine RAM mem­ory and CPU reg­is­ters, and load source files into the ed­i­tor proper.

Here’s AsmOne in one of its many in­car­na­tions. It’s quite sim­i­lar to Seka (in fact, it’s “Seka-Updated”), but has more built-in com­mands and pre­sum­ably other im­prove­ments as well (I’ve never been much of a coder). Interface-wise, it opens its own screen, as op­posed to run­ning in a win­dow on the de­fault Workbench screen.

What if you found a piece of cool mu­sic or graph­ics in, say, a game? What if you wanted to steal some sam­ples, or a sprite, or per­haps just save an en­tire tune for easy lis­ten­ing? Then you’d need a rip­per - a tool for hunt­ing through your com­put­er’s mem­ory, look­ing for rem­nants of such data af­ter quit­ting the game. There were tons of var­i­ous such rip­pers for the Amiga. Here’s Multi-Ripper, which has a fairly rep­re­sen­ta­tive set of fea­tures.

Here’s an­other type of rip­per, specif­i­cally writ­ten to look for Seka as­sem­bly sources in mem­ory af­ter the com­puter had crashed. The Amiga, like most other home com­put­ers, had no mem­ory pro­tec­tion, and demo cod­ing is a no­to­ri­ously crash-prone ac­tiv­ity. Saving of­ten was com­mon prac­tice, but even sea­soned coders some­times messed up and for­got. With a bit of luck, the code could be ex­tracted from mem­ory af­ter a warm re­boot.

Here’s an­other type of sine pre­cal­cu­la­tor, called The Sinus Creator. I have no idea if the num­bers I’ve en­tered in the screen­shot make sense, but the two-win­dow text in­ter­face is in­ter­est­ing. Of course, the re­sult can be saved as a Seka source file.

Music Trackers

Demo mu­sic has his­tor­i­cally been made in track­ers. Far from tra­di­tional no­ta­tion, a tracker lets the mu­si­cian en­ter tones along with var­i­ous mod­i­fiers and ef­fects in some­thing that’s more rem­i­nis­cent of a pro­gram­ming ed­i­tor rather than reg­u­lar com­pos­ing. They also let the user man­age in­stru­ments, whether sam­pled or syn­the­sized.

Sample-based track­ers on the Amiga have an even more sprawl­ing fam­ily tree than that of Amiga as­sem­blers, but they all orig­i­nate from Karsten Obarski’s com­mer­cial Ultimate Soundtracker from 1987. Being com­mer­cial and thus cost­ing money, it was soon picked apart by sceners, which re­sulted in NoiseTracker, which was then re­vamped into ProTracker, which in turn ex­ists in so many var­i­ous ver­sions and re-hashed hacks that it’s nigh im­pos­si­ble to keep track (heh) of. The sprawl is even sprawlier than that of Amiga as­sem­blers!

SoundMonitor 1.0 for the Commodore 64 (by Chris Huelsbeck) is­n’t strictly speak­ing a scene re­lease, and was­n’t called “tracker”. However, the in­ter­face (with one “track” per avail­able sound chan­nel) is what in­spired the pre­vi­ously men­tioned Ultimate Soundtracker, and is thus in­cluded here for pos­ter­ity and cor­rect­ness.

NoiseTracker by the Swedish duo Mahoney and Kaktus was­n’t the first, but it was im­mensely pop­u­lar and came to de­fine the tracker ex­pe­ri­ence for years to come. Its legacy lives on just not in Protracker on the Amiga, but on sev­eral other plat­forms as well.

Here’s Protracker’s file picker. Just like in NoiseTracker above, it’s ac­cessed by click­ing the “Disk Op.” but­ton in the rather dense in­ter­face. It’s hard to de­scribe what a strange ex­pe­ri­ence this UI de­liv­ers, be­cause it’s al­most - but not quite - in­tu­itive to some­one used to more main­stream Amiga pro­grams. It’s easy to misclick, mis­un­der­stand or just plain miss things. To il­lus­trate its idio­syn­cratic de­sign, take note of the ver­ti­cal EXIT but­ton, which quits back to the main menu. It’s con­ve­niently placed be­tween the up and down ar­rows used for scrolling the pur­ple file and di­rec­tory list­ing.

Here’s Digicomposer 1.0 for the Atari ST/e, which in turn builds on Noisetracker for the Atari. The in­ter­face is clearly more than just in­spired by its Amiga coun­ter­part. It’s but one of a whole menagerie of track­ers for the Atari ST, some “digi” (sample-based) like this one, some for YM-chip based mu­sic.

Fasttracker II for MS-DOS is iconic in its own right. With sup­port for Gravis UltraSound and other ad­vanced PC sound hard­ware, it has fea­tures for 16-bit sam­ples, bizarre amounts of sound chan­nels, and even lets the user play a sim­ple ver­sion of Snake if they so de­sire.

Abyss’ Highest Experience is a chip­tune tracker for the Amiga, in­tended to sound like the Commodore 64′s SID chip. The user in­ter­face is an in­ter­est­ing crossover be­tween Soundtracker and a more mod­ern, Workbench 2.0-like look.

I don’t know much about Megatizer for the Atari ST, but it sure does look cool!

JamCrackerPro for the Amiga es­chewed the tra­di­tional tracker UI and opted for a sys­tem-friendly, multi-win­dow in­ter­face.

Disk Copiers

In or­der to dis­trib­ute demos (and pi­rated soft­ware), disk copy­ing was a com­mon ac­tiv­ity on the scene. Commodore pro­vided a disk copier in AmigaOS, but it was­n’t al­ways up to the task of copy­ing demos and games that by­passed the file sys­tem by writ­ing di­rectly to the tracks of a floppy. Thus, spe­cial soft­ware was needed!

Like SoundMonitor, X-Copy is­n’t strictly a scene re­lease. Although orig­i­nally writ­ten by sceners, it was re­leased com­mer­cially and then heav­ily pi­rated on the scene. The promi­nently fea­tured grids con­tain one square for each track on the disk, dis­play­ing the sta­tus for copy­ing that par­tic­u­lar part of the floppy. When a copy was fin­ished (which could take some time), the pro­gram help­fully played a lit­tle “boing” sound.

X-Copy was re­leased in many ver­sions dur­ing the Amiga hey­days. Here’s X-Copy 3.0, ap­par­ently in an il­licit va­ri­ety dis­trib­uted by the crack­ing group Paradox.

Personally, I pre­ferred D-Copy, mostly be­cause I thought the user in­ter­face looked cool (and I still do). It is, as far as I know, a bona fide non-com­mer­cial scene prod­uct.

Other Tools

A short ar­ti­cle like this can only ever scratch the sur­face of the nu­mer­ous demo scene tools ever cre­ated. Here are but a few more var­i­ous tools and in­ter­faces, se­lected for be­ing in­ter­est­ing and/​or rep­re­sen­ta­tive of their kind.

This is Titanics Cruncher for the Amiga. A cruncher uses asym­met­ri­cal com­pres­sion of ex­e­cutable files. This saves space on disk, with the trade­off be­ing longer load­ing times, due to the de­crunch­ing (decompression) of the ex­e­cutable upon run­ning it. Several other crunch­ers ex­ist, and on a va­ri­ety of plat­forms.

Before the Internet, there was the Bulletin Board System, or BBS. Sceners were usu­ally in­ter­ested in Elite BBS:es, mean­ing ones that of­fered pi­rated soft­ware for down­load. There were few, if any, Elite BBS:es with­out cool ANSI (or PETSCII, on the C64) graph­ics, for ex­am­ple in an­i­mated menu screens. Thus, many var­i­ous ANSI ed­i­tors popped up for dif­fer­ent plat­forms. This is Digital Intelligence’s Ansi-Editor v2.4 for the Amiga, and it has a very pe­cu­liar user in­ter­face. The tool­bar at the bot­tom dis­plays the cur­rently ac­tive colours, but you can’t se­lect them from there. Click all you want, to no ef­fect - you have to use the pull-down menu to ac­tu­ally pick one.

Before Twitter, Facebook, IRC and even wide­spread ac­cess to modems and BBS:es, scroll texts were the com­mu­ni­ca­tion medium of choice for the scene. Cool scrollers re­quired cool fonts, and it could be help­ful with a ded­i­cated font (or charset) ed­i­tor. Here’s Charedit by Escape, for MS-DOS.

Home com­put­ers of­ten came with cus­tom or oth­er­wise es­o­teric hard­ware. The Atari Falcon, for ex­am­ple, sported a Motorola 56001 dig­i­tal sig­nal proces­sor. DSPdit by tSCc (short for The Sirius Cybernetics Corporation) is an ed­i­tor and as­sem­bler made specif­i­cally for DSP56k pro­gram­ming. It uses the stan­dard GEM toolkit, which gives it a very clean and pro­fes­sional look.

The first com­puter virus for the Amiga was a boot­block virus, in­fect­ing the boot sec­tor of floppy disks. As such, it could po­ten­tially ruin games and other flop­pies with cus­tom boot­blocks. It was con­structed by the Swiss Cracking Association, SCA. The virus spread like wild­fire and per­haps SCA was plagued by a guilty con­science, be­cause later they also pro­duced the very first virus killer for the Amiga - de­signed to counter their own virus. The mega-mighty in­ter­face is easy enough to grasp!

As men­tioned above, plenty of Amiga demos were so called track­mos, mean­ing they did­n’t use the file sys­tem, but rather stored data straight on the tracks of a floppy disk. This soon re­sulted in var­i­ous tool­ing be­com­ing avail­able for cre­at­ing such track­mos. Mostly it was just code shared be­tween sceners, but there were also com­plete soft­ware suites, like TrackmoDOS by Poison of NOVA. Among other things, it came with this or­tho­dox file man­ager for writ­ing and delet­ing files to a trackmo floppy. Being a scener tool, the GUI of course sports some rather spiffy colour gra­di­ents.

This is RAW, which is­n’t re­ally a tool, but rather a disk mag­a­zine, or diskmag. A diskmag is just that - a pe­ri­od­i­cal pub­lished on one or more floppy disks. Most of the ar­ti­cles were usu­ally scene re­lated, al­though some mags branched out and fea­tured every­thing from short sto­ries and po­ems to es­says about his­tory and pol­i­tics. RAW was one of the most pop­u­lar Amiga diskmags dur­ing the early 1990s, and as we can see, the UI was shiny and tex­tured long be­fore Frutiger Aero was a thing. It even came with a built-in palette ed­i­tor (pictured), al­low­ing the user to cus­tomize the text colours.

This is FuckPaint, a pixel painter for the Atari Falcon. It is in­cluded here solely on the merit of its name, and its equally classy “Analizer” tool.

Although not at all a scene pro­duc­tion, Deluxe Paint must be men­tioned here. To the best of my knowl­edge, the scene never pro­duced a pixel painter for the Amiga (except later ports of Grafx2), pre­sum­ably be­cause no­body saw the need for one. I don’t think a sin­gle Amiga user ex­isted that did­n’t have a copy of this soft­ware, ei­ther bought sep­a­rately, bun­dled with the ma­chine or just pi­rated. It was also com­pletely dom­i­nant on the PC. There were other Amiga pixel painters, such as Brilliance and Personal Paint, but their com­bined mar­ket share was a mere frac­tion of this gi­ant, which also dom­i­nated graph­ics cre­ation for games well into the the mid-1990s.

That’s enough demo scene in­ter­faces for one help­ing. For those still want­ing more, I rec­om­mend this gallery of utild­isk menus.

Take care and happy hack­ing!

If you man­aged to put Tailscale on a jail­bro­ken Kindle be­fore it up­dated too far ahead, you got some­thing pretty great, even if it was­n’t the full Tailscale ex­pe­ri­ence. But good things come to those who wait (or dig around on GitHub).

Open-source de­vel­op­ers have im­proved the Tailscale ex­pe­ri­ence on one of the weak­est com­put­ers you own. If your Kindle is jail­bro­ken, an up­dated ver­sion of Mitanshu Sukhwani’s Tailscale im­ple­men­ta­tion of­fers a few new things:

Tailscale SSH en­abled by de­fault, so you don’t have to en­able USBnetworking SSH and its very ob­vi­ous de­fault user/​pass­word

A proxy mode that lets apps like KOReader to reach other nodes on your tail­net, like a Calibre/OPDS or Wallabag server

A full TUN mode that, on some Kindles, can make Tailscale net­work­ing work at the de­vice level

Let’s dig into each one and how to set them up. As be­fore, this is com­mu­nity code work­ing on a very un­of­fi­cial de­vice state; bring your pa­tience along.

Tailscale on a Kindle, now with prox­ies

The last time we wrote about Tailscale on a Kindle, the client was ba­sic, but it worked. The Kindle showed up on your tail­net, com­plete with a green dot in the web ad­min con­sole. You could reach the Kindle by its Tailscale IP ad­dress. You could even SSH into the Kindle over Tailscale, which was handy for fur­ther tin­ker­ing.

But “reachable via Tailscale” is not the same as “routing all in­com­ing and out­go­ing traf­fic across your tail­net,” it turns out. Tailscale on a jail­bro­ken Kindle is typ­i­cally forced to run in user­space mode, which means it can­not use the de­vice’s own net­work rout­ing layer, known as TUN mode. You could start Tailscale, and then start an app like KOReader, but when you tried to con­nect to an­other Tailscale de­vice, like your Calibre server at 100.x.y.z, it would go like this:

KOReader (or any app) asks the Kindle’s root OS how to reach 100.x.y.z

The Kindle, lack­ing Tailscale rout­ing, can­not reach that Tailscale IP ad­dress

KOReader drops the con­nec­tion

An up­date to the Kindle KUAL app by grey­wolf1499 pro­vides dif­fer­ent modes that work around this. Now, when you try to reach an­other Tailscale IP ad­dress on your Kindle, it can go like this:

You start Tailscale in proxy mode

You set up KOReader or an­other ap­p’s proxy set­tings to con­nect to 127.0.0.1:1055

KOReader tells the proxy it wants to reach 100.x.y.z

Tailscale’s dae­mon tailscaled, lis­ten­ing on port 1055, routes the con­nec­tion through Tailscale

E-books, ar­ti­cles, and other data flows be­tween your Tailscale-running Kindle and other Tailscale de­vices

This Tailscale proxy of­fers two modes, SOCKS5 and HTTP CONNECT, for apps that may pre­fer one or the other. This opens up a good bit more util­ity for your more-con­nected Kindle.

What you can do with a prox­ied Kindle

A few wild ideas, de­pend­ing on how dug in you want to get:

Calibre or Wallabag servers, as men­tioned

Audiobookshelf con­nec­tion through KOReader

Use Readest to track read­ing progress across de­vices

Linking KOReader’s RSS reader to a a self-hosted feed server

Accessing min­i­mal­ist dash­boards and web pages in the (pretty bad) Kindle browser

Using a Bluetooth key­board and the kterm app to SSH into tail­net de­vices

Is that last one all that prac­ti­cal? Not re­ally. But is there a pleas­ant warmth, know­ing that you’ve added the least likely thin client to your what-if kit? For some types, types I know quite well: yes.

The Tailscale plu­gin for KOReader (with Kobo and PocketBook sup­port)

If you don’t re­ally need any Tailscale pow­ers out­side the highly ca­pa­ble KOReader app, check out this Tailscale KOReader plu­gin. It does­n’t make your Kindle ac­ces­si­ble over your tail­net, like the KUAL-based app. But it does au­to­mat­i­cally cre­ate the proxy in­ter­faces that are needed for reach­ing your con­tent servers from your KOReader-running Kindle—or your Kobo de­vice, or your PocketBook.

I haven’t been able to re­ally try this ex­ten­sion out my­self; my 11th-generation stan­dard Kindle does­n’t play well with it at the mo­ment. It’s been “Tested on Kindle PW5/PW6, Kobo, and PocketBook”—it’s nice to see Tailscale come to some other KOReader-friendly de­vices, too.

Installation is not too hard, at least if you made it this far into jail­break­ing al­ready. You copy the plu­gin into KOReader’s plu­g­ins di­rec­tory, trig­ger an “Install/Update Tailscale” from KOReader’s menu, copy a Tailscale key into a di­rec­tory, then tog­gle Tailscale on in the KOReader menu. From there, you con­fig­ure KOReader with one of its proxy ad­dresses (127.0.0.1:1055 for SOCKS5, :1056 for HTTP CONNECT), then give other plu­g­ins the Tailscale IP ad­dresses you need to reach.

Victoria Riley Barnett’s repos­i­tory notes that the plu­gin works great with a SyncThing plu­gin for KOReader. KOReader is like its own sep­a­rate OS for jail­bro­ken Kindles at this point,

So now you’ve got a lot more op­tions and weird pro­jects avail­able to you, through this al­ready quite-strange lit­tle slab. If you’ve worked up a weirdly use­ful Tailscale setup on your Kindle, Kobo, or other e-pa­per de­vice, we’d love to hear about it. Let us know on Red­dit, Dis­cord, Bluesky, X, Mastodon, or LinkedIn.

Published on 29/07/2026 – 12:04 GMT+2•Updated 13:49

French DJ Kavinsky has been found dead at his Paris home, ac­cord­ing to lo­cal au­thor­i­ties. The body of the 50-year-old, whose real name was Vincent Belorgey, was dis­cov­ered on Tuesday evening.

Kavinsky was a lead­ing fig­ure of the house mu­sic move­ment, ‘French touch’, along­side Daft Punk, Justice, Cassius and DJ Mehdi.

The Paris pros­e­cu­tor’s of­fice said that “an in­ves­ti­ga­tion to es­tab­lish the causes of death” had been opened, not­ing that no sus­pect was found at the scene on Tuesday evening.

“France has lost one of its most dis­tinc­tive voices”, French Culture Minister Catherine Pégard said in a mes­sage on so­cial me­dia net­work X. “Both dance­able and nos­tal­gic, his mu­sic will go on cross­ing gen­er­a­tions and bor­ders.”

One of his most pop­u­lar tracks was Nightcall, the dark, slow-tempo syn­th­wave hit in­cluded on the sound­track of Drive (2011), Nicolas Winding Refn’s Palme d’or win­ning neon-noir thriller star­ring Ryan Gosling. The track en­joyed a new lease of life dur­ing the Paris 2024 Olympic Games.

The DJ per­formed at the Stade de France along­side Belgian singer Angèle and pop-rock band Phoenix, who re­worked Nightcall for the oc­ca­sion dur­ing the Olympic clos­ing cer­e­mony.

A self-taught pi­anist born in Seine-Saint-Denis, Kavinsky launched his ca­reer in the early 2000s, open­ing in par­tic­u­lar for Daft Punk and shar­ing the stage with other emerg­ing names on the elec­tronic scene, such as SebastiAn. Kavinsky would have turned 51 on 31 July.

I would like to thank Microsoft prod­uct teams and Microsoft Security Response Center (MSRC) for col­lab­o­rat­ing with me on this tech­ni­cal analy­sis and mit­i­ga­tion of the dis­closed vul­ner­a­bil­i­ties. The ed­i­to­r­ial opin­ions re­flected be­low are solely the au­thor’s and do not nec­es­sar­ily re­flect those of the or­ga­ni­za­tions I col­lab­o­rated with.

I would like to thank Microsoft prod­uct teams and Microsoft Security Response Center (MSRC) for col­lab­o­rat­ing with me on this tech­ni­cal analy­sis and mit­i­ga­tion of the dis­closed vul­ner­a­bil­i­ties. The ed­i­to­r­ial opin­ions re­flected be­low are solely the au­thor’s and do not nec­es­sar­ily re­flect those of the or­ga­ni­za­tions I col­lab­o­rated with.

Summary

The find­ings de­scribed in this post are part of a co­or­di­nated dis­clo­sure with MSRC and Microsoft prod­uct teams. Microsoft was pro­vided with re­pro­duc­tion steps, videos, en­vi­ron­men­tal as­sump­tions, and the ex­act proof-of-con­cept (PoC) prompts used dur­ing test­ing. They were also in­formed of a 90-day co­or­di­na­tion pe­riod be­fore dis­clo­sure. This was ex­tended two times, re­sult­ing a 144-day co­or­di­na­tion pe­riod.

In parts 1 and 2 in this se­ries, I have shown how ex­ter­nal in­puts could in­flu­ence Copilot re­sponses and, in some cases, po­ten­tially lead to con­fi­den­tial­ity im­pacts through Cross-Domain Prompt Injection Attacks (XPIAs). This re­port builds on those find­ings and ex­tends the XPIA analy­sis from sin­gle-in­ter­ac­tion com­pro­mise to prop­a­ga­tion across trusted doc­u­ment work­flows. It shows that at­tacker-con­trolled in­struc­tions in one doc­u­ment can be copied into Copilot-generated or Copilot-edited Word doc­u­ments, caus­ing those down­stream doc­u­ments to be­come new car­ri­ers of the same at­tack.

Previous ex­am­ples of AI-worms ex­ist. Notably, Morris II demon­strated self-repli­cat­ing prompt prop­a­ga­tion in GenAI-powered email-as­sis­tant ecosys­tems. However, to my knowl­edge, this is among the first pub­lic demon­stra­tions of doc­u­ment-borne AI-worm self-prop­a­ga­tion through nor­mal work­flows in a main­stream com­mer­cial pro­duc­tiv­ity suite.

The re­ported sce­nario is:

Malicious in­struc­tions hid­den in an ex­ter­nally shared doc­u­ment could make Copilot al­ter drafted or edited doc­u­ments in Word and prop­a­gate the at­tack to new doc­u­ments.

The full at­tack in brief

The at­tack

An at­tacker places hid­den in­struc­tions in a doc­u­ment that is later used as source ma­te­r­ial in Copilot for Word. Copilot may in­ter­pret those in­struc­tions as part of the user’s re­quest, caus­ing it to ma­nip­u­late the doc­u­ment be­ing drafted or edited. Copilot may then also copy the hid­den in­struc­tions into the re­sult­ing doc­u­ment, turn­ing that doc­u­ment into a new car­rier. If the car­rier is sub­se­quently used in an­other Copilot-assisted work­flow, the in­struc­tions can trig­ger again and prop­a­gate into fur­ther doc­u­ments, even with­out the at­tack­er’s orig­i­nal doc­u­ment be­ing pre­sent.

Example

Consider an em­ployee prepar­ing a fi­nan­cial re­port. The em­ployee down­loads a mar­ket analy­sis from a trusted web­site that has been com­pro­mised, un­aware that the doc­u­ment con­tains hid­den in­struc­tions. The em­ployee then in­cludes the analy­sis as source ma­te­r­ial when draft­ing the re­port with Copilot. The hid­den in­struc­tions cause Copilot to al­ter in­ter­nal fig­ures in the fi­nan­cial re­port and copy the at­tack into the new doc­u­ment. The em­ployee saves and shares the ap­par­ently le­git­i­mate re­port in­ter­nally. Later, a col­league uses it as source ma­te­r­ial for an­other re­port; the in­struc­tions trig­ger again, al­ter the new re­port, and copy them­selves for­ward. The at­tack can there­fore con­tinue with­out fur­ther in­volve­ment from ei­ther the com­pro­mised web­site or the orig­i­nal ma­li­cious doc­u­ment. As af­fected re­ports are reused, ad­di­tional re­ports and doc­u­ments can be­come car­ri­ers of the at­tack.

Disclosure sta­tus at pub­li­ca­tion

Vendor: Microsoft

Coordinated dis­clo­sure: Handled through MSRC and Microsoft prod­uct teams

Included in this post: XPIA and self-prop­a­ga­tion sce­nario in Microsoft Copilot for Word

Customer ac­tion: No cus­tomer-side re­me­di­a­tion fully ad­dresses the is­sue at the time of pub­li­ca­tion. Customers can re­duce ex­po­sure by:Treat­ing ex­ter­nally sourced doc­u­ments as un­trusted when used with Copilot.Reviewing any at­tached doc­u­ment be­fore start­ing a Copilot gen­er­a­tion or edit.Care­fully re­view­ing Copilot-generated or Copilot-edited doc­u­ments be­fore reusing, shar­ing, or dis­trib­ut­ing them.

Treating ex­ter­nally sourced doc­u­ments as un­trusted when used with Copilot.

Reviewing any at­tached doc­u­ment be­fore start­ing a Copilot gen­er­a­tion or edit.

Carefully re­view­ing Copilot-generated or Copilot-edited doc­u­ments be­fore reusing, shar­ing, or dis­trib­ut­ing them.

Microsoft-side sta­tus: Testing has re­pro­duced the at­tack with all cur­rent mit­i­ga­tions de­ployed. At the time of pub­li­ca­tion, no ro­bust mit­i­ga­tion for the broader vul­ner­a­bil­ity class is avail­able.

A note on dis­clos­ing be­fore a fix

Unlike Parts 1 and 2, this sce­nario re­mains ex­ploitable at pub­li­ca­tion. I have weighed that care­fully. The co­or­di­na­tion pe­riod agreed with Microsoft has been ex­hausted, and test­ing shows that no ro­bust mit­i­ga­tion for the broader vul­ner­a­bil­ity class is cur­rently avail­able. Two mit­i­ga­tion at­tempts, in­clud­ing a model up­grade, did not close the class.

I have there­fore cho­sen to dis­close at the class level rather than the pay­load level. My rea­son­ing is that de­fend­ers can­not re­duce ex­po­sure to a risk they are un­aware of, and the prop­a­ga­tion mech­a­nism de­scribed here af­fects or­di­nary doc­u­ment work­flows that many or­ga­ni­za­tions al­ready rely on. Withholding the ex­is­tence of the is­sue would leave those or­ga­ni­za­tions un­able to make an in­formed de­ci­sion, while pro­vid­ing no ad­di­tional pro­tec­tion.

Disclosure time­line

2026 – 03-06: Initial re­port sub­mit­ted to MSRC with re­pro­duc­tion steps, videos, en­vi­ron­men­tal as­sump­tions, and PoC prompts.

2026 – 03-09: MSRC ac­knowl­edged re­ceipt and opened a case.

2026 – 03-31: Microsoft con­firms the re­ported be­hav­ior.

2026 – 03-31: Microsoft prod­uct teams be­gan mit­i­ga­tion work; on­go­ing tech­ni­cal dis­cus­sion.

2026 – 04-03: First mit­i­ga­tion go-live (The new “Edit with Copilot” ex­pe­ri­ence)

2026 – 04-09: Original at­tack prompt word­ing ver­i­fied mit­i­gated with “Edit with Copilot”.

2026 – 04-09: Attack be­hav­ior re­pro­duced in “Edit with Copilot” us­ing a new XPIA prompt task (manipulating fi­nan­cials). Reported as sep­a­rate case to MSRC.

2026 – 04-10: MSRC ac­knowl­edged re­ceipt and opened a case.

2026 – 04-10: Microsoft prod­uct teams be­gan mit­i­ga­tion work; on­go­ing tech­ni­cal dis­cus­sion.

2026 – 06-08: At Microsoft’s re­quest, pub­lic dis­clo­sure was moved to 2026 – 07-15.

2026 – 07-14: Second mit­i­ga­tion fix go-live. This mit­i­ga­tion con­sisted of up­grad­ing the un­der­ly­ing model to GPT-5.5.

2026 – 07-15: Successful ex­ploit with worm­ing re­pro­duced us­ing GPT-5.6, the lat­est avail­able model at the time.

2026 – 07-15: I sug­gest we post­pone dis­clo­sure a fur­ther two weeks to 2026 – 07-28, to al­low time for a new mit­i­ga­tion.

2026 – 07-15: Microsoft agreed.

2026 – 07-28: Attack still re­pro­duces.

2026 – 07-28: Coordinated pub­lic dis­clo­sure (this post).

Threat model

The at­tacker does not need ac­cess to the vic­tim’s Microsoft 365 ten­ant. The at­tacker only needs to share a ma­li­cious doc­u­ment with the vic­tim. This can be done through SharePoint, Teams, Outlook or any other way of shar­ing doc­u­ments.

Security bound­ary and ob­served be­hav­ior

The rel­e­vant se­cu­rity bound­ary in this sce­nario is the bound­ary be­tween at­tached doc­u­ments and the cur­rent draft­ing doc­u­ment. If any of the at­tached doc­u­ments con­tain an XPIA the at­tack may trig­ger.

Copilot must read every at­tached doc­u­ment to de­ter­mine which parts to in­clude in its cur­rent draft­ing task. However, at­tached doc­u­ments should be treated as un­trusted in­for­ma­tion, not trusted user in­struc­tion.

Boundary vi­o­la­tion Attacker-controlled doc­u­ments are down­loaded or shared through email/​share­point/​other shar­ing op­tion. If such doc­u­ments are at­tached to Copilot dur­ing a draft­ing task, trust is bro­ken.

Expected be­hav­ior When a user asks Copilot to draft e.g. a Q1 fi­nan­cial re­port based on at­tached doc­u­ments, Copilot should uti­lize the in­for­ma­tion in the at­tached doc­u­ments with­out treat­ing in­struc­tions em­bed­ded within doc­u­ments as au­thor­i­ta­tive in­struc­tions.

Observed be­hav­ior Instructions em­bed­ded in doc­u­ments cause Copilot to al­ter its be­hav­ior. Here pre­sented as: 1: Copilot silently chang­ing nu­mer­i­cal val­ues in fi­nan­cial re­ports 2: Copilot prop­a­gat­ing the full XPIA by past­ing into down­stream doc­u­ments, which may then be used as at­tach­ments in later draft­ing ses­sions\

Crossing the trust bound­ary in Word

The ini­tial at­tack vec­tor for these sce­nar­ios uses a ma­li­cious doc­u­ment. The ma­li­cious doc­u­ment con­tains a JSON-formatted ma­li­cious prompt that trig­gers the at­tack when the doc­u­ment is in­cluded in Copilot’s con­text. The prompt can be ren­dered as white text on a white back­ground and in a small font size to con­ceal it from the vic­tim. Since Copilot for Word strips all text for­mat­ting like color and font size be­fore pass­ing the text into the un­der­ly­ing Large Language Model (LLM), this text re­mains fully read­able to Copilot even though the vic­tim can­not see it. The at­tack can be fur­ther con­cealed by em­bed­ding it in a seem­ingly be­nign doc­u­ment with task-rel­e­vant text.

This at­tack re­quires the ma­li­cious doc­u­ment to be in­cluded as part of Copilot’s con­text in Word. Thus, de­pend­ing on the ver­sion of Copilot in use, the vic­tim must ei­ther:

Actively at­tach or up­load the doc­u­ment in Copilot for Word.

Use the “Edit with Copilot” func­tion­al­ity in work/​Work IQ mode and let Copilot find the ma­li­cious doc­u­ment in the vic­tim’s OneDrive. In this case, Copilot must deem the doc­u­ment rel­e­vant and in­clude it in the con­text. An at­tacker there­fore needs to craft a doc­u­ment that in­creases the like­li­hood of ei­ther or both.

The ex­ploit is rel­e­vant both for the “magic pen” and the “Edit with Copilot” func­tion­al­i­ties in Word.

The at­tack hap­pens in two stages. The first stage es­tab­lishes foothold and in the sec­ond stage the at­tack self-prop­a­gates across doc­u­ments that use Copilot for Word as part of draft­ing or edit­ing.

Stage 1:

In the first stage the at­tacker has crafted a doc­u­ment that con­tains a ma­li­cious hid­den prompt. In my ini­tial PoC I used a doc­u­ment that only con­tained the ma­li­cious prompt as white text on white back­ground. This was done to il­lus­trate that the ma­li­cious doc­u­ment did not need to be rel­e­vant to the vic­tim’s task for Copilot to use it. If it was in­cluded in the con­text, it is read and there­fore the at­tack may trig­ger.

The PoC prompt was struc­tured in two parts:

The first part con­tained the in­struc­tions on how to af­fect a doc­u­ment. This could range from slightly chang­ing mean­ings of sum­maries to al­ter­ing num­bers in fi­nan­cial doc­u­ments. The key was for­mu­lat­ing the prompt in a way that made Copilot be­lieve it was task-rel­e­vant and be­nign. In many of my ex­per­i­ments I ac­tu­ally needed to also in­struct Copilot to high­light which changes it made, since they were of­ten mean­ing­ful changes that were dif­fi­cult to spot. This shows how ef­fec­tive the at­tack is at sub­tly chang­ing the text in mean­ing­ful ways that eas­ily elude even an at­ten­tive re­viewer. In a real-world set­ting, the at­tacker would ob­vi­ously not in­clude such in­struc­tions. For the rest of this dis­clo­sure, there­fore, I’ll use al­ter­ing num­bers in fi­nan­cial re­ports since that is an im­me­di­ately vis­i­ble change.

The first part con­tained the in­struc­tions on how to af­fect a doc­u­ment. This could range from slightly chang­ing mean­ings of sum­maries to al­ter­ing num­bers in fi­nan­cial doc­u­ments. The key was for­mu­lat­ing the prompt in a way that made Copilot be­lieve it was task-rel­e­vant and be­nign. In many of my ex­per­i­ments I ac­tu­ally needed to also in­struct Copilot to high­light which changes it made, since they were of­ten mean­ing­ful changes that were dif­fi­cult to spot. This shows how ef­fec­tive the at­tack is at sub­tly chang­ing the text in mean­ing­ful ways that eas­ily elude even an at­ten­tive re­viewer. In a real-world set­ting, the at­tacker would ob­vi­ously not in­clude such in­struc­tions. For the rest of this dis­clo­sure, there­fore, I’ll use al­ter­ing num­bers in fi­nan­cial re­ports since that is an im­me­di­ately vis­i­ble change.

The sec­ond part con­tained the in­struc­tions to self-prop­a­gate the at­tack. The ex­act word­ing also mat­ters here, but it was gen­er­ally framed as serv­ing the pur­pose of track­ing sources in down­stream doc­u­ments. It also con­tained in­struc­tions on how to hide it­self, framed as in­struc­tions to im­prove read­abil­ity.

The sec­ond part con­tained the in­struc­tions to self-prop­a­gate the at­tack. The ex­act word­ing also mat­ters here, but it was gen­er­ally framed as serv­ing the pur­pose of track­ing sources in down­stream doc­u­ments. It also con­tained in­struc­tions on how to hide it­self, framed as in­struc­tions to im­prove read­abil­ity.

Figure 1: The ini­tial at­tack vec­tor doc­u­ment. I cre­ated a full mock com­pany named Tfosorcim Ltd. for this PoC, with mock eco­nom­ics and vi­sion. This at­tack vec­tor doc­u­ment is a fake mar­ket analy­sis made us­ing in­for­ma­tion about the com­pany that would typ­i­cally be avail­able to an at­tacker. The at­tack is ap­pended at the end of the doc­u­ment us­ing white text. [Most of the XPIA text is blurred for se­cu­rity]

Once this ma­li­cious doc­u­ment was in­cluded in the con­text when draft­ing or edit­ing a doc­u­ment with Copilot for Word, the at­tack would trig­ger and Copilot would ex­e­cute the in­struc­tions. Thus, the af­fected doc­u­ment would have fi­nan­cial num­bers changed. Copilot would then also copy the en­tire ma­li­cious prompt into the bot­tom of the af­fected doc­u­ment us­ing white text and font size 8, ef­fec­tively con­ceal­ing it from the vic­tim.

Figure 2: The down­stream draft gen­er­ated by Copilot used my ma­li­cious doc­u­ment as an at­tach­ment ([att] Direct wmr.docx). In the re­sult­ing Q1 fi­nan­cial re­port draft, all fi­nan­cial num­bers are halved. The screen­shot also shows other at­tached doc­u­ments (Tfosorcim in­ter­nal doc­u­ments).

Figure 3: The fig­ure demon­strates that GPT-5.6, the lat­est model from OpenAI at the time of writ­ing, was used in these PoCs.

Figure 4: After hav­ing halved all fi­nan­cial num­bers in the Q1 fi­nan­cial re­port draft, Copilot also ap­pends the full at­tack prompt us­ing white text to ef­fec­tively con­ceal it from the vic­tim. It also makes no men­tion about its halv­ing of num­bers or that it in­cludes the at­tack. Thus, the vic­tim is clue­less of it. [Most of the XPIA text is blurred for se­cu­rity]

Figure 5: Copilot does not re­quire the vic­tim to at­tach the ma­li­cious doc­u­ment though. In this screen­shot the vic­tim only in­structs Copilot to write a Tfosorcim Q1 fi­nan­cial re­port. Copilot then searches through the vic­tim’s OneDrive to find rel­e­vant doc­u­ments. Among the doc­u­ments, we find the ma­li­cious Market Analysis doc­u­ment. This doc­u­ment does not re­side in the same folder as the rest of the Tfosorcim doc­u­ment. However, Copilot still finds it, reads it and is suc­cess­fully ex­ploited.

Stage 2:

Stage two is the self-prop­a­ga­tion stage. It re­lies en­tirely on the in­struc­tion for Copilot to copy the ma­li­cious prompt into the af­fected doc­u­ment. Once the af­fected doc­u­ment con­tained the prompt, the new doc­u­ment it­self be­came the new at­tack vec­tor.

Figure 6: The screen­shot shows a new draft­ing ses­sion us­ing Copilot. This time the orig­i­nal at­tack vec­tor is no longer in­cluded among the at­tach­ments. However, the pre­vi­ously cre­ated doc­u­ment is (Tfosorcim Q1 2026 re­port.docx). The re­sult is the same, and Copilot again halves all fi­nan­cial num­bers in the drafted Q2 fi­nan­cial re­port.

Figure 7: In ad­di­tion to halv­ing all fi­nan­cial num­bers, Copilot adds the full at­tack prompt, again us­ing white text. Thus, the at­tack prop­a­gates through Word doc­u­ments, ef­fec­tively cre­at­ing a doc­u­ment-borne AI worm. [Most of the XPIA text is blurred for se­cu­rity].

Of note, this new at­tack vec­tor is now an in­ter­nally cre­ated doc­u­ment, with all the trust that fol­lows. Thus, the vic­tim needs only share this doc­u­ment with cowork­ers for the at­tack to spread. If the vic­tim or a col­league then uses the af­fected doc­u­ment as an at­tach­ment to Copilot for Word while draft­ing or edit­ing, the at­tack spreads to these new doc­u­ments.

In all re­ported PoC sce­nar­ios, Copilot would al­ter gen­er­ated or edited doc­u­ments and copy the hid­den in­struc­tion into these doc­u­ments. When these doc­u­ments were them­selves used as part of the con­text for new down­stream doc­u­ments, the at­tack trig­gered again. Note that for the sec­ond phase, the orig­i­nal at­tack doc­u­ment was no longer part of the at­tach­ments for the new down­stream doc­u­ments, yet the at­tack trig­gered and spread to these as well.

Impact

Since the at­tack is able to spread through in­ter­nal doc­u­ments, once it has moved be­yond its ini­tial point of en­try, the trace­abil­ity of the at­tack be­comes ex­tremely dif­fi­cult. This is fur­ther ex­ac­er­bated by each doc­u­ment be­ing cre­ated by a le­git­i­mate in­ter­nal re­source and that Copilot ed­its are not made vis­i­ble af­ter they have been ap­proved by the vic­tim. The broader con­cern is that, if the at­tack silently spread within an or­ga­ni­za­tion through or­di­nary doc­u­ment work­flows, it could erode the in­for­ma­tional foun­da­tion on which or­ga­ni­za­tions make de­ci­sions.

In ad­di­tion, or­ga­ni­za­tions that are not aware that they are af­fected by the at­tack are also likely to spread it to other or­ga­ni­za­tions through col­lab­o­ra­tive ef­forts on shared Microsoft SharePoint sites or shared Microsoft Teams. Thus, the ini­tial at­tack vec­tor for a par­tic­u­lar or­ga­ni­za­tion may ac­tu­ally come from an al­ready af­fected trusted part­ner. This again in­creases like­li­hood of the vic­tim choos­ing to in­clude the af­fected doc­u­ment in the Copilot for Word con­text dur­ing draft­ing.

Recently Copilot is also be­com­ing more deeply in­te­grated with sys­tems such as Microsoft Cowork or Microsoft Scout, which ex­tend the as­sis­tant to au­to­matic ma­nip­u­la­tion and cre­ation of doc­u­ments, tools, and col­lab­o­ra­tive work­flows. In such sys­tems the prac­ti­cal im­pact of the is­sues de­scribed here may scale rapidly. The un­der­ly­ing mech­a­nism re­mains the same, but the po­ten­tial sur­face over which it can prop­a­gate or in­flu­ence ex­pands at ma­chine speed.

Mitigating the vul­ner­a­bil­i­ties

Microsoft suc­cess­fully mit­i­gated the orig­i­nally sub­mit­ted PoC prompt, and de­ployed mul­ti­ple fixes over the course of this dis­clo­sure. Each of these raised the bar by clos­ing the spe­cific pay­loads re­ported, and re­pro­duc­ing the be­hav­ior af­ter­wards re­quired al­tered pay­loads rather than reusing the old ones di­rectly.

The orig­i­nal re­port, how­ever, also de­scribed the broader vul­ner­a­bil­ity class, in which in­struc­tions em­bed­ded in a source doc­u­ment could in­flu­ence Copilot’s gen­er­a­tion and copy them­selves into down­stream doc­u­ments. Changing the re­quested ac­tion or word­ing changes the pay­load, but not the un­der­ly­ing vul­ner­a­bil­ity or prop­a­ga­tion mech­a­nism. Using a mod­i­fied pay­load, the com­plete at­tack chain has been re­pro­duced with all mit­i­ga­tions de­ployed (the PoC in this re­port is one such case). The vul­ner­a­bil­ity class there­fore re­mains ex­ploitable at the time of pub­li­ca­tion.

That the class is not yet fully closed re­flects how hard the un­der­ly­ing prob­lem is. As the clos­ing thoughts dis­cuss, the weak­ness is ar­chi­tec­tural and shared across cur­rent LLM-based sys­tems. I’m not aware of a com­plete mit­i­ga­tion for this class in any com­pa­ra­ble prod­uct to­day. Fully re­solv­ing it re­quires re­search rather than a sin­gle patch. Within those lim­its, Microsoft’s fixes mean­ing­fully re­duce ex­po­sure, and the mem­ory and email-body vec­tors cov­ered in Parts 1 and 2 were mit­i­gated out­right. I would like to thank Microsoft for their con­tin­ued and sub­stan­tive ef­fort on a gen­uinely dif­fi­cult prob­lem.

Implications

Taken to­gether with the two pre­vi­ous parts in this se­ries, these find­ings point to a broader is­sue in mod­ern work en­vi­ron­ments. Namely that the in­tegrity of in­for­ma­tion be­comes a pri­mary se­cu­rity con­cern in sys­tems that in­te­grate LLMs as part of their op­er­at­ing work­flows. The sce­nar­ios pre­sented show that at­tacker-con­trolled con­tent can not only in­flu­ence in­di­vid­ual out­puts and po­ten­tially leak in­for­ma­tion. The at­tacks them­selves can also be repli­cated and self-prop­a­gate through nor­mal user work­flows.

This in­tro­duces chal­lenges that ex­tend well be­yond ini­tial ex­ploita­tion. Once ma­li­cious in­struc­tions are em­bed­ded in gen­er­ated con­tent, they may per­sist across doc­u­ments, be re­dis­trib­uted by le­git­i­mate users, and be rein­tro­duced into new con­texts. At that point, the at­tack is no longer de­pen­dent on its orig­i­nal en­try point. It has in­stead be­come part of the sys­tem’s in­ter­nal in­for­ma­tion flow.

A re­lated im­pli­ca­tion is the loss of trace­abil­ity. Since af­fected con­tent is gen­er­ated and mod­i­fied through le­git­i­mate work­flows, the ori­gin of the ma­nip­u­la­tion be­comes dif­fi­cult to iden­tify af­ter the fact. This com­pli­cates both de­tec­tion and re­sponse, par­tic­u­larly in en­vi­ron­ments where such con­tent is widely shared.

Independently of prompt-in­jec­tion pre­ven­tion, gen­er­ated doc­u­ments should pre­serve prove­nance for source ma­te­r­ial and model-per­formed ed­its in meta­data. Such con­trols would not pre­vent the un­der­ly­ing in­jec­tion, but they could make trace­abil­ity much eas­ier.

Closing thoughts

The find­ings in this se­ries point be­yond any sin­gle prod­uct or im­ple­men­ta­tion. They ex­pose a broader ar­chi­tec­tural weak­ness in cur­rent LLM-based sys­tems.

For AI-assistants to be use­ful, they of­ten must process emails, doc­u­ments, web­pages, mem­o­ries, tool out­puts, and other in­for­ma­tion that may be con­trolled by an at­tacker. To process that in­for­ma­tion, it must be in­cluded in the mod­el’s con­text win­dow, where it par­tic­i­pates in the same com­pu­ta­tion as sys­tem in­struc­tions, user re­quests, and other trusted in­for­ma­tion.

This cre­ates a fun­da­men­tal prob­lem: the LLM must process ex­ter­nal con­tent to de­ter­mine what it means, whether it is rel­e­vant, and whether it con­tains an at­tack. But by the time it makes that de­ter­mi­na­tion, the at­tacker-con­trolled to­kens are al­ready in­flu­enc­ing the com­pu­ta­tion that pro­duces it. The con­tent be­ing in­spected par­tic­i­pates in the act of in­spec­tion. Relying on the model to de­tect XPIAs there­fore re­sem­bles ask­ing an in­ter­preter to ex­e­cute an un­trusted pro­gram to de­ter­mine whether that pro­gram is safe to ex­e­cute.

Detecting and re­mov­ing ma­li­cious con­tent be­fore it reaches the tar­get model merely moves the same prob­lem out­ward.

Because LLMs can re­cover se­man­tics across rad­i­cally dif­fer­ent rep­re­sen­ta­tions, an ef­fec­tive de­tec­tor must pos­sess com­pa­ra­ble se­man­tic re­cov­ery ca­pa­bil­i­ties. A de­tec­tor weaker than the tar­get LLM will cover a smaller rep­re­sen­ta­tional space, leav­ing ma­li­cious for­mu­la­tions that the tar­get un­der­stands but the de­tec­tor fails to rec­og­nize.

The only gen­er­ally avail­able tech­nol­ogy with com­pa­ra­ble se­man­tic ca­pa­bil­i­ties is an­other LLM. Placing one model in front of an­other may re­duce the suc­cess rate of par­tic­u­lar at­tacks, but it cre­ates an “LLMs all the way down” prob­lem, where every LLM in­tro­duced to pro­tect an­other LLM must it­self be pro­tected.

The long-term chal­lenge likely lies in de­sign­ing sys­tems in which goals and in­ten­tions also ex­ist in­de­pen­dently of the in­for­ma­tion be­ing processed. Current LLM ar­chi­tec­tures pro­vide no re­li­able sep­a­ra­tion be­tween in­ten­tion and in­ter­pre­ta­tion. Thus, in cur­rent sys­tems with em­bed­ded LLMs, at­tacker-con­trolled in­for­ma­tion can in­flu­ence not only what the model pro­duces, but what the model be­lieves it has been asked to pro­duce.

For that rea­son, any sys­tem that in­te­grates an LLM into a trusted work­flow to­day must as­sume that at­tacker-con­trolled con­tent en­ter­ing the mod­el’s con­text will re­sult in com­pro­mise at some rate.

Change Log

The fol­low­ing is a change log that shows which part of this post have been changed and at what time. Spelling mis­takes and sim­i­lar er­rors will not be logged. However, I will strive to in­clude any mean­ing­ful changes to the post.

View PDF HTML (experimental)

Abstract:Language-model agents are in­creas­ingly de­ployed un­der stand­ing in­struc­tions: a sys­tem prompt, a pol­icy file, or a skills doc­u­ment is placed in con­text, and the agent is trusted to let it gov­ern every ac­tion that fol­lows. Existing bench­marks rarely test this de­ploy­ment pat­tern di­rectly; they mea­sure whether an agent can com­plete a task, not whether a long, bind­ing pol­icy doc­u­ment ac­tu­ally con­strains its be­hav­ior over an ex­tended tool-use hori­zon. We pre­sent this http URL, a bench­mark of 65 agen­tic tasks mod­eled on how en­ter­prise em­ploy­ees fol­low com­pany hand­books. Each task places an agent in a self-con­tained com­pany en­vi­ron­ment, a file work­space to­gether with mock email, chat, cal­en­dar, is­sue-track­ing, and com­merce ser­vices ex­posed over the Model Context Protocol, and in­structs it to carry out rou­tine pro­fes­sional work gov­erned by an ex­pert-writ­ten stan­dard op­er­at­ing pro­ce­dure of 20 to 124 pages. Tasks span five do­mains (finance, med­ical billing, in­sur­ance, lo­gis­tics, and HR) and ten fic­tional com­pa­nies. To re­sist mem­o­riza­tion, every task mod­i­fies one of ten base hand­books, al­ter­ing the spe­cific rules and thresh­olds on which grad­ing turns, so no two tasks share a pol­icy. Grading is fully de­ter­min­is­tic: each task car­ries a rubric of pro­gram­matic cri­te­ria (824 in to­tal) that check both that re­quired ac­tions oc­curred and that pro­hib­ited ac­tions did not. Under strict grad­ing, where a trial passes only if every cri­te­rion is sat­is­fied, the best of thirty eval­u­ated model con­fig­u­ra­tions passes 36.2% of tri­als, and most fron­tier con­fig­u­ra­tions re­main be­low 25%. Failures fol­low con­sis­tent pat­terns: agents let a plau­si­ble in-en­vi­ron­ment re­quest over­ride the stand­ing pol­icy, per­form a re­quired check and then act against its re­sult, lose rule de­tails over long hori­zons, and re­port com­pli­ance they did not achieve. We re­lease all tasks, en­vi­ron­ments, and the eval­u­a­tion har­ness.

arXiv-is­sued DOI via DataCite (pending reg­is­tra­tion)

Submission his­tory

From: Sushant Mehta [view email] [v1] Tue, 28 Jul 2026 07:58:07 UTC (57 KB)

A new AI com­pany

Conventional wis­dom says AI will re­place peo­ple. I be­lieve the op­po­site.

Andrew Ng · Founder & CEO

AI is cre­at­ing un­prece­dented op­por­tu­ni­ties for every­one. LearnVector helps peo­ple build skills so every per­son can take part.

$100M in­vest­ment from Coursera

Our mis­sion

To ac­cel­er­ate hu­man de­vel­op­ment.

AI will be the great­est ac­cel­er­a­tor of hu­man de­vel­op­ment — if we do it right.

The chal­lenge

For most of his­tory, great teach­ing has been scarce.

Rationed by cost, ge­og­ra­phy, and time. We have al­ways known that one per­son with a good teacher learns more — and faster — than the same per­son in a class­room of two hun­dred. We built the class­rooms any­way, be­cause we could­n’t give each per­son their own tu­tor. That was not a lim­i­ta­tion of learn­ing. It was a lim­i­ta­tion of eco­nom­ics.

Despite enor­mous progress in AI, we still have not changed how we learn. Learning ex­pe­ri­ences are still one‑to‑many.

And we know that

chat­bots with­out guardrails harm learn­ing.

A chat­bot can give you an an­swer, but an an­swer is not an ed­u­ca­tion. Cognitive of­fload­ing means you end up learn­ing less. And, you can­not al­ways trust what a chat­bot tells you.

Meanwhile the de­mand for trust­wor­thy learn­ing — know­ing that what you learn is ac­cu­rate, im­por­tant, and rel­e­vant — has never been higher.

The re­sult

Three things change.

The model

One‑to‑many

One‑to‑one

A per­sonal learn­ing ex­pe­ri­ence for every­one.

The model

One‑to‑many

One‑to‑one

A per­sonal learn­ing ex­pe­ri­ence for every­one.

The ex­pe­ri­ence

Labor

Love

Learning that’s en­gag­ing and fun — that you want to do.

The ex­pe­ri­ence

Labor

Love

Learning that’s en­gag­ing and fun — that you want to do.

The habit

Occasional

Daily

Learning that feels like an in­stinct, not a chore.

The habit

Occasional

Daily

Learning that feels like an in­stinct, not a chore.

What we’re build­ing

A trust­wor­thy guide for learn­ing.

A chat­bot can give you an an­swer, then it moves on. We’re build­ing a one‑to‑one learn­ing ex­pe­ri­ence that…

01Plans a path with you

Plans a path with you

02Adapts to how you learn

Adapts to how you learn

03Patiently stays with you un­til you’ve mas­tered new skills

Patiently stays with you un­til you’ve mas­tered new skills

We’re heads‑down build­ing, and will have prod­ucts to show by early 2027.

A mes­sage from Andrew

Why I’m do­ing this.

Fifteen years ago, Coursera and on­line courses changed ed­u­ca­tion. It worked bet­ter than al­most any­one ex­pected, ex­pand­ing ac­cess by open­ing up where you can learn. But how you learn re­mains largely the same as it has for cen­turies: it is one-size-fits-all courses, taught the same way to each per­son who shows up.

We now have an op­por­tu­nity to change how learn­ing hap­pens. With ad­vances in AI, we can now build a cus­tom learn­ing guide for each per­son. We will turn learn­ing from one‑to‑many to one‑to‑one. I’m start­ing LearnVector to in­vent this next gen­er­a­tion of learn­ing. We are start­ing with an in­vest­ment from Coursera, and plan to col­lab­o­rate closely with Coursera and Udemy.

Good learn­ing needs much more than just a chat­bot. Research shows that chat­bots with­out guardrails harm learn­ing. They help com­plete tasks and en­able stu­dents to do bet­ter on home­work. But cog­ni­tive of­fload­ing to a chat­bot re­sults in them be­ing less skilled.

In con­trast, LearnVector will plan a path with you, adapt to how you learn, and pa­tiently stay with you un­til you’ve mas­tered new skills.

One thing has not changed in all this time. People want learn­ing they can trust: ma­te­r­ial that is ac­cu­rate, rel­e­vant, and worth the ef­fort you put into it. Anything less wastes the most valu­able thing a learner has: time. Coursera has a trusted li­brary of ma­te­ri­als from au­thor­i­ta­tive sources. LearnVector plans to work with Coursera to bring this trust­wor­thy learn­ing to every­one. I’m grate­ful to Greg Hart and the en­tire Coursera team for sup­port­ing LearnVector.

I look for­ward to work­ing with our tal­ented team to change how we learn, and ac­cel­er­ate hu­man de­vel­op­ment.

Andrew Ng

Founder & CEO, LearnVector

From Coursera

Our strate­gic in­vest­ment in LearnVector has the po­ten­tial to be a force mul­ti­plier for our growth. Andrew’s un­matched AI ex­per­tise pairs his agen­tic AI with our plat­form and as­sets that turn learn­ing into val­i­dated mas­tery — a clear com­pet­i­tive ad­van­tage that we be­lieve can ac­cel­er­ate our busi­ness and ex­pand the im­pact we de­liver for in­di­vid­u­als and en­ter­prises around the world.

Read Coursera’s an­nounce­ment here.

In brief

The facts.

Careers

We’re hiring.

We’re a small, fast-mov­ing team in Mountain View, California, work­ing on‑site. We have a short list of open roles for ex­pe­ri­enced builders pas­sion­ate about AI and hu­man de­vel­op­ment.

AI Engineer Build the agen­tic sys­tems at the core of the prod­uct. It will un­der­stand learn­ers, plan a path with them to gain valu­able skills, and work step-by-step untli they get there.

AI Engineer

Build the agen­tic sys­tems at the core of the prod­uct. It will un­der­stand learn­ers, plan a path with them to gain valu­able skills, and work step-by-step untli they get there.

Learning Engineer Apply ex­per­tise in teach­ing to build en­gag­ing prod­ucts that re­sult in the learner de­vel­op­ing new skills. You will be build­ing prod­ucts in­formed by ped­a­gogy.

Learning Engineer

Apply ex­per­tise in teach­ing to build en­gag­ing prod­ucts that re­sult in the learner de­vel­op­ing new skills. You will be build­ing prod­ucts in­formed by ped­a­gogy.

Learning Scientist Invent new ways to teach that take ad­van­tage of agen­tic AI, and ap­ply rig­or­ous mea­sure­ment to en­sure users are de­vel­op­ing new skills and re­tain­ing them.

Learning Scientist

Invent new ways to teach that take ad­van­tage of agen­tic AI, and ap­ply rig­or­ous mea­sure­ment to en­sure users are de­vel­op­ing new skills and re­tain­ing them.

Software Engineer, Full‑stack Build our soft­ware prod­uct end to end. You’ll make key ar­chi­tec­ture and im­ple­men­ta­tion de­ci­sions to en­able us to serve unique, AI-enabled learn­ing ex­pe­ri­ences at scale.

Software Engineer, Full‑stack

Build our soft­ware prod­uct end to end. You’ll make key ar­chi­tec­ture and im­ple­men­ta­tion de­ci­sions to en­able us to serve unique, AI-enabled learn­ing ex­pe­ri­ences at scale.

Operations Specialist Lead of­fice op­er­a­tions and ad­min­is­tra­tion to en­sure our team is well sup­ported and can move fast and fo­cus on their work in­vent­ing and build­ing prod­ucts to serve learn­ers.

Operations Specialist

Lead of­fice op­er­a­tions and ad­min­is­tra­tion to en­sure our team is well sup­ported and can move fast and fo­cus on their work in­vent­ing and build­ing prod­ucts to serve learn­ers.