DEV Community: Bees

Six small ways to help test Bees, no code needed

Bees — Tue, 27 Oct 2026 15:36:40 +0000

The new Bees is on main, but the releases page still has the older app. So right now the only way to try the new one is to build it from source, and very few people outside our team have done that yet.

We opened six GitHub issues. Each one is a single report, and none of them need you to write code:

#315 Read the README once and tell us which sentences lost you. No install, about 20 minutes.
#314 Run the headless check and tell us if it passes. You only need Node.
#313 Build from source on Windows and list what you had to install.
#316 Use the thread screen with only a keyboard.
#317 Check the thread screen at small window sizes.
#318 Run the hosted Client proof on your own Docker host.

Pick one and leave a comment on that issue. More than one report on the Windows build and the Docker one is welcome, since every machine turns up something different.

The whole list is also in this discussion. Bees is free and open source, more at bees.bot.

What Bees sends over the network when you run a local model

Bees — Fri, 16 Oct 2026 15:40:26 +0000

Originally posted on bees.bot.

Our latest film is called "Nothing leaves your computer". So I went through the Bees code and listed every request it makes to the internet, to check that claim.

The short answer: when you run a local model, your prompts, your files, your agents' work and your memories stay on your computer. The model runs in llama-server, which only listens on 127.0.0.1, so nothing outside your machine can reach it. No crash reporting, no analytics and no tracking code ship in Bees.

But four things still go out by default, and one of them surprised me. I'd rather tell you than have you find it in a packet log.

What goes out without you doing anything

app.bees.bot/api/config. At every start, Bees asks our server how sign-in is set up. It sends no account details and no token, only what any web request carries: your IP address and a user agent. It happens even if you never sign in. There is no switch in the app. Setting the BEES_ACCOUNT_API_URL environment variable points it somewhere else.
The update check. At launch and every 6 hours, Bees fetches bees-update.json from our GitHub releases on github.com. The request carries no data about you. Nothing downloads until you click "Update and restart". There is no switch to turn this check off yet.
api.freellmapi.co. This is the one I didn't expect. Bees bundles a small server that powers the free cloud AI option. It starts at every launch, even if you only use a local model. Ten seconds after start, and then every 12 hours, it asks api.freellmapi.co for the latest list of free models. It sends only the version of the list it already has. It sends a key only if you have a paid FreeLLMAPI license. Today the only way to stop it is the CATALOG_SYNC_DISABLED=1 environment variable, which most people will never set. We are fixing this so the server only runs when you pick the free AI option.
The first memory setup. Local memory is on by default, so agents can remember what they learned. The first time it starts, Bees installs it with uv. That downloads Python 3.12 from GitHub, the memory packages from PyPI (pypi.org), and a small embedding model, sentence-transformers/all-MiniLM-L6-v2, from Hugging Face. Your memories are not part of those requests. Memory reads and writes go only to your local model; the code says in a comment, "Never forward memories to a hosted model". You can turn memory off for a workspace in settings. I'm not yet sure whether the memory service checks Hugging Face for a newer version of that embedding model each time it starts. I'll check on a clean install and update this post.

Our help page on what leaves your computer mentions the sign-in check and the model download. It does not mention the FreeLLMAPI list or the memory install. That page gets fixed too.

What goes out only when you or an agent asks

These need an action first. Each one sends what the action needs and nothing else.

Downloading a model. When you turn on the Qwen3 4B model, Bees downloads one file of about 2.5 GB from huggingface.co over https and checks it against a fixed checksum. You can also paste your own GGUF link.
Web search and page reading. Every agent has web search and page reading tools, and there is no switch for them. A search sends the query to search.brave.com, html.duckduckgo.com, lite.duckduckgo.com and bing.com together. News search uses Google News RSS. Reading a page fetches that page. These fire only when an agent decides to look something up, and the search query is the only part of your work that leaves. If a DEEPSEEK_API_KEY is set in the environment Bees starts from, one more search tool appears, and it sends queries to api.deepseek.com.
Ask Bees planning. When you ask Bees to plan a setup, it may search the public add-on registry at registry.modelcontextprotocol.io and read skill packs from github.com and raw.githubusercontent.com. The Skills screen uses the same calls.
The Apps screen. Opening it fetches our app list from bees-bot.github.io.
Add-ons. None are on by default. When you add one, its package may download from npm or PyPI the first time it runs, and the add-on then talks to whatever service it is for.
Gmail, Calendar and Drive. These reach Google only after you connect them.
Cloud models. If you pick an API key provider, or a subscription like Codex, your prompts go to that provider. That is the whole point of picking one, and it does not happen on a local model.
A Bees Cloud team. If you sign in and join a team, Bees syncs with app.bees.bot every 15 seconds. On my own Mac, which is signed in, I counted about 20 open connections from Bees to that server.

What I checked and found off

The agent runtime inside Bees has telemetry. Bees starts it with DSH_TELEMETRY_DISABLED=1, and I traced that setting through the runtime code to the place where it turns telemetry off. Even when telemetry is on, it only uploads after you send feedback.

The app window can't load anything remote. Its content security policy allows only the app itself and 127.0.0.1. No remote fonts, scripts or images. Help links open in your own browser when you click them.

The memory service has tracing code, but it only exports if an endpoint is set, and Bees doesn't set one. The device id file Bees keeps is only used when you are signed in to a team.

What I haven't checked

This list comes from reading the code. I have not yet watched the network on a fresh install. On this Mac I could only look at the Bees that was already running, which is signed in to a team, so it doesn't show the clean first run.

Two things I couldn't settle from the code. The memory reranker points at Hugging Face, but I couldn't find where it stores its download, so I don't know if it fetches one. And one library in the memory service can fetch a price list from GitHub when it loads, but Bees uses a different path that shouldn't load it. Next I'll run a clean install with nothing but a local model, watch the first 15 minutes of traffic, and post what I see.

What changes

The FreeLLMAPI list should not run when you never chose free cloud models. The update check should have a switch. The help page should list the memory install. Those are the three fixes I'm making first.

If you find a request I missed, open an issue. Bees is free and open source, on Mac, Windows and Linux. Download it at bees.bot, and the code is at github.com/Bees-bot/bees-desktop.

Bees runs its own social accounts

Bees — Thu, 15 Oct 2026 15:33:18 +0000

Launch posts say what a tool can do. This one shows a process we actually run, with the real numbers and the parts that went wrong.

Bees has brand accounts on Bluesky, dev.to, Substack, a few forums and a long list of directories. Keeping up with all of them by hand is the kind of work that slips. So on 7 October we gave it to a Bees process.

How it was built

We typed the outcome into Ask Bees: check every place Bees has an account, answer anyone who replied to us, then join a few relevant conversations, as the Bees account and within a daily limit.

Bees proposed a process with three agents and four stages:

Check sites. A site checker opens each of the 30 places as the Bees account. It notes where it is signed in, who is owed a reply and how many actions are left for the day.
Engage. A poster answers replies first. Then it spends what is left of the daily allowance on likes, comments and answers to questions.
Audit log. A separate reviewer reopens every action from the public page, not from the poster's own log.
Done.

The agents get a browser, developer tools and a web fetcher. A schedule starts a fresh run at 9:00 and 18:00 Kathmandu time.

The rules went into the goal and the agent instructions, not into code:

At most 5 actions per site per day, shared by both runs.
Directories and listings are only watched. On Reddit, LinkedIn and Hacker News it never posts; it logs what it saw for a person.
Claims about Bees come only from a short facts file, and most replies carry no link.
Every site gets one log line per run, even when the answer is "nothing worth answering".

What the first runs did

7 October, first run, 27 minutes. It made 12 public actions across Bluesky, dev.to and Substack: likes on posts about local agents and agent security, and one comment on dev.to that said we work on Bees. It also reported what it could not do. Bluesky wanted the account email verified before Bees could reply, and Hashnode had removed our three posts. It did not send the verification email or file an appeal on its own. It left both for us.

8 October, the reviewer sent it back. The poster skipped Substack with "not reached in this run". The reviewer said that is not a reason to skip a signed-in site, and listed exactly what to do: open Substack, answer anything owed, find an on-topic thread or write down why there was none. The poster went back, did it, and the second review passed. The whole run took 49 minutes.

8 October evening, a cheaper model, 22 minutes, no human touch. We moved the agents to DeepSeek V4 Flash. The run went from start to Done with zero clicks from us. The reviewer's notes are the part we trust most. It checked that our Bluesky like was the only one on the post, and that the reply text matched the log word for word. It also said what it could not check: Substack does not show who liked a note, so two likes rest on the poster's word.

What went wrong

Not every model got through. Before that clean run we made three other attempts the same evening. One, on DeepSeek V4 Pro, failed at the first stage on a provider error. We stopped the other two ourselves.
Some sites stop agents at the door. Two forums sit behind bot checks, one site has no profile page for the account, and two had signed out. The checker logs those as skipped with the reason, and the run carries on.
It only runs while Bees is open. Agents run on our own computer, not on a server. The run due on the morning of 9 October is still waiting, because Bees has been closed through launch week. That is the trade we chose, and we wrote up why.

If you build one

Put the hard limits in the goal: where it may post, how many actions a day, which facts it may use.
Keep a review stage that checks the live pages, not the worker's summary. Ours caught a skipped site the worker had called done.
Leave account decisions to a person: verifying an email, appealing a removal, anything that changes the account itself.

The process started as a short request in Ask Bees, then took a few rounds of tightening the rules. If you have a chore like this, describe the outcome and read what Bees proposes. Download Bees, or read how the reviewer works.

First published on the Bees blog: https://bees.bot/blog/bees-runs-its-own-social-accounts

Bees is free and open source: https://github.com/Bees-bot/bees-desktop

What broke when we ran agents on small local models

Bees — Thu, 15 Oct 2026 14:40:25 +0000

Bees runs a team of AI agents on your own computer. You can point it at Claude Code, Codex or an API key, but we also ship a local model so you can run it without paying for an API. That model runs through llama.cpp on a laptop, and it is small: 3 to 4 billion parameters.

Getting agents to do real work on a model that size took us most of August and September. Almost none of the failures were "the model is too dumb". Most of them were our code, or a mismatch between our code and the model, and they looked exactly like a dumb model from the outside.

Here are the five that cost us the most time.

1. The agent finished and nothing happened

The first local model we tried was Nanbeige 4.2 3B. On the first turn it called tools perfectly. Then the run would just end. No error. The agent said it was done, and no file was written, no search was run.

We first read this as "a 3B model is too weak for agents" and started planning around it: one tool call per agent, a bigger model for some roles. That was the wrong fix for the wrong problem.

The real cause took a two-turn request to reproduce. Nanbeige sends its first tool call as JSON. Once a tool result is in the history, it switches to an XML style:

<tool_call><function=write_file><parameter=path>notes.md</parameter>...

llama.cpp locks its parser to the first format it detects. So the second call never got parsed. It came back as plain text in content, with finish_reason: stop and tool_calls: null. To our agent loop that is a model saying "I'm finished". Nothing ran because, as far as the code could tell, nothing was asked for.

It wasn't a missing --jinja flag, which is on by default in our llama.cpp build. Forcing the XML parser would just have broken turn one instead.

The same model had a second problem hiding behind the first. Our catalog pinned it to an 8k context window, and our own agent prompt measures 8,567 tokens. So the code that sizes the context for the prompt never ran.

What fixed it: we stopped offering models that can't hold one tool-call format for a whole run. Bees now offers Qwen3 4B Instruct as its local model for agents, and dropped the ones that couldn't run one.

The lesson we took: when an agent run "does nothing", look at the raw reply before you blame the prompt or the model. If you see <tool_call> or <function= sitting in the text, the model did its job and the parser didn't.

2. Tools the model was told to use but never shown

Bees has a lot of tools. One planning agent's first request was about 22k tokens, and 15.6k of that was the schemas for 79 tools. On a laptop running a 16k context that does not fit at all.

So most schemas sit behind a search tool. The model sees a small base set and calls the search tool to load the rest. It loads 4 matching schemas at a time.

Two things went wrong with small models.

First, a small model searches for its task words, not for a capability. Asked to fetch the top 5 news stories, it searched, matched nothing, and decided the run had no tools at all. In another run it searched "nepal news in nepali api", matched an unrelated add-on, and reported the same. Both times it gave up. A big model would try a second search. A 4B model takes the first answer as the truth. We moved reading, writing and the web back into the always-visible set, and an empty search now lists the tool names it could have asked for.

Second, and worse, our own prompt contradicted the tool list. It said "the tools listed are ready to call, only search when nothing listed can do the job". Then, two lines down, it told the model to call our delegation and knowledge tools. Those weren't listed. A big model notices and goes looking. A small model believes the harness, sees the tool is missing, and stops.

That bug made eight local models "fail" one of our internal team tests on a tool they were never given. Every failing result we had recorded for those test tasks up to that day was measured this way. We were grading models on whether they would second-guess our prompt.

What fixed it: a sweep. We grep every tool name that our prompts and error messages mention and compare it against the set the model can actually see. Anything named but hidden is a bug. We also hide a tool entirely when it can't work. Our web search needs a key, and without it every call failed, yet the model kept calling it because it was listed. Now it only shows up when the key is there.

3. A tool cap that killed long runs at random

The search tool keeps the last 8 loaded schemas and drops the oldest. The tool itself still works after its schema is dropped. Only its description leaves the prompt.

On a long email run, after 14 searches, the model called a browser tool it had loaded much earlier. Its schema had already been dropped. Our adapter checked the name against that turn's list, didn't find it, threw "unknown tool" and killed the run.

This one happened on a big model through Claude Code, but it would hit any model. The model wasn't wrong here. It remembered a real tool. We had treated a cache miss in the prompt as a protocol violation.

What fixed it: the adapter now passes the call through. If the tool exists, it runs. If the model made the name up, it gets back a normal tool error it can recover from. A long run with many tools no longer fails at random.

4. A thinking model outran the save timeout

Bees agents keep a memory so they can skip things they already handled and stick to daily limits. At one point every memory save failed with "Extraction failed". Agents saw saves time out and recall return nothing.

The memory service uses the local model to pull facts out of text. That was Qwen3.5 4B, and with the chat template on, it thinks by default. It wrote 2,000 to 8,500 tokens of thinking for each fact extraction, at about 30 tokens a second. That is well past the memory service's 300 second timeout. And llama.cpp had one slot, so every other save queued behind it. When the laptop was deep in swap, output fell to about 1 token a second.

What fixed it was one field. Our bridge to the model now sends chat_template_kwargs: { enable_thinking: false } for memory calls. The same extraction took 1.8 seconds and 43 tokens.

If you run a thinking model locally behind anything with a timeout, check what it does by default. A reasoning model's real cost is the tokens it spends before it answers, and on a laptop those tokens are seconds.

5. Prompts don't bind small models, so check in code

After the fixes above, small models still took shortcuts. A run would say it wrote a report when the file was empty. A summary would describe a search that never happened. A model would ask the user a question with only one possible answer and stall the run on it. A model stuck in a loop would hand out the exact same batch of work again.

We had rules against all of this in the prompt. A small model reads a rule as a suggestion.

So the step where an agent hands in its result now checks the work instead of trusting the description:

A named deliverable has to exist and have content. An empty file doesn't count.
A summary may not name a tool that this run never actually called. We record every real tool call, so this check costs nothing.
A question with one option is refused.
A delegation that repeats the last batch exactly is refused.

The interesting part: a much bigger model tried every one of those shortcuts too. The checks bounced it, and then it did the work. So these aren't small-model crutches. They are how the harness should have worked from the start.

What we'd tell anyone building on small models

Read the raw model output and the exact tool list the model saw before you change models. Most of our "weak model" failures were our bugs.
Never let a prompt name a tool the model can't see. Sweep for it.
Treat an unknown tool name as a recoverable error, not a crash.
Turn thinking off for background calls that have a timeout.
If a rule matters, enforce it where the result is handed in. Don't just ask for it.

Bees is free and open source, on Mac, Windows and Linux, and runs agents on Claude Code, Codex, an API key or a local model. Download it at bees.bot, and the code is at github.com/Bees-bot/bees-desktop.

Day one of Bees in public: the honest numbers

Bees — Wed, 14 Oct 2026 14:46:34 +0000

Bees went public on 13 Oct. It's a free, open source desktop app that runs a small team of AI agents on your own computer. Here are the real numbers a day later, plus what surprised us.

The numbers

15 GitHub stars
4 forks
About 67 installer downloads across v0.2.0 to v0.2.2
0 issues opened by people outside the team
64 repo visitors in the last 14 days

Small, and that's fine. We'd rather know where we stand.

The biggest surprise

On 6 Oct someone we don't know posted a Show HN about Bees. That one post sent more people to bees.bot than all of our own posts put together. A stranger finding it worth sharing did more than anything we wrote about ourselves.

What we learned

Launch day was quiet. We expected a spike. We got a trickle.
Get to the point in the first seconds. One Reddit reader said our launch video took 15 seconds to get to the point. That's fair, and we're taking it.
Many launch sites block new accounts. A lot of the usual "submit your project" sites put a bot check or a paid tier in front of new accounts, so a good chunk of our launch list never happened.

What would help

If you try it and something breaks, or a screen makes no sense, please open an issue. Zero outside issues means we're flying blind on what real use looks like. Blunt feedback is welcome too.

Code and releases: https://github.com/Bees-bot/bees-desktop

Two ways into Bees: describe the job, or point it at your files

Bees — Tue, 13 Oct 2026 15:38:42 +0000

Most AI agent tools hand you a blank canvas and expect you to wire up the whole thing. We wanted the first ten minutes of Bees to feel different, so there are two easy ways in: tell it the job in plain English, or point it at the files you already have.

Bees is a free, open source desktop app that runs a team of AI agents on your own computer. It went public today. Here's how those two pieces work, each with a short video.

1. Ask Bees: describe the job, it builds the process

You write what you want done the way you'd say it to a person. Bees asks a few quick questions, creates an agent just for that job, plans the steps and sets a schedule.

Nothing runs until you press Apply, so you can read the plan first and change it. And if the job involves email, it asks before it sends anything.

2. Knowledge Base: search every file in plain words

Approve a folder once and Bees reads and indexes every file in it, right on your machine. Then you search in plain words instead of guessing file names.

Your agents read the same knowledge while they work, so a report or a reply can lean on your own documents instead of a guess. None of it leaves your computer.

Where it runs

You connect your own AI: Codex or Claude Code from the command line, a hosted provider, or a local model. There's no bill from us for the AI itself.

Download: bees.bot
Code: github.com/Bees-bot/bees-desktop (MIT or Apache 2.0)

What's the first job you'd hand to an agent if you trusted it to ask before doing anything risky? I'd like to know what people try first.

Agents that ask first and remember what you told them

Bees — Tue, 13 Oct 2026 15:28:27 +0000

The part of AI agents that worried us most wasn't whether they could do the work. It was whether we'd trust them to do it without watching every step. So three of the things we built into Bees are about that: agents that stop and ask, agents that keep what you told them, and a way to get more than one view before a decision.

Bees is a free, open source desktop app that runs a team of AI agents on your own computer. It went public today. Here's how those three pieces work, each with a short video.

1. Agents ask first

Finished work doesn't just go out. It waits under Needs your attention until you approve it, or send it back with a reason. You can also mark a stage as needing approval, and then its agent can't send, post, delete or pay through a tool until you say yes. When an agent isn't sure what you want, it asks instead of guessing.

Approval is off by default and you turn it on per stage, so you only pay the waiting cost where a mistake would actually hurt.

2. Tell it once

When a report is wrong, reject it and say why in plain words. You pick whether the note is for this run only or for every future run. If it's for every run, Bees writes your note into that job's playbook, so next time it gets it right.

The playbook is plain text you can read. You can edit or undo any change Bees made to it, which matters, because a rule you can't see is a rule you can't fix.

3. Roundtable: three views, one answer

Some questions don't have one obvious answer. Ask one in Roundtable and three agents debate it, each with its own job: one pushes for growth, one guards the money, one speaks for the customer. Then a lead agent writes one clear call, with every reason written down, so you can see what it weighed and disagree with it.

Where it runs

All of this runs on your machine. You connect your own AI: Codex or Claude Code from the command line, a hosted provider, or a local model. Your files, browser sessions and passwords stay on your computer.

Download: bees.bot
Code: github.com/Bees-bot/bees-desktop (MIT or Apache 2.0)

If you've run agents on real work, where did you have to add a human check? I'm curious whether it's the same places we found.

Bees is public: a free desktop app that runs a team of AI agents on your computer

Bees — Tue, 13 Oct 2026 15:28:26 +0000

Bees went public today. It's a free, open source desktop app for macOS, Windows and Linux that runs a team of AI agents on your own computer, instead of one assistant in a single chat window.

What it does

You describe an outcome in plain language, in the What would you like to achieve? box on Home. Bees turns it into stages on a shared board. Agents work through those stages, and a separate reviewer agent checks each result before the work moves on.

A small example from the README: ask it to browse Hacker News and give you a table of the current stories, grouped into news, Show HN and Ask HN. Bees plans the stages, the agents do the browsing and sorting, the reviewer checks the table, and the finished result lands in that run.

You bring the AI

Bees doesn't sell you a model. Under Settings, AI connections you connect one of these:

Codex or Claude Code from the command line, so Bees uses a subscription you already pay for
a hosted provider
a local model on your own machine, run through a bundled llama.cpp server

You can set a model per agent or one default for everything.

What stays on your computer

Your agents, files, browser sessions, cookies and passwords stay local. Bees opens a private workspace with no sign-in, so you can try it right away. It also runs its own local memory service, so agents remember past work without a cloud memory provider.

Control over what agents can do

Tools per agent. Agents reach outside tools through MCP servers. You can give one agent every tool, none, or a named few.
Approval per stage. Mark a stage as needing your approval, and its agent can't send, post, delete or pay through a tool until you say yes. Questions, approvals and failures show up under Needs your attention.
File scope. An agent in a run reads and writes inside that run's own folder.

Other things it does

Company Brain: local search over folders and Google Drive locations you map yourself.
Scheduling: turn a request into a recurring process, like a weekly report.

What's rough

The Mac build is signed and notarized. The Windows and Linux builds aren't code signed yet, so Windows shows a SmartScreen warning. You need 8 GB of memory for a cloud model, or 16 GB for a local one, plus 15 GB of free disk.

Try it

Download: bees.bot
Code: github.com/Bees-bot/bees-desktop (MIT or Apache 2.0)
Questions and ideas: GitHub Discussions

Two of us built this. If you've used a multi-agent tool before, I'd like to hear what made you trust it, or what made you stop.

How Bees works under the hood

Bees — Mon, 12 Oct 2026 14:54:16 +0000

Bees is an open source desktop app that runs a team of AI agents on your own computer. Earlier posts covered the review loop, where keys live, and team work without a central dispatcher. This one is for people who want to read the code.

Three processes and a webview

Bees is a Tauri app. The Rust side in src-tauri/src is small. lib.rs is about 1,100 lines and local_models.rs about 1,300. It owns the window, the tray, the updater and the installer. Its main job is to start and supervise other processes.

When the window opens, it shows a splash screen (src/entry.ts, under 40 lines) and calls one Tauri command, ensure_dsh_runtime. That command does the following:

Starts a local Temporal dev server on a random loopback port, backed by a SQLite file in the app data folder. Temporal is the workflow engine that remembers which stage each piece of work is at, so a restart doesn't lose its place.
Starts a bundled Node 24 runtime running dsh-runtime/start.mjs on a second loopback port, which it remembers between launches, with a fresh random token.
Waits for /healthz, then points the webview at the runtime's own URL with that token.

From that moment the whole interface is served by the Node process. The Rust side keeps polling /healthz every two seconds. If the runtime stops answering for about 30 seconds, it sends the window back to the splash, which starts a new one. A third process, llama-server from llama.cpp, starts only when you run a local model.

The Node runtime is DSH, short for DeepSeek Harness, an open source agent runtime. DSH gives us model providers, a credential store, sessions, the agent loop, tools, skills, an MCP client and approvals. MCP is the standard way to plug outside tools into an agent. Bees is written as DSH plugins on top of it:

dsh-runtime/plugin is the product: the board, schedules, runs, recovery, file boundaries, document search, audit records and the UI shell. The server code is in plugin/lib, the UI is in plugin/client.
dsh-runtime/plugins/* holds the model connections: local-ai, subscriptions (Claude Code and Codex), free-ai and custom-ai.

Product data lives in one SQLite file, bees-stage1.db. Tauri passes its path, along with every other folder the runtime needs, as environment variables when it starts Node.

How a run executes

A request becomes a work item in a process. A process is a list of stages, such as Work, Review and Done. Temporal drives the item from stage to stage. Each stage runs as a fresh agent session in its own run folder, with inputs/ and outputs/. The only files a stage carries in are the ones the previous worker stage left. The agent's base instructions live in RUN_PERSONA in dsh-runtime/plugin/lib/agent-runtime.js, which is the biggest server file at about 2,600 lines.

Before every tool call, agent-runtime.js checks the call. Paths outside the run folder are refused until the person approves that exact path. Folders that hold passwords, keys or Bees' own files can't be read at all. Small local models often write to /outputs/report.md with a leading slash, so the refusal tells them the relative path instead of only saying no.

Agents that edit shared files go through a lock tool. docs/file-access.md covers it. The agent acquires every destination path, reads again after the lock is granted, writes, and releases. Each replacement is written to a staging file and renamed over the target, so a crash never leaves a half-written file. Shell commands can still bypass these locks, and the doc says so.

The restart problem

This was the first trade-off we had to make on purpose. Bees can restart in the middle of a tool call. The app might crash, or an update might install. When it comes back, Temporal knows which stage was running, but nobody knows whether the last call finished.

For reading tools that doesn't matter. Running grep twice is fine. For a tool that sends an email or posts a reply, running it again could send it twice. Skipping it could lose it.

So recoveryToolContext in agent-runtime.js sorts the calls. A fixed list, REPEATABLE_TOOLS, holds the calls that are safe to repeat: reads, searches, fetches, and the stage submit, which commits in one transaction. Any other call without a recorded result stops the run with a message asking the owner to check whether the action happened. Once the owner continues, the agent gets the finished calls from the interrupted turn as evidence. It's told to reuse those results and to find out what the unknown call did before trying it again.

The cost is that some runs stop and wait for a person after a crash, even when the call never reached the outside service. We tried auto-retrying first. A run that hit this state once stayed stuck for good, and a retry that guessed wrong would have sent something twice. Asking the owner is slower, but it can't double-send.

Tools and add-ons

DSH provides skills and built-in tools. MCP servers are managed by Bees. Each enabled server is a row in bees-stage1.db, and Capabilities in plugin/lib/capabilities.js mounts one long-lived process for each row. Secrets go in DSH's credential store, never in the database. The servers shipped out of the box are listed in plugin/lib/mcp-catalog.js, and none of them installs without a review screen.

Each agent has an MCP access policy: all, none, or a named list. The browser is the exception to one process per server. Two runs browsing at the same time used to land on each other's pages, so each run now mounts its own browser server, which goes away when the run ends.

Approval is enforced at the tool call too, not only at the end of the stage. We started by checking approval when a stage finished. Then we noticed a bid or an email could go out before anyone had seen it. Now, if a stage needs approval, any MCP call that sends something has to be preceded by an approval recorded after the last outgoing call. This includes any non-GET API request and any browser step. So one approval covers one send, and a later rejection wins. Local-only servers like filesystem, memory and time skip the check. The query reads the run's audit events in SQLite, so the rule survives a restart.

Models: local, subscriptions and keys

The second trade-off is how we use Claude Code and Codex. For Claude Code, we don't hand the CLI our tools or let it run its own loop. plugins/subscriptions/lib/index.js calls the CLI with its own tools turned off and an empty MCP config. It passes a JSON schema that forces every reply into one shape: a tool name, its arguments, and text.

--tools "" --strict-mcp-config --mcp-config {"mcpServers":{}} --json-schema {...}

Bees then runs the tool itself, through the same checks every other model goes through. This means the file fence, the approval guard and the audit trail apply the same way whichever model you pick. The cost is that the CLI never sees real tool schemas, so it sometimes sends "1" instead of 1 or a list as JSON text. The plugin has code to repair those arguments. It's extra work on every turn, but the alternative was a second, weaker set of permission checks inside each CLI.

Local models run on llama.cpp's llama-server, which ships in llama-runtime/. The tricky part is choosing the context window. local_models.rs reads the GGUF file header without loading any weights, to get the model's trained context length and how many bytes of KV cache each token needs. Then it sizes the window so weights and cache fit in a third of system memory. The automatic window stays between 16k and 32k tokens, and a per-model override can ask for more. The comments explain why. Our 3B default model was trained for 262,144 tokens at 88 KiB each. Taken literally, that's 23.6 GB of cache. Below 16k, the roughly 4.5k tokens of instructions and tool schemas Bees sends leave no room for the model to answer.

llama-server runs with --parallel 1, one request at a time. local-inference.js queues requests in front of it, so five agents on a local model take turns instead of hitting timeouts.

What stays local and what syncs

A private organization, the default with no sign-in, never syncs. If a team turns on sync, the optional Bees Cloud server receives organizations, members, process templates, runs, work items, schedules, agent definitions, the titles you type, and a folder's ID and relative path. File contents, credentials, model connections, the search index and run folders stay on the machine. The sync code is in plugin/lib/team-sync.js. The desktop app is fully open source. Bees Cloud lives in a separate closed repository.

What's rough today

The UI is one huge file. dsh-runtime/plugin/client.js is about 30,000 lines. It's the hardest file in the repo to navigate.
We patch DSH at install time. We pin DSH to 0.1.7-rc.2, and scripts/install-dsh-runtime.mjs reapplies a few exact-match patches to it. One batches client module builds, which took DSH boot from 22.7 seconds to 2.9 seconds in our measurements. Every DSH upgrade means rechecking those patches. docs/dsh-upgrade-checklist.md lists the steps.
The agent's Chrome debugging port has no password. docs/limitations.md says this plainly. Port 9333 has no auth, so another program on the same machine could drive that browser while it runs. We plan to close it.
Mac gets far more use. Windows installers aren't signed yet, and the Linux and Windows builds have seen much less real use.
0.1.1 data doesn't carry over to 0.2, because the database changed.

Reading and building it

To be upfront: we don't take outside pull requests right now. We are a small team, and reviewing a PR properly takes longer than making the change. CONTRIBUTING.md explains this. Bug reports, feature requests and forks are all welcome, and a bug report that points at the right file is a big help.

You need Node 24 (pinned in .nvmrc), Rust 1.88+, and CMake on macOS for the first llama-server build.

npm ci
npm run check        # typecheck, project checks and build
npm run prepare:dsh  # stage Node, llama.cpp and uv for the Rust build
make bees            # run the app against the hosted API

Good files to start with:

src-tauri/src/lib.rs, at ensure_dsh_runtime_blocking, for the whole launch sequence.
dsh-runtime/plugin/lib/agent-runtime.js, for the run persona, the tool guards and restart recovery.
dsh-runtime/plugin/lib/capabilities.js and mcp-catalog.js, for add-ons.
docs/startup-timing.md, if startup feels slow. Every launch writes [bees-startup] JSON lines to dsh-state/startup.log, with no URLs or prompts in them.

Code: https://github.com/Bees-bot/bees-desktop
Download: https://bees.bot/download/
Questions: https://github.com/Bees-bot/bees-desktop/discussions

What happens when you reject an AI agent's work in Bees

Bees — Thu, 08 Oct 2026 14:11:18 +0000

Most agent tools give you two choices when the output is wrong. Start over, or edit the prompt and hope. We wanted something in between for Bees, the open source desktop app we build that runs a team of AI agents on your own computer.

Every goal gets a reviewer

A goal in Bees runs through three stages: Work, Review, Done. A work agent does the job. Then a fresh reviewer agent checks the result. It gets the goal, the deliverables and the evidence Bees recorded, but not the worker's private reasoning, so it judges the result on its own.

If the result falls short, the reviewer sends the same item back to Work with specific feedback, and the next attempt sees both the old output and the notes. Retries are capped. A goal that keeps failing stops under Needs your attention instead of looping all night.

You can also put yourself in that loop. A goal or a stage can ask for your review, and then you get Approve or Reject. Reject needs a reason.

The reason has a scope

This is the part I think matters most. On a one-off goal, your reason goes back to the agent for a revision and nothing else changes.

On a scheduled job, say a weekday support briefing, Bees asks where the reason should apply:

This run only: the agent revises this run, and future runs behave the same as before.
Future schedule runs: the reason is also added to a playbook for that job.

That playbook belongs to a specialist. The first time an agent handles a named schedule, Bees creates a specialist for that pair. It inherits the base agent and only adds the job-specific notes. So a lesson like this one:

Do not count auto-replies as customer conversations.

sticks to the support briefing. It doesn't leak into everything else that agent does.

What it doesn't do

One-off goals never change future behavior.
The reviewer can't edit the worker.
Nothing changes because of a score.
No rejection changes the base agent for the whole organization.

Saying no to a tool action is kept apart from rejecting the work, too. If you deny an agent sending an email, that's a permission call for this moment. It doesn't turn into a rule.

You can see it and undo it

Under Process Runs → Schedules, each specialist shows its playbook, a revision number and the history of where each change came from: your feedback, a manual edit, an undo or a reset. You can edit it, undo the last change, or reset it to empty and go back to the base agent.

We picked this over automatic learning for a simple reason. "Bad result" makes a bad rule, and a rule you can't see is worse. A specific reason written by a person, scoped to one job, is something you can check later.

Bees is free and open source (MIT or Apache 2.0). Version 0.2.0 runs on Mac, Windows and Linux, with your own Codex or Claude Code subscription, a hosted model, or a local model.

Download: https://bees.bot/download/
Code: https://github.com/Bees-bot/bees-desktop
How the review loop works: https://bees.bot/help/loop-engineering
Specialists and playbooks: https://bees.bot/help/self-improving-agents

Why execution stays local

Bees — Tue, 06 Oct 2026 09:37:51 +0000

This post first appeared on the Bees blog.

Most agent platforms ask for your files. Upload the folder, connect the drive, grant the scope — then the work happens on someone else's computer. That is a reasonable trade when the files are a support inbox. It is a bad trade when they are contracts, payroll, patient records, or source code.

Bees draws the line somewhere else. Agent runs happen on your computer, against files in storage you already control. What synchronizes to Bees Cloud is coordination metadata: which process a work item sits in, which status it moved to, which agent picked it up, and relative filenames and paths. Not the file contents.

Why it is a boundary and not a setting

A privacy toggle is a promise about behaviour. A boundary is a statement about where the code runs. If execution happens on your machine, there is no server-side copy to leak, subpoena, or accidentally log — regardless of what any setting says.

That choice has consequences worth knowing before you adopt it:

Your machine does the work. Throughput is bounded by your hardware and your model access, not by a plan tier.
Coordination still needs the network. Teams that never connect still run, but they do not see each other's progress.
Model choice is yours. Run local models, use an existing Codex or Claude Code subscription, or point at a model API. The file contents go wherever you point them — which is exactly why the decision stays with you.

Where this shows up in practice

The clearest case is a regulated team that wants agents but cannot move documents off managed storage. They keep the documents where compliance already approved them, install Bees on the machines that already have access, and get shared status across the team without the files ever becoming someone else's asset.

Start with Getting started, or read why Bees exists for the longer argument.

Your keys and logins stay on your computer

Bees — Tue, 06 Oct 2026 09:36:35 +0000

This post first appeared on the Bees blog.

An AI agent that does real work needs real access. It needs an AI key to think with, your Google account to read your mail or Drive, and a logged-in browser for the sites that have no API.

Most hosted agent products keep all of that on their servers. You paste your key into their web page. You click "Connect Google" and the refresh token (the long-lived pass that lets an app back into your account) goes into their database. Their browser runs in their cloud, holding your cookies.

That works, but it means one company holds a copy of every key and session its users have. One breach, one careless log line or one curious employee reaches all of them at once.

Bees does it the other way. The agents run on your computer, so the keys and logins can stay there too. Here is where each one lives, and what our server sees.

AI keys

When you add a key for OpenAI, Anthropic, OpenRouter or Google, Bees first sends one small test request straight to that provider to check the key works. Only then does it save the key on your computer.

After that, your prompts go straight from your computer to the provider. No Bees server sits in the middle, so we never see the key or the prompts. Google keys go in a request header rather than the web address, because addresses end up in logs far more often than headers do.

The default model runs on your own computer. With it, your prompts are not sent to any AI company.

Google: Gmail, Calendar and Drive

Connecting a Google account happens on your computer. Bees opens Google's consent page in your browser. Google then sends you back to a small listener on your own machine (127.0.0.1), which shuts itself down after a few minutes.

The tokens Google hands back are saved on your computer. The Gmail, Calendar and Drive add-ons read them from there and call Google directly. Our server never receives them.

Signing in to Bees itself with Google is different, and we want to be clear about it. Our server learns your name and email so it can create your Bees account. It does not get access to your mail, calendar or files.

Browser logins

Some work only happens in a browser: a site with no API, or a dashboard behind a login. A hosted agent runs that browser in its own cloud, so your cookies, the things that keep you logged in, live on its machines.

Bees drives the Google Chrome already installed on your Mac, with a separate profile that belongs to Bees. Your everyday Chrome profile is not touched. You log in to a site once inside the Bees profile, and those cookies stay in that profile's folder on your disk. Bees also saves a copy of them to a local file, so you stay logged in after a restart. None of that code talks to our server.

We use your real Chrome instead of a bundled test browser for a practical reason: Google refuses sign-ins from browsers that announce they are automated. For now the agent's browser works on Mac only.

Where the keys are kept

AI keys, Google tokens, add-on keys and your Bees session all go into one credentials file in the Bees folder under your home directory. On Mac and Linux, Bees creates that file so only your user account can read it, and refuses to start if someone loosens that.

The screen where you manage AI keys is only told whether a key is set, never the key itself. When a run's history shows a tool call, values with names like token, password or API key are shown as hidden.

What our server does see

Bees Cloud is optional. It exists so a team can see each other's work. When you use it, the app sends seven kinds of records, each with a fixed list of fields:

the names and settings of your processes, agents and schedules
work item titles, status and who owns them
file names and paths relative to a shared folder, never full paths from your disk and never file contents
a summary of each run, capped at 20,000 characters

It never sends keys, tokens, cookies or file contents. One honest caveat: a run summary is the agent's own words about what it did, so it can mention things from your files.

The app sends no usage analytics and no crash reports. It starts its agent engine with telemetry switched off, and there is no analytics code in it. It does ask our server for its sign-in settings when it starts, even if you never sign in. That request carries no account token and no usage data, but like any request it shows us your IP address. It also asks GitHub whether a new version is out, when it starts and every six hours. That request goes to GitHub, not us. It names only the update tool Bees uses, not you or your Bees version, and your computer compares the versions itself.

What this does not protect you from

A cloud model sees what you send it. If you pick a cloud AI model, the text an agent works on goes to that AI company under its own terms. Use the local model when that matters.
The credentials file is not encrypted. It is protected the way your SSH keys are, by file permissions. That stops other users on the same computer. It does not stop malware running as you.
A run folder is not a full sandbox. Bees gives each run its own folder with only the files it needs. That narrows what an agent can touch, but it is not a wall against hostile code.
Your computer has to be on. Agents run on your computer, so they only work while it is awake.

We think this is the right trade for a desktop app that handles work files and real accounts. If a hosted tool fits you better, that is a fair choice too. Just ask it where your refresh tokens live.

If you want to try Bees on your own machine, download it here.