How Bench works

What a workspace is

One folder on your computer that holds all your projects. That is the whole of it.

When you first open Bench you choose a folder — ~/Heureka Bench is a good default. That folder is your workspace. Every project you make becomes a sub-folder inside it, holding that project's data, code, drafts and results as ordinary files.

You can open the workspace in Finder or File Explorer at any time and everything will be exactly where you would expect. Bench keeps its own bookkeeping in a hidden .heureka folder alongside your files, which is also plain text — nothing about your work is locked inside a database only Bench can read.

Because it is just a folder, moving it, backing it up with your normal tools, or putting it under version control all work the way they always did.

What a project is

A folder in your workspace, and the unit ARC thinks in.

A project is a folder holding one line of work — a study, a paper, a collaboration, a screen. Inside it are your own folders plus the ones Bench writes into: Analysis for analysis results, Drafts for drafted text, Reviews for document reviews, Scheduled Tasks for recurring runs.

The project is also the boundary ARC works within. Open the agent inside a project and it has that project's files, its rationale and its to-dos in hand, and it writes its output back into that project. This is why "one project per line of work" beats one giant project — it keeps the agent's context on the thing you are actually asking about.

There is no limit worth worrying about. Projects are folders.

Local project or cloud project?

A local project lives only on your machine. A cloud project also lives on our servers, which is what makes it shareable and visible on your phone.

Every project starts local, and it can stay that way indefinitely: your files, your machine, nothing leaves.

Making a project a cloud project adds a copy on our servers and keeps the two in step. You still work on the local copy exactly as before — the cloud copy is what lets a collaborator open the project, what your phone shows you, and what survives if your laptop does not.

Nothing is one-way. A local project can be pushed to the cloud later, and a cloud project can be pulled down to a machine that has never seen it. Syncing is opt-in per project and per direction; Bench never silently overwrites a local file, and any conflict is shown to you rather than resolved behind your back.

1. Open the project and choose Sync to give it a cloud copy.
2. Or go to Cloud Projects and pull an existing cloud project down onto this machine.

What uses credits

Credits pay for thinking and computing. Storing and sharing are free.

One rule covers almost every case. If work is being done for you — thinking or computing — it uses credits. Keeping files somewhere, or sending them to a colleague, does not.

That means the storage-shaped half of Bench — cloud projects, syncing, backups, messaging, the activity feed — costs nothing to use. You are not billed for having your work in the cloud, only for work done on it.

What things actually cost

Rough figures for the things you will do most — with the spread, so you can see where the ceiling is.

Three shapes of work cover most of what you will do in Bench. Each figure below is for the whole job, with the spread around it so you can see the typical case and the ceiling together.

None of these is a single operation. Asking ARC to analyse a dataset means it reads the files, writes code, runs it, looks at what came out, fixes what was wrong and writes the result up — thirty-odd steps is normal. The figures below are for the whole piece of work, start to finish.

• A quick question ~$0.7575 credits
  Typical ~$0.75 · half fall between $0.25 and $1.50 · 1 in 10 costs under $0.05, 1 in 10 over $2.80

  Reading a file and telling you what is in it, checking a number, pulling a value out of a table, plotting a column, a quick summary statistic, a short back-and-forth about a result. Most small asks land here rather than in the rows below.

• A literature search ~$3.20320 credits
  Typical ~$3.20 · half fall between $2.00 and $5.50 · 1 in 10 costs under $1.25, 1 in 10 over $9.00

  ARC searches the literature and reference databases, reads what it finds, and works the relevant parts into an answer with the citations attached — looked up rather than recalled, so what lands in your notebook is traceable.

• An analysis of a dataset ~$7.50750 credits
  Typical ~$7.50 · half fall between $4.75 and $12 · 1 in 10 costs under $3.30, 1 in 10 over $17

  The whole job: ARC reads the data, writes the code, runs it, looks at what came back, fixes what was wrong and runs it again, then writes up the result — figures, tables and the script that produced them, saved into the project.

$0$5$10$15

The bar holds the middle half of cases and the tick is the typical one. The line runs from the cheapest tenth to the dearest tenth, so eight cases in ten land somewhere along it. Rows are grouped by the size of the job, not by what you asked for: a quick question is a short exchange, a literature search is one where ARC went out to a reference source, and an analysis is sustained work running over several minutes. A small plot or a fast calculation counts as a quick question, so the analysis row shows what substantial analyses cost rather than the cheapest thing you could call one. Figures are rounded estimates from observed usage.

Worth reading against what each one replaces. The analysis figure is not for one plot — it covers the exploratory pass, the statistics, the figures, the checks ARC runs on its own output, and a written-up result with the code sitting beside it. That is the afternoon you were going to spend, and the script is still there in six months when a reviewer asks how you did it.

The literature figure is not a search box either. It is the searching, the reading, and the part that usually eats the evening — pulling what actually bears on your question into something you can use, with the references attached.

Pricing — what a credit costs

One hundred credits to the dollar, with a bonus on larger purchases.

Credits are bought as a balance rather than a monthly subscription: you pay for the work you ask for, and what you do not use stays on the account.

Institutional purchases can be made by purchase order from the Usage page — organisation, address and amount, and an invoice follows.

Everyone on an account shares one balance

Credits belong to the account, not to the person who spent them.

A lab on one account draws from one pool. When a student runs an analysis it comes out of the same balance as the PI's literature search — there is no per-seat allocation to manage, and nobody is blocked because their personal quota ran out mid-experiment.

Anyone on the account can spend the account's credits. The Usage page shows the balance and how it is being drawn down over time, so a lab head can see the shape of consumption and top up before it becomes a problem.

Privacy Mode still uses credits

It stops your data leaving your machine. It does not stop the agent thinking.

In Privacy Mode every off-machine tool is blocked — no web, no literature or database lookups, no cloud jobs, no sync. What still happens is the model call itself, through our no-retention proxy, because that is what makes the agent able to answer at all.

So a private project uses credits at the same rate as any other. What you are buying with Privacy Mode is the guarantee about your data, not a discount.

Ways to work with other people

Three that work properly, and one common workaround that only works within limits.

A cloud project is the real answer. Sync the project, share it, and collaborators open the same project with their own copy on their own machine. Changes flow both ways, conflicts are surfaced rather than silently resolved, and everyone sees who changed what.

Shared Lab spaces — inventories, colonies and data spaces — are shared per record rather than per folder. Two people editing different parts of the same colony do not collide, and every change is attributed.

Pings covers the conversation around the work: direct messages, groups, and attachments, without leaving the app.

And the workaround worth a warning: putting your workspace inside Dropbox, Box or OneDrive. It genuinely works for one person across two machines, or for handing someone a copy to read. It does not work as a substitute for a cloud project when two people are working at the same time. Bench guards against two edits colliding within one running app; it cannot coordinate across two machines it does not know about. Your file-sync service will resolve that by making "conflicted copy" duplicates — including of Bench's own bookkeeping files — and the losing edit is simply gone. If more than one person is editing, use a cloud project.

What sits on your machine, and what sits on ours

The short version: everything is on your machine; some of it is also on ours, and only because you asked.

Your projects are always on your disk in full. The question is only ever what additionally has a copy on our side, and that is decided per project and per feature by you.

Backups are the case worth understanding: the archive is encrypted on your machine before it is uploaded and the key never leaves. We store ciphertext and can log that an upload happened, but we cannot open it. That is also why losing the key means losing the backup — there is no recovery path we could offer even if you asked.

If you stop using Bench, your workspace is still a folder of markdown, data and code, readable by everything else you own.

Sync is not a backup

Sync copies what you have now, including the mistake you just made. A backup is a moment you can return to.

If you delete a folder and sync, the deletion is faithfully copied. Sync keeps two places identical; that is its job and it is why it cannot also be a safety net.

A backup is a sealed archive of a moment. Restoring one brings that moment back regardless of what has happened since. Cloud projects and backups solve different problems, so use both — sync so the work is where you need it, backups so a bad afternoon is recoverable.

What works without an internet connection

Your record does. The agent does not.

Everything that is genuinely local keeps working: opening projects, reading and writing files, the editor, your notes, your to-dos, your inventories and colonies. It is your disk; nothing needs asking.

Anything involving ARC needs a connection, because the thinking happens through our proxy rather than on your laptop. Cloud actions grey out while you are offline rather than failing after you have committed to them. Work you handed to the cloud before losing signal carries on without you and is waiting when you return.