starnet: a pixel-art station where the diagram is the permission model
A living pixel-art station where real AI agents do real work. Local-first desktop agent harness - bring your own key, watch your crew actually run.
At a glance
- What is it?
- A Tauri and Node harness that renders running agents as rooms, hallways and placed objects, then makes those objects real capability grants. Useful, opinionated, and refreshingly candid about what its own release train broke.
- Who is it for?
- starnet is genuinely interesting where most agent tooling is a chat box with a tool list attached, because the spatial layout is not a skin over a config file. Rooms scope teams, hallways gate handoffs, and a placed object is an actual grant the runtime enforces.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Star history
- androoAGI/starnet1,587 ★ · +354
| Repository | 2026-10-08 | 2026-10-23 |
|---|---|---|
| androoAGI/starnet | 1.2k | 1.6k |
354 Stars in the last 15 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
The station is a projection, and the README insists on it
The repository description calls StarNet a local-first desktop agent harness, and the README spends its first screen on a claim most agent projects avoid making. A room is a capability-scoped team, a hallway is an authorized handoff lane, and a placed object is a real capability grant. The layout you draw is the workflow the agents run. That is a design commitment rather than a slogan, because the alternative is a settings page where the same relationships live as free text nobody maintains.
The stated product law is that the interface must never assert state the harness cannot prove, followed by a list of what is real: model calls stream through a local Node sidecar, tools operate through explicit capability and consent checks, memory, transcripts, spend records, tasks and schedules persist on disk, and multiple agents run concurrently with separate workspaces and bounded permissions. StarNet says it does not simulate revenue, completed work, model activity or spend. For a project with a pixel-art front end, that is the sentence worth reading twice, because the visual language invites exactly the opposite assumption.
The screenshot caption makes the same point in different words, describing the station as rooms, crew and workstations rendered from live harness state. So the pixels are a projection of runtime state, not an illustration sitting next to it.
Running the sidecar from a clone with no install step
The cheapest way to evaluate the project is three commands and no dependency install, because the sidecar is written against Node core modules only:
git clone https://github.com/androoAGI/starnet.git
cd starnet
node sidecar/index.jsYou then open `http://localhost:8787` and connect a provider. Requirements are Node.js 18 or newer, with Node 22 matching CI, plus Git. Rust and the Tauri prerequisites are needed only for the desktop shell, which is a clean split: the runtime you want to judge does not require the toolchain that packages it.
Desktop development needs the install, and the two npm targets are commented in the README:
npm ci
npm run desktop:dev # dev shell
npm run desktop:build # build installers locallyThe `package.json` script list shows how much machinery sits behind those two commands. There are separate MCP and ACP server entry points at `sidecar/mcp/serve.js` and `sidecar/acp/serve.js`, a seeded dev mode, an audit script, a longhaul audit with a 3000 scale budget enforcement flag, an HTTP test suite driven by a test list file, a fast test runner, and a screenshot script. Tests are wrapped in a timeout harness labelled per suite with hour-long and fifty-minute budgets, which tells you these are long-running integration tests rather than unit tests.
A security patch that disabled the web tools for nine days
The release notes are the most useful document in the repository, and the reason is that they record regressions instead of hiding them. Version 0.13.1, published 2026-10-04, is described as a repair update, and its first entry says web requests work again: since 0.12.5, every web request an agent made could fail with a fetch failure, even for ordinary sites. The previous release, 0.12.5 on 2026-09-28, had announced a large security update. So a hardening change broke the agent web tools completely for roughly nine days, and the fix came in the following version rather than a patch on the same day.
The rest of 0.13.1 is a list of things users had noticed: group chats save and show membership, the COMMS view reads like a conversation, crew members no longer freeze in hallways, each floor OUTBOX shows only its own line of work, schedules let you pick which identity an agent runs as, and spending limits now hold during retries. Six defects from ordinary use, fixed in one release, is a reasonable ratio for a project shipping weekly.
The same release notes also state that the downloads are mirrored byte-for-byte from a validated distribution release, and that an existing install can update from inside the app with crew, sessions, keys and station intact. Combined with the signature requirements described below, that is a careful release process for a product that distributes executables.
Autonomy, routine timeouts and spend ceilings all tightened in three weeks
Read the three most recent releases together and a clear policy direction appears: defaults became more conservative. Version 0.12.5 introduced a hard cap where a metered run stops once spend in the last 24 hours reaches $25, with a RESUME button in Budget and a setting where 0 turns the limit off. Version 0.13.0 then changed three more defaults: stations that never set autonomy now start at SUGGEST rather than something more permissive, routines stop after 90 minutes, and a StarNet-credits run stops at $2 unless a per-run limit is set.
Every one of those changes is a breaking change for an existing user, and the project labels them Heads-up rather than burying them. It goes further in 0.13.0 by saying that going back to 0.12.5 drops made props and plugin terminals, which is a clear statement that downgrades are lossy. For an application holding agent workspaces and spend records on disk, that asymmetry is worth planning around: read the heads-up list before upgrading, and keep a copy of your workspace.
The feature list explains what those numbers are protecting. Night Shift lets agents keep working inside an explicit adjustable leash with every away-action logged and reviewable, and the OUTBOX is where deliverables land as real files rather than chat scrollback. Budgets and run history are described as real ledgers persisted on disk and shown as is. The spend ceilings and the ledgers are two halves of the same decision, and the fact that both exist is a better argument for the default than any amount of documentation about restraint.
Binaries live in a second repository, and Linux is not a target
The download badge, the homepage field in `package.json` and every release table point at `androoAGI/starnet-releases`, not at this repository. The one you are reading is source only. That split is common for projects that want a clean source tree, but it means the tags in this repo and the installers a user downloads are separate histories, and a version number is the only thing joining them.
Public builds cover Windows and macOS. Windows 10 and 11 get an x64 setup executable, Apple Silicon gets an aarch64 disk image covering M1 through M4, and Intel Macs get an x64 image, with an explicit warning not to run the x64 build under Rosetta 2 on Apple Silicon. Linux is named directly: packages exist as internal build artifacts and are not a supported public release target. That is an unusual thing for a README to state plainly, and a useful one, since Tauri normally makes Linux the easy target.
The signing requirements are described as pipeline gates rather than as proof about your copy. A release will not stage unless the Windows installer passes Authenticode and timestamp verification, both Mac builds pass Developer ID checks and Apple notarization, and every updater artifact carries a valid updater signature. The README immediately qualifies this by saying those are pipeline requirements and not evidence that a particular downloaded copy was tested on your machine, and points at INSTALL.md for what to verify and when to stop. The early release note adds that Windows is the most-tested target and macOS has less real-world coverage. If you are on a Mac, that is the line to read twice before filing a bug.
Local-first means local storage, not local inference
The privacy claim needs the qualifier the README gives it. StarNet is described as local-first, and station state, transcripts, memory and ledgers stay in the local workspace. But the same paragraph states that provider requests leave your machine when you run an agent. Bring your own key means you hold the credential, not that the inference happens at home, so the badge reading local-first, your machine, your data is accurate about storage and easy to overread about compute.
The project is honest about the offline alternative and its limits. With Ollama installed and a model pulled, you can pick OLLAMA as the provider, and the app talks to `127.0.0.1:11434` and only reports readiness once it can list your local models. The advice to pick a tool-supporting model matters, because agents act through tool calls and a model without tool support will produce text instead of work. The caveat is stated without hedging: local models are smaller, expect slower and rougher work on long tasks, a large context window is required, and an 8B model takes about 10 GB of graphics memory while it works.
Two features carry real data-leaving risk that PRIVACY.md is said to map. The MCP connectors let you attach external servers, and the messaging integrations wire agents to Telegram, Discord, Slack, Signal or Matrix. Both are the point of the product and both are network tools, so the honest sequence is to read the data map before enabling the first connector rather than after an agent has already used one.
For a different angle on the same design question, the import path is unusual: pointing StarNet at an on-disk OpenClaw or Hermes home mints an agent from the persona, instructions, memory and model it finds, with API keys deliberately not transferred. That is a migration feature built by someone who expects users to arrive from a competitor.
Editorial conclusion
starnet is genuinely interesting where most agent tooling is a chat box with a tool list attached, because the spatial layout is not a skin over a config file. Rooms scope teams, hallways gate handoffs, and a placed object is an actual grant the runtime enforces. What you accept by installing it is a young product making sharp policy changes on a short cycle: autonomy defaults, routine timeouts and spend ceilings all tightened between 0.12.5 and 0.13.1, and downgrading is documented as lossy. The sidecar runs from a clone with no install step, which makes it the cheap way to judge whether the model fits your work. Read PRIVACY.md for the data map before enabling a connector, and set an explicit per-run spend limit in Budget rather than relying on the default.
Frequently asked questions
What is StarNet used for?
It is a local-first desktop harness for running several AI agents as a team. You place agents into rooms that scope capabilities, connect rooms with hallways that authorize handoffs, and give agents capabilities by placing objects, and the layout is the workflow the runtime enforces. Work can be scheduled, run on cron, delivered into per-floor OUTBOX folders as files, and reached from Telegram, Discord, Slack, Signal or Matrix.
Does StarNet work on Linux?
Not as a public release. The release train covers Windows and macOS, with an x64 setup executable for Windows and separate aarch64 and x64 disk images for Macs. The README states that Linux packages are internal build artifacts only and not a supported public release target. The sidecar itself is plain Node and runs anywhere Node 18 or newer runs, if you want to evaluate the runtime without the desktop shell.
Can I run StarNet without paying for an API key?
Yes, through Ollama. Install Ollama, pull a model such as qwen3:8b, and pick OLLAMA as the provider on the first-run brain screen or later in SETTINGS, PROVIDERS. StarNet checks readiness by listing your local models over 127.0.0.1:11434. Pick a model that supports tools, and expect roughly 10 GB of graphics memory for an 8B model on long tasks.
Where are the StarNet installers published?
In a separate repository, androoAGI/starnet-releases, not in the source repository. The README badge, the package.json homepage and each release table all point there. Releases will not stage unless the Windows installer passes Authenticode and timestamp verification, both Mac builds pass Developer ID checks and notarization, and updater artifacts carry a valid updater signature.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/androoagi-starnet)Star history chart for your README
[](https://hysenlabs.com/projects/androoagi-starnet)Was this useful?