News

What's new

Your work stays on your computer

Your requests, messages, documents and results stay on your computer. The hosted service keeps the structure of the work and the settings you chose: ids, states, times, counts and costs, the names of your projects, computers and areas, file paths inside a project, your saved commands, and the configuration of your checks, environments and workflows. What you keep across projects is stored on the service too: your agents, recipes and hooks, and guidance about how you work. When the service needs words to do its work, for example to show a page on another device, it reads them from your computer, uses them in memory and does not store them. Data and security says what is kept where.

Away from your computer

Open the app on a phone or another computer and the words are read from the computer the project lives on. With that computer off, the app shows the shape of the work and says "On your computer, not connected" where the words are, and fills them in when it connects again. Your computer holds the only copy of the words, so AlchemyLab backs them up there once a day, in a folder you choose. Settings, Data has the backups, a check of what the service holds for the project, and a download of your record.

One service per computer

Set AlchemyLab up once with alchemy service and it runs your projects in the background, so a project no longer needs its own terminal. Run alchemy in a folder to add it as a project. Opening a project in the app starts it on its computer: the page says Connecting for a few seconds, then it is live. When the service starts again after a stop, the projects that were running come back and their work goes on from where it was.

Several computers

You can run AlchemyLab on more than one computer with the same account, each with its own projects, and see all of them in one app. The project list says which computer each project is on, and its work runs there. When a computer replaces another one, run alchemy on the new one and sign in. It asks whether this computer replaces the old one, brings the words back from a backup, and then moves the projects.

Rounds on a completed request

After a request is completed, a message on its page starts its next round, so "a bit bigger" is round 2 of the same request. While you keep writing, the round stays open and each change goes straight to its worker. What it made sits beside Steer and loads again after each change. The checks and the review run once, on everything the round changed. With the page open, the round completes a minute after its last change or when you press Complete. If you have left the page, it completes as soon as its worker is done. Under Manual and Assisted, your sign-off ends it. A round that asks for separate work can be made a request of its own.

What a completed request shows

When a completed request has something to look at, it is shown first and the words follow: in Steer, on the sign-off card, and at the top of the request's page. It can be a picture, a page before and after, a document, or the request's numbers against its target.

Notifications

Settings, Notifications has one choice for your account: off, when something needs you, or also when a request completes. Each browser or device is turned on by itself. A notification names the project and the request, as in "ferry-board: a request completed". In a background tab, the title starts with the number of things that need you.

Targets

A thread, or a request on its own, can have a target: the numbers that say it is done. Each one is a number an approved command prints, with a bound, such as "broken_links at most 0". After each request in the thread is completed, the target is read again on your main branch. A schedule can be judged by a target too. When a number misses its bound, the schedule proposes the change that brings it back, inside the thread's budget.

Strictness in three levels

Strictness is how much evidence each criterion needs before a request is completed. It now has three levels: Minimal, Checked and Reviewed.

The app

A request's page has its tabs at the top: Overview, Work, Artifacts, Files, Activity and Guidance. A document, a change or a preview you open sits beside Steer, so you can talk about what you are looking at, and Full size gives it the whole window. The message box has two looks under Settings, Theme: Bubble, in the colour of your messages, or Classic, the outlined box. Exhibits, the small pages an agent shows in Steer, take the app's colours and can send your input back to the agent.

Models

Claude Sonnet 5.5 and Haiku 5.5 are on the model list beside Opus 5.5. You pick the primary model from its name at the top of Steer, and helper agents such as research use a model two steps below it on the same provider's list. New projects start on GPT 6.1 Sol with OpenAI and on Opus 5.5 with Anthropic, as before.

Quicker

The first sealed box of a new project opens in about a second once its setup has run, where it used to install the dependencies again. The project list opens as quickly with a thousand projects as with ten. The agents' standing instructions are about a third shorter.

Coming from 2.x

3.0 starts fresh

Your account is kept: the same email and the same password or Google sign-in. Projects from earlier versions are removed from the service, with their requests, documents, messages and history. Your own agents, recipes, hooks and workflows are removed too. Your code and your folders on your computer are not touched. To use a folder you had before, update AlchemyLab, sign in again when asked, and run alchemy in that folder. It starts as a new project.

Fixes

• A sign-off refused because main had just moved gets its new card as soon as the next run finishes.
• A check cut short by a restart reads "did not run".
• A criterion that is already proven is no longer listed as unmet on the request's page.
• A message longer than 2,000 characters is kept whole.
• When you are signed out, the app takes you to the sign-in page and back to where you were.
• A preview whose folder is gone says so.

What's new

Esc to stop

While the Alchemist is answering you in Steer, press Esc to stop that turn. If it had only looked things up, your message comes back to edit. If it had already done something, Steer says what.

Ask how it is going

Ask in Steer, in any words, and get a few lines per thread: what is done, what runs next, what waits on you, the spend so far, and anything stuck.

Plans with a spend limit

Start Building can take a limit ("go ahead, stop at $30"). Each finished step is one line in Steer. When the spend passes the limit, or a step fails its check twice, the plan pauses and asks you how to go on.

Numbers that must not get worse

Say that a running time, a test count or a size must not get worse, and the work is measured against where it started, three runs each. A real regression waits for your sign-off, with both numbers on the card.

Cards that say more

Each option on a card says what it gets and costs, and the recommended one says why. The sign-off card and the receipt start with what was not checked. When you correct how something was done, you can keep it as guidance for later work.

Checks

When main has moved, a check whose files main's new work did not touch keeps its earlier pass. A check that fails on main too no longer holds your request back, and the card says it could not check this change.

Existing projects

The test check is set up to run the project's fast tests on every change and lists what it leaves out. Boxes use the runtime version the project declares, and every box can write to its working folder.

A quicker Steer

Replies appear as soon as they are ready, opening Steer downloads less, and typing goes back into the composer after a click. On our benchmark, 2.3 got the same results as 2.2 with about 10% fewer agent steps.

Fixes

• A test-check setup that ends with no check asks you again, with what went wrong.
• A question passed on to you always has options.
• A sign-off held for running checks continues as soon as they finish.
• Review waits for a check's newest run.

What's new

Install with one line

In a terminal on macOS or Linux, run curl -fsSL https://alchemylabcode.com/install.sh | sh, and in PowerShell on Windows, irm https://alchemylabcode.com/install.ps1 | iex. The home page has both, with a copy button. The script brings its own Node if yours is too old, checks what it downloads, installs into your home folder without admin rights, and says what it changed. npm still works, now from Node 22.16, and installs without running any package's install scripts.

A better first hour

With no AI provider connected, the app says so and points to Settings, Providers. A new Python or Node project gets a sealed box that fits it, so its first request can run its tests. Signing in from the terminal needs a confirmed email, as on the website, and the getting-started page moves on to your project once it is registered.

Fewer steps per task

The agents' tool descriptions and instructions are shorter, and rules that made them take extra steps are gone. On our benchmark, simulation tasks finish about 18% faster and 12% cheaper than in 2.1; on the Python tasks the time is about the same and the cost a little lower.

Questions and Self-driving

On Self-driving, an agent's question that has a default is answered with it at once, so the work keeps going. For content only you can give, the agent builds with a clearly marked placeholder when it can, and the final card asks you for the real thing. When the work cannot go on without your answer, it asks you on every setting and builds everything that doesn't depend on it in the meantime. A recommended answer never makes up data.

Default model

New projects now start on GPT 6.1 Sol with OpenAI and on Opus 5.5 with Anthropic.

Warm workers

A worker that just finished can take the next request in the same area of the code, not only the next one in its thread, while its context is still cached. A thread now only groups work you see as one piece.

What it would cost

On a plan login your provider doesn't report a price, so receipts and the Usage page now show what the work would cost at list price, marked as not your bill.

Voice

Words are no longer written twice, a short chime tells you your words were sent, and while the agent works it says in a few words what it is doing. You can talk over a reply to interrupt it.

Standards and guidance

"Use as a standard" on a document asks the Alchemist to turn it into guidance, and the Guidance page groups those rules under their standard. When no review runs, the sign-off card lists the guidance for you to check.

Phones

Settings and every dialog take the whole screen on a phone, and diffs, toolbars and the sign-up form fit.

Fixes

• Replies in Steer are no longer shown twice while you wait.
• A request and its rounds count as one request everywhere; unrelated requests no longer join the same thread.
• The app tells you when your browser blocks it from reaching AlchemyLab on this computer.
• The agents' tool server restarts itself if it stops.
• Many smaller fixes to the sealed boxes, the agent runtime and the interface.

What's new

Standards

Give the Alchemist a document that says how you want work done, such as your coding standard or how you run simulations. It turns the document into guidance for the agents, each item pointing back to its section, and you adopt it once. From then on, whatever a reviewer can check in the finished work is checked on every request. When the work runs into something your standard doesn't cover yet, the review can suggest adding it, and if you agree it goes into the document. Edit the document yourself and the Alchemist suggests the matching changes. This is new, and it will get more polish in 2.2.

Sealed boxes in three sizes

When an agent runs a command, it runs in a sealed box: a throwaway container on your machine, cut off from the rest of your system and from the internet unless you allow it. Boxes now come in three sizes, and the agent picks one to fit the job: a small one for a lint, a bigger one for a test suite, and most of the machine for a simulation or a large build.

Faster on long work

A long simulation or test suite that already passed isn't run a second time before the work is merged. The worker can finish up while its last check is still running, and its box is ready sooner.

Long sessions

When a session gets very long, older parts are summarised to make room. Your exact words and the request's records now survive that, and the agent carries on where it was.

Parallel work

Requests that add results to the same results file no longer get in each other's way, and the Alchemist only makes requests wait for each other when they would change the same code.

The final review

The final review now sees what the worker ran and what each run printed, so it can check where a number came from. When it needs a decision from you, the card asks exactly that: keep what was delivered, or say what it should be instead.

Default strictness

A new project starts at Strictness Minimal, with you signing off. Turn it up on the Workflow dials whenever you want more checking.

The interface

Each request has its own page: its card, then how it was done. Steer shows where a message will go and groups each request's story. Briefs and answers on cards are simpler, and light mode was reworked.

Fixes

• Opus 5.5 works with a Claude login.
• Many smaller fixes to the sealed boxes, the agent runtime and the interface.

What's new

A whole new steer surface

Before, you talked to agents inside their sessions: you had to find the right session and keep track of which agent was doing what. Now you talk to the work. Every running request reports to Steer, one conversation for the whole project where questions, progress and anything waiting on you are grouped by the request they belong to. Comment on a request and the agent working it picks your message up at its next step, without stopping. Questions come with a suggested answer and say when the agent will go ahead on its own, and anything that really needs you, like a sign-off, waits for you. You can still open one agent's session when you want to watch it work.

Any kind of work

Code is one kind of work AlchemyLab takes on. Writing, research, simulations, office documents and checks on a running product now go the same way: you say what done means, and the work stays open until it gets there. Agents read your PDFs, Word files, spreadsheets and slide decks, and a plan can run on a schedule.

Checked before it lands

Work reaches your project only after it passes the checks you set: tests, and a separate reviewer who compares it with what you asked for. When a check fails, the work goes back with the reason, and anything that still slips through can be undone in one step.

You set how much the agents decide

Two settings cover it. Autonomy decides whether agents ask before acting and who signs off. Strictness decides how much checking runs before work lands.

Your way of working, written down

A workflow holds how a project works: your instructions for each kind of work, its reviewers and rules, the gates and both dials. Its processes name the work you repeat, like a CFD case or a board paper, with the criteria every request that follows one must meet. Only you can waive one, and agents propose new processes and criteria for you to adopt. Export a workflow as one file and whoever imports it works the same way.

The project remembers

Answer a question once and later agents use your answer. A decision you keep reusing can become a rule for the project, or for every project you own, once you adopt it.

Point at what you mean

Open what an agent built from Previews, snapshot it, draw a box on what is wrong and ask about it or leave a comment. In a plan or a document, select text and ask. Your words stay on the exact spot you pointed at.

Follow the whole story

When one request leads to another, they stay linked. The Arcs view shows everything that grew out of what you first asked, and what became of each part.

Safe by default

Agents work in a copy of your project and never change its history themselves. Their commands run in a sealed box, and risky ones wait for your approval. Where your data lives and what agents can reach is set out on Data and security.

From anywhere, with what you already use

• Start work from Linear by labelling an issue, and have the receipt posted back to it when the work merges.
• Use it from your phone, and talk to it by voice.
• Sign in with the ChatGPT or Claude plan you already pay for, and see how much of it is left.

Under the hood

The sealed box

Anything beyond editing tracked files runs in a disposable container with a read-only root filesystem, dropped capabilities and no network unless you allow it. Without Docker, commands run in the operating system's own sandbox or wait for your approval. Agents run only registered commands, and an unknown one waits for you once and is remembered. Every command, and every connection the box refused, is recorded on the request. AlchemyLab does all the branching, committing and merging: a git command that would change the repository is refused rather than asked about, read-only git still works, and only a merge moves main.

The gates

Tests run on exactly what would be merged. Pin the reviewer to a different model from the coder if you want a second opinion. A visual gate renders your pages in a headless browser inside the box and compares them with baselines only you can change. A merge that would undo what an earlier request promised is caught before it lands. Workflow rules say what every change must respect, and a Rules reviewer checks each change against the ones that apply; a rule can be waived for a single request. An optional intake review checks a new request before any work starts. Strictness sets how hard each of these bites. Both dials live on the workflow, each request keeps the settings it started with, and its steps show which gate is asking what.

Kinds of request

A request is code, writing or a drive. Code and writing get their own branch, their own gates and one merge. A drive checks what the docs, a deploy or a merged request claims against the running product and never edits anything, so its receipt is the result. A changed office file shows as a text diff with its pages before and after, and output too large for git, such as a solver's field data or a render, is kept as a recorded result the reviewer can open. Schedules run every few hours or at set times of day. When a worker needs an environment it does not have, the setup architect builds it as a request of its own, and the worker waits for it.

Steering

Your message reaches the agent at its next step, even in the middle of a long command, and when it changes what is wanted it is written into the request's description. Every exchange is kept as a thread you can reopen. A request can open with a brief: one card listing the choices it expects to make and what it recommends, and depending on the autonomy level it builds on those defaults while you decide.

Warm coders

Each request gets its own coder. When the next request lands in the same area while that coder is still warm, it goes to the same one, so it already knows that part of the code and the model's cache is still live, which saves time and tokens. Idle sessions keep that cache warm for a few hours, a setting under General.

Blocked agents say what they need

A decision an agent cannot make goes to the agent above it and reaches you only if that agent cannot answer. Something only a person can verify becomes a card for you to check by hand. A request it depends on becomes a wait, and the agent is told the moment that request lands. A request that refers to something the project does not have goes back to drafts and asks.

Receipts

Before a request is recorded as done, its checks have to hold up. The request shows what it ran, what the gates decided, what the box blocked, and anything it did outside the project. When nothing ran, the receipt says so.

And also

• Web access for agents: search, read and screenshot pages and fetch assets, all behind one switch on the workflow.
• Local models through LM Studio, set up in Settings.
• Cmd or Ctrl+K opens a command palette to jump to anything.
• MCP servers for trackers, error reporting, databases and documentation: no agent can use one until a workflow grants it, tools that write ask first, and every call is recorded.
• New agents start on your secondary model once your plan is 90% used.
• Bring your own Docker Compose file for the services a project needs; anything in it that would reach into your machine is stripped before it runs. Watches wake an agent when a check they are watching fails.
• The Flow view lists every command a request ran, coloured by where it ran.
• Your data, stated exactly: full agent transcripts stay on your machine, the Data page in Settings downloads everything the hosted service keeps as one file, and deleting a project removes all of it in one step.
• The server on your machine answers only the AlchemyLab app, and the app has to prove who it is first.

Quests

A new mode for open-ended work where you don't know up front how many turns it'll take. Define a goal, success criteria, an iteration cap, and a minimum tick count; the agent keeps iterating until you mark it done or a cap is hit. The LLM can't end a quest on its own. Quests appear in the timeline with a status panel, tick countdown, and criteria checklist.

Light mode (beta)

A light theme covers the full app. Toggle in Settings → Theme. Still in beta, so expect a few rough edges in dense views.

Faster testing

A pass of improvements to the test loop:

• The warm worktree pool now skips setup (npm install and friends) when nothing relevant has changed, using a fingerprint of files you nominate (`package-lock.json`, `Cargo.lock`, `uv.lock`, `go.sum`, etc.).
• A recent passing test run (within 10 minutes) now counts toward the merge gate in auto-test-then-merge mode, so finishing doesn't trigger a redundant re-run.
• Coders can fire an async test run mid-session via a new `tests run` operation and keep working while it runs in the background.

Commands

A round of improvements to the commands system: specialists can register reusable project commands (lint, build, custom shell), and approvals for new commands now arrive as a single batched card with approve / decline / Select-a-subset instead of one prompt per command.

Sessions panel

Two new bits in the drawer:

• A live token-usage + remaining-context meter on each session header, so you can spot a session walking up to its window before it stalls.
• Hovering a specialist tab now peeks at the specialist's current task and most recent message without clicking in.

Herald

Voice mode for the Sessions panel. Press the trumpet icon and talk instead of type. Herald cleans up your dictation before the agent receives it, and reads the agent's reply back to you as prose, so you can work with your hands off the keyboard.

The cleanup matters. Raw speech-to-text is full of homophones and false starts, and agents take it literally. Herald sits between you and the session, rewriting the transcript into something clean before forwarding it. Replies come back to Herald first, which summarises them before reading them out, so you get the gist of what the agent did instead of the raw tool-call soup.

If you prefer unfiltered dictation, turn Herald off in settings and the voice button goes back to plain speech-to-text.

View a short demo.

Model-aware thinking

Reasoning-depth options now come from provider metadata instead of a hardcoded list. Switch models and the available thinking levels follow what that model actually supports.

Multi-project

You can run more than one alchemy-local project at a time. Each instance registers itself at the machine level, and the UI binds its action-server URL to the selected project so things route to the right place. The project list shows which projects are currently connected, with a filter to match.

Bug fixes

• Long sessions slowly got sluggish from leaked SSE timer callbacks.
• Opening Settings could crash the tab when sessionStorage hit its quota.
• Top-level sessions of unknown type showed up under alchemists in the drawer.
• Planner choice cards briefly flashed the wrong card while the reply was still streaming.
• Sent messages flashed a duplicate for a moment before settling.
• Clicking a specialist while in alchemist view could leave the wrong view open.
• Session spawning had races in parent lookup and auto-planner triggering.
• Timer-hook actions silently swallowed errors instead of surfacing them.
• Multiple browser tabs could race to create the same alchemist on reload.

Commands

Project-level shell commands that agents run to check their work. You configure them per project. Agents can suggest new ones, but those need your approval before they're active.

Timer hooks

Hooks that fire on an interval instead of an event. Each timer has conditions: only when no specialists are busy, only after a session has been idle for N minutes. Auto-pause on inactivity. New header indicator with status and controls.

Bug fixes

• Subagents sometimes ignored the user's model selection and ended up on the wrong provider.
• Selected project was cleared on every login.
• Request completion could use a stale session identity.
• Auth validation logged noisy warnings on temporary network errors.
• Adding or connecting a provider didn't take effect until restart.
• Tool call rendering collapsed incorrectly for task-related operations.

Two weeks of work on the internals. The biggest change is invisible: AlchemyLab no longer depends on an external runtime to run agents.

Own runtime

AlchemyLab 1.0 required Bun installed on your machine to run agent sessions. That's gone. We forked OpenCode and rebuilt the server layer to run on Node.js, which you almost certainly already have. The fork ships as a single npm package of about 285MB, down from 2.6GB.

The deeper reason for the fork wasn't size. Concurrent agent sessions worked before, but the workarounds were ugly. Owning the runtime let us do it cleanly.

The fork tracks upstream and we have a sync process to pull in updates without losing our patches.

Two-phase request completion

In 1.0, completing a request meant verifying criteria and merging the branch in one step. If the merge hit conflicts, the whole thing got messy.

Now completion is split. When a coder finishes, the request moves to a verification stage where acceptance criteria are checked against the actual evidence. Only after that does the merge happen. If something fails, you know whether it was a criteria problem or a merge problem, and the request sits in a clear state instead of being half-done.

Quick actions

Not everything needs a full request. Specialists now have lightweight tools (quick write, quick replace, quick manage) that wrap a single file operation in its own micro-request. The change is still tracked and reversible, but there's no overhead of task decomposition for a one-line fix.

Stuck session detection

Agent sessions sometimes hang. The model stops responding, or a tool call goes nowhere, and the session just sits there burning time. There's now a watchdog that detects this: if a session has no output and no active tool calls for too long, it surfaces in the UI so you can kill it or retry.

Specialist memory

Specialists can now update their own description of what they know. When a specialist works on authentication code for the third time, it writes that down. Next time auth work comes in, the alchemist routes it to the right specialist instead of picking one at random.

Model selection

You can now switch models per session from the agent drawer. The system resolves which model to use from a stack: the agent type's default, the user's preference, and what's actually available from connected providers. If you want your specialists on a cheaper model and your alchemist on the flagship, that works.

Provider configuration

You can now add providers directly from the settings panel. Browse a list of known providers or configure a custom endpoint. Disconnect and reconnect without restarting.

AlchemyLab is built with AlchemyLab. The 722 requests that went into this release were all run through the system.

You describe a change. Agents break it down, execute it across your codebase, and every step is recorded.

Agent hierarchy

Work flows through three layers:

• Alchemist: the orchestrator. Reads your request, understands the codebase, delegates to specialists.
• Specialists: hold deep context on specific parts of the codebase. Each specialist owns a set of tasks and decides how to implement them.
• Coders: do the actual edits. Each coder works on an isolated git worktree, so parallel execution doesn't cause conflicts.

When coders finish, their branches merge back. The specialist reviews the result against the original task. If something's wrong, it goes back.

Beyond the core three, there are purpose-built agent types: research agents for codebase exploration, planners for architecture and design, history agents that trace changes back to their origin, testers that verify work against acceptance criteria, and a workflow architect that designs automation rules. Each type has a locked-down toolset. A research agent can read but not write, a tester can run commands but not edit files.

Traceability

Every request, task, tool call, and file change is a record with a unique ID. You can walk the full chain from a changed line, to the tool call that changed it, to the task that requested it, to the original request.

Git blame is integrated with the record system. Running blame on a file shows not just which commit changed each line, but which request and task caused it. This works because every agent commit is tagged with a record ID.

The record view is how you review what agents did, approve changes, and understand decisions.

Collaborative planning

You talk through a feature or architecture change with a planner agent, and it builds the plan document in real time, section by section, so you can steer as it takes shape. You can annotate specific sections with inline comments, and the planner picks those up and revises.

When the plan is ready, the planner decomposes it into linked requests and offers a handoff to build mode. Requests carry a reference back to the plan, so implementation traces back to the design decision. Plans are versionable if you need to snapshot or restore, but the core value is the back-and-forth: you and the AI iterating on a design before any code gets written.

Agents can also generate journals, narrative summaries of completed requests covering what was done, what decisions were made, and what files were touched.

Acceptance criteria and evidence

Requests have typed acceptance criteria. When a coder completes work, it writes what it did to satisfy each criterion and how it verified the result. Testers can independently validate criteria by running configured test commands and reporting results.

Rollback

Completed requests can be reverted with one action. Rollbacks follow LIFO ordering so dependencies unwind cleanly. You can't revert request #3 if request #4 built on top of it without reverting #4 first.

File changes, git state, and records are all unwound together.

Agent communication

Agents coordinate through typed messages (reports, questions, handoffs), each with a sender, recipient, and status. Messages are stored and queryable, so the full coordination chain is visible.

Hooks, recipes, and workflows

Automation is built in layers. Hooks are event-triggered prompts: when a specific event occurs (a task completes, a session goes idle, a request is created), a hook can fire an agent with instructions. Recipes group related hooks together. Workflows bundle recipes into a named configuration you can activate per alchemist.

A workflow architect agent can design these for you. Describe the behavior you want, and it builds the hooks, recipes, and workflow structure using purpose-built tools.

Tooling

Agents have no bash access.* This is a deliberate choice. Most AI coding tools give agents a shell and let them run wild. It works remarkably well. Until it doesn't, and something gets blown up beyond repair. The popular answer is to put everything in a container, which brings its own set of problems. We're making a different bet: that the future of AI tooling isn't bash commands from half a century ago. You can't reliably record what a bash command did, you can't undo it, and you can't constrain what the model decides to run. Some tools now use a second agent to check whether the first agent's commands are safe, but who checks the checker?

AlchemyLab replaces this with purpose-built tools: structured file edits, search, git blame wired into the request system, file recovery. Every tool call records exactly what it changed, so the audit trail is complete and rollback can actually unwind it.

The trade-off is that agents can't do arbitrary things. That's the point.

* Bash can be enabled per agent when the task calls for it. But it's off by default, and the built-in tools cover the vast majority of development work.

Local-first

AlchemyLab runs on your machine, built on OpenCode. Files stay on disk, all changes go through actual git commits. Metadata (requests, tasks, records, plans) lives on a server that enables the UI and multi-device access. Provider configuration uses the OpenCode system, so anything working in OpenCode works in AlchemyLab. Model selection is configurable per agent type.

The UI runs in the browser and is accessible from any device: phone, tablet, another computer. The browser is the IDE.

Current status

AlchemyLab is early and actively developed. The core loop works: requests, tasks, agents, records, rollback. The hook and workflow system is functional but still being refined. Testing integration is in progress. AlchemyLab is built with AlchemyLab.

If you've gotten this far you might as well try it.