StarNet — AI Agents Working From a Pixel Space Station

I spent a few days with StarNet, a local-first harness that puts a pixel space station on your desktop, places AI agents in it, and makes them do real work. No subscription, just your own key — attractive, but it snagged me in a few places I didn't expect. What worked and what didn't, together.
Markdown source·Anything to add or correct?

StarNet — AI Agents Working From a Pixel Space Station

Most cloud AI agent platforms hide their process behind a chatbot window and charge a monthly subscription per head. Let the team grow even a little and the burden climbs fast. It's a structure where the wallet cries once for every new hire.

So I installed the open-source local desktop harness StarNet (github.com/androoAGI/starnet) and ran it for a few days. The short version: the fun is genuinely worth the money. That said, you have to drop the expectation that "you just turn it on and it runs itself." I had that expectation on day one and it bit me. Here's what worked and where I got snagged, together.

What StarNet is

One line:

A local-first harness that puts a pixel space station on my desktop, places AI agents inside it, and makes them actually work.

The fun part is that the pixel art isn't decoration. The developer (Andrew Sims) nails it down in the README:

  • A room is a team with defined permissions
  • A corridor is an approved handoff path
  • An object you place is an actual grant of authority

Put simply, the layout you draw is the workflow the agents will execute. Instead of reading through log lists, you find bottlenecks by watching the agents communicate and move around the station.

Technically it's a Tauri (Rust) desktop shell plus a Node sidecar, and model calls are streamed through that local sidecar. The code is MIT licensed, and it has about 1.2k stars.

Install to first agent

Installation itself wasn't hard. Grab the installer for your OS from the official releases page.

  • Windows 10/11 (64-bit): StarNet_<version>_x64-setup.exe
  • macOS (Apple Silicon M1–M4): StarNet_<version>_aarch64.dmg
  • macOS (Intel): StarNet_<version>_x64.dmg

There's also a way to run from source. All you need is Node 18+.


git clone https://github.com/androoAGI/starnet.git
cd starnet
node sidecar/index.js

Then open http://localhost:8787 and connect a provider.

Model wiring comes in three flavors:

  • Paste an OpenRouter key (BYOK)
  • Log in with Anthropic / OpenAI / Google
  • Ollama for local models (no key, no account needed)

Here's the first thing I liked. Keys are stored in the OS keychain and don't linger in the frontend. It says local-first, and it's actually designed that way.

When you first launch the app, a retro pixel spaceship base pops up. Watching the dot characters dock and walk the corridors for a moment makes you wonder "is this a game?" I watched the first five minutes like a new game tutorial. But each of those characters is a separate agent with its own workspace, memory, permissions, and dedicated tools. It's a cute admin console.

Actually running it

I placed three or four agents and split up the roles:

  • Researcher: web search and parse tools only
  • Coder: read/write on a designated folder plus CLI execution
  • Reviewer: read-only, no file modification permission

The most satisfying part was isolated permission control. Even if an agent messes up, the whole system isn't at risk. For instance, tell the reviewer to fix a file and it simply can't — no permission. You feel the difference immediately. Watching an agent reply "you don't have permission" is like seeing an employee whose paperwork is stuck because the manager didn't stamp it. Weirdly satisfying.

The handoff between agents shows up as a pixel animation. The researcher's material getting passed to the coder gets logged on the timeline. Calling several models at once was also smooth.

Before important actions (editing a file, running a script), an audit log pops up and a human clicks approve or reject. The point where a human intervenes is clear, which is reassuring.

When a job finishes, the output drops into the OUTBOX as an actual file. No digging through the chat scrollback.

What didn't work (failure cases)

This is where the real review starts. If I only wrote what worked, it wouldn't be a review — it'd be an ad. The six below are in the order I actually stubbed my toes.

1. I downloaded the Intel DMG on Apple Silicon

At first I absent-mindedly grabbed the x64 DMG. On Apple Silicon that runs under another layer of Rosetta 2, so much heavier than native. Like running a marathon in someone else's shoes. The README says "if you're on Apple Silicon, use the native aarch64 DMG" and I flat-out missed it. Only after re-downloading aarch64 did I get normal speed. 100% my fault, nothing to argue.

2. Long jobs on local Ollama got rough

I connected Ollama to use it without keys. Pull with ollama pull qwen3:8b and set the provider to OLLAMA. StarNet connects to 127.0.0.1:11434 and only marks itself ready after actually reading the local model list.

The problem was performance. Short jobs were passable, but longer ones were slow and the output was rough. The README warns honestly too: local models are smaller than cloud ones so they'll be slower and rougher, the tasks need a large context window, and an 8B model grabs around 10GB of graphics memory while it works. That's exactly what happened. I handed a big job to an 8B model and came back after two coffees and it was still writing the first paragraph. I started to wonder whether that 10GB of graphics memory was going into drawing the pixel station or into the model thinking. In my environment I decided it's only good for short tidying tasks.

3. I couldn't get it onto a Linux server

I thought "it'd be great to run this on a server continuously," but the Linux package is just an internal build artifact, not an official distribution target. Official support is Windows and macOS only. Disappointing for a Linux user. So I gave up on running it on a server from the start. With no server to run overnight, Night Shift is just a feature with a cool name.

4. Imported my existing agents, but the keys didn't come along

There's a feature for importing agents from OpenClaw or Hermes. Persona, instructions, memory, and model all come across fine. But the API keys do not. A sensible design from a security standpoint, but it caught me off guard at first. Personality and memory follow you, wallet doesn't. You have to re-enter them in the KEYS tab.

5. macOS is still shallowly validated

It's stated in the README. As an early release, Windows has been tested the most and macOS has comparatively little real-world validation. I used it mainly on Windows, and colleagues on Mac hit occasional minor bugs.

6. "Perfect data isolation" is only half true

Local-first, yes, but with conditions. Station state, conversation history, memory, and the spend ledger stay on my PC. But if you connect a cloud model and run agents on it, those requests go out to the provider. Obvious enough, but don't misunderstand "it's local so nothing leaves." Connecting a cloud model and saying "it's local so it's safe" is like locking the front door and throwing the windows wide open. If you don't want anything going out, use a local model or read the privacy docs.

So is it worth using?

To sum up.

The good

  • No per-head subscription. You only pay for the API you use (or run a local model).
  • There's real runtime state behind the pixel screen. You read bottlenecks by movement, not logs.
  • Permission isolation genuinely works. When an agent causes trouble, the blast radius is contained.
  • Approval gates, audit logs, and the OUTBOX round out a practical workflow.

The weak

  • The initial setup is foreign to non-developers. API keys, permissions, MCP wiring.
  • Running multiple agents on a local model will tax your PC specs.
  • Linux unsupported, macOS under-validated.

Wrapping up

StarNet isn't a cute pixel agent app. It's a local harness aimed at individual developers and security-sensitive teams who held off on cloud agents because of security and cost. In short: you don't pay subscription, you pay electricity.

If you want to run several agents while keeping control of them on your own device rather than leaving them in a black box, it's worth an afternoon. That said, I'd recommend starting your first attempt with one short task, checking where the local model's limits are, and only then attaching a cloud model. You'll hit most of the disappointment points in advance. Two coffees and a few stubbed toes is cheap tuition.

Note: This post was organized after checking StarNet's official repository (README, INSTALL.md, PRIVACY.md) and release info. Most of the limitations listed in the failure section are stated in the repository itself.