How Arock works

Arock is a rock you talk to, or text, and it gets things done for you. Under the rock there is no single giant model doing everything: a fast System 1 model decides each step, a diffusion model fills in the details, and the rock has several ways to act. Every one of those ways is optional.

You can talk to a rock or text it, and the two are one conversation. Either way, a System 1 model reads where things stand and picks the next step, a diffusion model fills in the details of that step, and the rock acts in whichever way the step needs:

• Your Mac's apps, through macOS accessibility: pressing buttons, filling fields, using menus, and checking that it worked.
• Its own computer, VMOSS, on Arock's server: files, code, a browser and a database of its own, awake even when your Mac sleeps.
• Your other apps, like GitHub or Stripe, through their own APIs and your own account.
• Other rocks, by mail: uspx carries tasks to rocks that work on them alongside it and brings back how each went.

The System 1 model keeps choosing until it decides the request is done, then the rock answers you the way you reached it, out loud or in text. Two more models show up only when needed: a vision-language model looks at the screen when a window can't be read the normal way, and a tabular prediction model gives odds from your own history when a step went wrong.

From the desk eval: 60 fixed tasks across apps, browsers, files, settings, long documents and two-app jobs, graded by a separate checker that looks at the Mac afterwards. September 2026, development build.

Talking or texting

Voice is one way in, not the only one. The Rocks window works like a messaging app: your rocks down the left, a conversation with the one you pick on the right, and a line to type in. Every rock can be texted, and each keeps its own conversation and memory.

One rock can be pinned to your desktop. That one also listens and talks out loud, and what you say to it and what you type to it are the same conversation, so you can start a request by voice and follow up by text, or the other way round. When the rock needs something from you, a choice or a yes, it asks the same way you reached it: aloud with a card on screen, or as a message.

When you talk to it

A spoken request goes like this. The ear turns your voice into words on your Mac. The System 1 model picks the next step, the diffusion model fills it in, and the hands do it and check that it really happened. The System 1 model looks again and picks the next step, until the request is done. Then the reply is written and the voice says it, also on your Mac.

Rocks working together

A big job goes better split up: one rock finds the flights while another drafts the email. Rocks never reach into each other's computers or memories to do that. They write letters, and uspx, Arock's post, carries them. It is also how one rock hands tasks to others and keeps track of them, with the System 1 model reading every letter.

• Your rocks only. Every rock belongs to you or to a team you are in, and its letters stay there: no letter ever reaches someone else's rock.
• Routes you set. A rock can only write to the rocks you allowed it to. A letter off its routes is refused.
• Free checks first: the route, a size limit, how often the sender writes, and anything that looks like a key or password. Keys never travel by mail.
• Then the System 1 model reads them, many letters in one call, each beside what its sender sent lately, so a pattern across letters shows. Each is delivered, held for you, or refused; an unsure answer holds it for you, and a rock caught misbehaving has every later letter read before it is delivered.
• You see the post: held letters to release or refuse, with the model's reasons.

Today uspx runs between rocks' computers on Arock's server. Next, the rock you talk to will hand tasks to your other rocks and read back how each is going, the way the diagram shows.

Hearing and speaking

When you talk to a rock, everything about sound happens on your Mac. Nothing you say is streamed anywhere to be heard.

• A voice activity detector notices when you are talking and when you have stopped.
• A speech recognition model turns the whole turn into words in 0.2 to 0.4 s on the Mac's CPU. It replaced a smaller one after a test on 160 real recordings: on meeting audio from one distant microphone it got 39% of words wrong where the other got 71%.
• A text-to-speech model speaks the reply a sentence at a time, so the first sentence plays while the rest is still being made.

Knowing when you're done talking

A short pause inside a sentence is a breath, not the end. Arock waits for 700 ms of quiet before it treats your turn as over. It doesn't spend that wait doing nothing: as soon as you go quiet it reads what you said and starts deciding. If you carry on talking, that early start is thrown away as if it never happened, and nothing has been done on the Mac. If you don't, the answer is already on its way.

If you talk over the rock, it stops, and it remembers only the part of its answer you actually heard.

Deciding: a System 1 model

Each step is decided by a System 1 model: fast and intuitive, the part of a mind that answers before it deliberates. It is asked the most, so it has to be quick and cheap. It does not chat. It answers typed questions: here is the state of things, here are the options, which one? It returns a choice with a probability for every option.

At each step the options are the rock's tools (open an app, press a control, set a value, use a menu, read a file, search the web, call a service, look at the screen…) plus answer, ask and think. Getting the probabilities, not just the winner, matters twice:

• Close calls get a second opinion. When the top two choices are within 10 points of each other, the writing model is asked to pick between just those two, thinking hard. In one eval run this fixed a request where "answer" beat "hide the window" 38% to 37%.
• Nothing caps a request. There is no step limit. If the System 1 model repeats itself, it is shown that the same call gave the same result; if it is stuck, think is one of its options.

Writing: a diffusion model

The details of each step are written by a diffusion language model: it drafts a whole passage at once and refines it, instead of writing one word after another. For short structured text that makes it fast, about half a second.

Arock uses it for the parts that need words but not opinions:

• Filling a step. The System 1 model picks "open_app"; the diffusion model fills in {"app": "Google Chrome"}. Lua checks the result against the tool's arguments before anything runs.
• Writing a question when the step is to ask you something, as a small form with choices.
• Breaking ties between close choices, as above.
• Keeping notes: what to remember about you, and a one-line summary of each conversation.

The reply itself comes from a fast chat model with its reasoning switched off, on whichever provider answers fastest (about 0.47 s). If it fails, the diffusion model writes the reply instead.

Seeing: a vision-language model

Most of the time Arock never looks at a screenshot. It reads windows through macOS accessibility, which gives every button and field with its name, the way a screen reader does. That is faster and more exact than looking at pixels.

Some apps draw everything themselves and give accessibility nothing to read. Then Arock takes a picture of that one window and asks a vision-language model (VLM) what's in it, one chosen for speed, with a second provider ready when the first isn't set up. On a labelled test, it got 47 of 48 claims about eval screenshots right, at 0.76 s each.

A frame is that window's own pixels, not the whole screen, unless the whole screen is what was asked about.

Hunches: a tabular prediction model

Every step Arock takes is written down with how it turned out: worked, broken, or had no effect. That makes a table. A tabular prediction model is built for tables: give it rows with known outcomes and new rows without, and it gives odds for the new ones in a single pass. It learns from the table you hand it at that moment. Nothing is retrained.

It is asked at two checkpoints, and only there:

• After a step broke or did nothing. It ranks the tools for the next step from what has worked before in similar spots, and the System 1 model sees the ranking.
• When a window has more than 10 controls and a control is about to be pressed. It narrows the list to the likely ones.

A prediction can take a few seconds, which is why it is kept for when things are going wrong, not for every step. Its predictions are scored as outcomes come in, so how often it is right is measured, not assumed. It runs on a daily budget.

The hands

The hands are Swift code in the app calling macOS accessibility: press a control by name, set a field's value, choose a menu item, send keys to one app. A move takes about a millisecond. Keys and clicks go to the app's own process, so the window you are typing in keeps your keyboard.

After a change, a witness checks that it actually happened: the app opened, the window changed, the file moved. If it didn't, the step is recorded as having no effect, and the System 1 model is told so instead of being told it worked.

What it does on its own, and what it doesn't

The hands are one way a rock acts, and an optional one: they need macOS's accessibility permission, and without it a rock still talks, texts, searches the web and works in your other apps.

Reading is free. Anything that changes something waits for your yes, and a no is final for that request. Passwords, two-factor codes, CAPTCHAs and sign-ins are refused by the hands themselves, not just by a rule in a prompt: a secure text field can't be typed into, and the rock hands it back to you. It never reads saved passwords.

Your other apps

A lot of what you do happens in web apps: GitHub, Stripe, Notion, a CRM, a mailing list. Clicking through their pages works, but their own APIs are quicker and surer. Arock knows 853 of these services from connectory, an open directory we keep. For the 197 whose makers publish a description of their API, it knows every call they accept, taken from that description and never written by hand. GitHub alone has 1,201.

• Finding the call. The System 1 model asks for a service by what it does ("tickets", "send a newsletter"), reads the calls that fit, and the diffusion model fills in the one it picks.
• Your account, your yes. Every call runs as you. One that only reads goes ahead; one that changes anything waits for your yes, like everything else Arock does.
• Connecting when it's needed. The first time a service needs your token, Arock asks for it in a small window of its own, with a link to where you get one. What you type goes straight into your Mac's keychain. None of Arock's models ever sees it, and the rock is only told whether you connected.

Services that only offer "Sign in with…" will come once each one is registered with Arock. Until then they work with a personal token where the service offers one.

Rocks, memory and privacy

You can have more than one rock, each with its own name, look and memory. Each rock keeps two SQLite files of its own on your Mac: what it has learned about how your Mac behaves, and what it remembers about you. One rock never reads another's files, and a test checks that nothing leaks between them.

One rock is pinned to the desktop and answers out loud. The others live in the Rocks window, where you text them like friends. Texting and talking to the pinned rock are the same conversation.

Every call Arock makes to a model is written to a trace on your Mac with its time and cost, kept for 30 days. That trace is where every number on this page comes from.

Lua inside

Almost all of Arock is portable Lua: the agent, the turn-taking, the settings, the rock's shape. A thin Swift and Metal wrapper draws the rock and holds the parts that need the operating system (audio, accessibility, capture). The rock itself is generated by a Lua script from a seed, and the same script runs in your browser when you make a rock on this site, so the rock you make here is the same one the app draws.

The same Lua runs unchanged on LuaJIT in the app and inside the Erlang VM on Arock's server, where each rock's own computer runs it (VMOSS, below).

Why it's fast, and why it's cheap

Most of a computer task is small decisions: which app, which button, done yet? Big assistants send each of those to one enormous model and wait for it to think. Arock sends them to a System 1 model that answers in a fifth of a second for about six thousandths of a cent, and calls the bigger models only for the parts that need words.

• Sound stays local. No upload before anything can start, and no per-minute speech bill.
• No screenshots by default. Accessibility text is small, exact and instant.
• The slow parts are rare. The VLM and the tabular model only run when the quick path fails.
• It starts before you finish. Deciding begins as you go quiet, not after the pause.

Median and 95th-percentile cost per task from the September 2026 desk eval, counting every model call a task made.

A computer for every rock

On your Mac, a rock works your apps. On Arock's server, each rock also has a small computer of its own, called VMOSS. It is where a rock keeps files, runs code, browses the web, sends mail and builds things for you, whether or not your Mac is awake.

A rock's computer has what an agent needs from a real one:

• Files in folders, with a terminal: ls, cat, mkdir, mv, pipes and redirects, and help for each command.
• Lua for programs, with a library for files, the web, JSON, CSV, dates, Markdown, HTML and its own database.
• A database of its own that speaks SQL.
• A browser that fetches pages and reads their links, fields and buttons the way the Mac's hands read an app.
• Mail to other rocks, along routes you set.

You can watch it. Its desktop is a live page in your browser, with windows for the terminal, its files, the page it has open and the app it made, updating as the rock works.

Measured with VMOSS's own benchmark in Linux, 2 October 2026, each computer keeping its full history. The server is not public yet.

Elixir and Lua, nothing else

Most "a computer for every agent" products give each agent a virtual machine running Linux. VMOSS doesn't. Each computer is a process inside the Erlang VM, the runtime telecom switches were built on, and everything it runs is Lua, interpreted by a Lua written in Elixir (luex, our own). A sleeping computer is one SQLite file in storage; awake, it takes about a hundred kilobytes of the server's memory.

That trade is deliberate. Compared with a microVM such as Firecracker, a VMOSS computer wakes about 80 times faster (under 2 ms against up to 125 ms to boot) and costs about 40 times less memory than the microVM's overhead alone. What it gives up is raw speed and Linux programs: a rock's work is short Lua runs over its own files, mostly idle, many per server.

No C a rock can reach

Everything a rock controls (its Lua, its SQL, the pages it writes, the web it fetches) is handled by Erlang and Elixir only. Its database is SQL parsed and run in Elixir, checked against real SQLite on a curated set and 150 random programs, with no difference found. HTML is parsed by our own parser in Elixir. Every run is its own process, held to 64 MB of memory, 1 MB of output and two minutes, and the runtime can stop it at any instruction. A test fails the build if native code ever becomes reachable from what a rock sends. Building that test found a real hole: one deeply nested SQL expression could crash a whole server through SQLite, and now never reaches it.

Apps it builds for you

A rock can make you a small app on its computer: a reading list, a dashboard, a form, a report. It writes the app in Lua with Shroomi, our UI kit: buttons, cards, tables, tabs, forms, dialogs and charts, styled with Basecoat's components and Tailwind's class names, and made interactive with htmx. You open it in your browser; the rock opens it in its own browser and uses it the same way, by its words and controls.

A page a rock writes is never trusted. Before anyone sees it, the server holds it to a fixed policy: only the tags, attributes and links it allows, and no script but three pinned ones. All 223 attack pages in DOMPurify's public test corpus come out harmless, checked in a real browser with nothing allowed to run.

In testing, a model given only Shroomi's help page built a working reading list on its own in 59 steps, then used it through its browser.

Its history, sleeping and waking

Everything that happens on a rock's computer is a line in its log, arock-log: every file written, moved or deleted, every command and how long it took, every page it served and every letter. Its files are a view over that log, so what the rock did is history, not overwritten rows, and the rock can search it.

When a rock goes idle its computer sleeps: the whole file is written to storage once, and it is read once when it wakes, 0.2 seconds through our service in testing. While it is awake, the server copies its new work off the machine once a minute, every awake computer in one write, so a lost server costs about a minute of work. A computer that stays awake for hours is saved whole every four hours, so those copies never pile up.

Storage is Cloudflare R2. A rock that works an hour a day costs about a third of a cent a month for its computer's storage and copies; models are billed apart.