holaOS

You will get value from this if your work arrives through conversations rather than through tickets. The deciding trait in daily use is proximity: chat tools, authenticated integrations and small interactive apps sit in the same window as the agent, so asking it to act on something someone just sent you does not involve copying context between four programs. It is a workspace first.

Pick it if the assistant's job is your day rather than your repository. Pick Manus if you want the same breadth hosted, or Kun if you want a local workbench that is genuinely aimed at code.

Read the capability row before the tagline. This executes nothing and edits nothing across files; hosted agent CLIs do that, and they do it with their own permissions, their own defaults and their own failure modes. What is being evaluated, then, is a container for other people's tools, first released a month ago. Judge it as furniture, not as an engineer.

What it does right, and it is not a small thing: workspace files, memory, embeddings and session history stay on the user's disk, so the default posture is local rather than uploaded.

The interesting design is shared state. 1. Two third-party agents and a built-in one operate over a single memory store, which is the correct ambition, since handoff between agents is normally the lossy step. 2. The documentation does not specify the record format, the write discipline, or what happens when two agents disagree about the same fact, and a shared mutable store without those answers is where the hard bugs live.

No evaluation is offered and the documentation is thin for a claim this central. The idea is sound; the specification that would make it checkable is absent.

This is a deliberate structure rather than an accident. The modified terms block anyone else from running it as a commercial service, which keeps the hosted business exclusive while the repository does the customer acquisition. Above the free desktop build sit a Growth plan at $499 a month and a Scale tier starting at $3,000, so the intended revenue is organisational, not individual.

The risk is that the free build is good enough forever and the paid tiers sell integrations rather than intelligence. Likely acquirer: a workplace collaboration vendor buying the integration surface. Position: use the free build, treat the cloud pricing as unsettled.

The desktop build is free, which is the version I would actually deploy, and the moment it becomes a hosted product the number is $5,940 a month for my sixty engineers before integration usage is metered on top. For that I would expect an identity story, and the row records none: no single sign-on, no SCIM, no audit trail. There is no headless mode either, so nothing here participates in a pipeline or leaves an artefact behind.

Onboarding is a day, mostly integration consent screens. Not yet. The free build only, and nothing connected to production systems.

Let us be precise about the licence, because the project is not: commercial hosting and branding carve-outs on top of a permissive base make this source-available, and a fork that tried to compete would be in breach rather than in business. That caps how much I can own it.

What I do get is real. Any OpenAI-compatible or Anthropic-compatible endpoint can be configured, so inference runs on my own machine and nothing goes out; MCP servers attach as a client; and the install is a shell script I can read before running. Source I can read and a fork I cannot ship is half ownership.