Netclode

The deciding trait is the phone in your pocket. There is a native client for iOS and macOS, so kicking off a task from a sofa and reading the result on a screen the size of your hand is the normal way to use it rather than a party trick. For anyone who has wanted a cloud agent without a vendor holding the code, that combination is rare.

You are the wrong buyer if operating infrastructure is not already your job. Pick it if you enjoy running things. Pick a hosted agent if you do not.

The install is a distributed system. Before a prompt runs you are operating an orchestrator, a microVM runtime and a hypervisor, plus the storage layer underneath them, and each of those is a component with its own upgrade path and its own failure modes. The agent is the small part. The infrastructure is the commitment, and nothing here reduces it.

What it does right is earn the permissions it takes. Running with root inside the box is defensible precisely because the box is a virtual machine rather than a namespace.

1. The design addresses the standard objection to hardware-level isolation, which is start-up cost, by keeping machines booted in advance and handing one over on demand. That converts a latency problem into a capacity problem, which is the easier of the two. 2. Session events are persisted, so a disconnected client resumes rather than restarts.

2. Both choices are conventional distributed-systems practice applied to an unconventional setting, which is the correct direction to borrow. No evaluation is published and none is claimed.

252 stars for something this involved tells you the audience is small and technical. There is no company, no hosted tier and no price, so the real cost is a platform engineer's time, and that number is larger than any subscription this replaces.

Moat: none, and the sophistication is not a moat because it is published. Likely acquirer: none; this is a personal system generously shared. Likely path: it tracks its author's own needs. Position: study the architecture, and do not plan a team's workflow around a single person's cluster.

The credential design is better than most commercial products I have reviewed. Repository access comes through scoped tokens issued per repository rather than a developer's personal credential, and provider keys sit behind a proxy so the sandbox never holds them. Those are the two questions my security team asks first, answered before they asked.

Everything else is unbudgeted. Sixty engineers means cluster capacity, storage and the people who keep it running, and there is no SSO, no audit log and no retention policy. Not yet, and the blocker is operating cost.

Published source with no licence file is not open source, it is code you can read and cannot lawfully use. That is the one thing I will not wave through, because a fork, a patch and a deployment all depend on a grant that has not been made. Ask the author. It is probably an oversight.

Everything else is what I want: Ollama can serve the models on my own card, the whole system runs on hardware I own, and nothing about my repository has to visit a vendor.