Sutando: a self-hosted Mac voice agent that rewrites its own code

What Sutando solves for a single Mac owner

Most agent projects assume a server and a team. Sutando assumes one person and one laptop. The README frames it as a Stand: a personal spirit that fights on your behalf, named after the JoJo's Bizarre Adventure concept, and it starts unnamed until it learns your style and generates its own avatar. That framing is not decoration. It signals the design target: a long-lived process that accumulates context about one operator rather than a stateless API you call.

The concrete jobs are mundane and specific. You are looking at a document and say "make this paragraph shorter"; Sutando reads the screen, rewrites the paragraph, and replaces the original text. You say "join my 2pm call" and it reads your calendar, joins Zoom through the desktop app or Google Meet through the browser with computer audio, screenshots participants, and writes a summary. You call it from your phone and say "summon" to open Zoom with screen sharing so you can watch its screen while walking around.

The audience is narrow on purpose. You need a Mac, a terminal, and enough patience to configure service credentials for the parts you enable. The README is explicit that no pay-per-token core API key is required: Sutando runs through the Claude Code or Codex CLI session you select. That is the single most interesting economic claim in the project, and it is also the claim most worth verifying against your own CLI plan before you commit.

How the proactive loop and the channel bridges fit together

The architecture is documented in docs/architecture-boundaries.md, which the README calls the normative definition of core, adapters, apps, skills, tooling, and workspace state. The picture that document accompanies shows two realtime paths and one batch path. Voice and phone agents use inline tools for instant actions. Telegram and Discord bridges queue larger work into a tasks/ directory. A scheduled proactive loop watches tasks/. The core agent then executes work with whatever tools are available and returns results to each channel.

The scheduling detail matters more than the diagram. The core agent's loop is a cron job that fires /proactive-loop every 15 minutes, written as */15 * * * * in the per-host crons.json. On Claude, Sutando backs that off to every 30 minutes when 7-day quota utilization reaches 80%. That is a real design decision: the agent throttles itself against a subscription quota rather than a per-token budget, which is consistent with running on a CLI session instead of an API key.

Self-development is on by default. The .env.example states that autonomous self-development is ON by default, that product deployments can turn it off while keeping owner tasks, health checks, and task delivery active, that invalid values fail closed (self-development disabled), and that you must restart the core after changing the value. Most of Sutando's code, per the README, was written this way.

Multi-machine behaviour is coordinated rather than scripted. The README says that when you plug in a second Mac, the original agent opens a Discord channel, sends setup commands, and migrates services, with the new machine handling phone calls 24/7 while your laptop stays portable. There are no migration scripts; the two agents negotiate the handoff. That is an unusual claim and it is the part of the design I would test first on a spare machine.

Installing Sutando and getting one real task done

The README says to clone the repository, build it, and run it locally on your own Mac. A packaged Mac app exists as a preview at sutando.ai with access by request; the source route is the one this article covers. Start by copying the environment template, because the README states Sutando will not start without the required values.

cp .env.example .env

The required entry is a Google AI Studio key, used for vision plus image and video generation and for voice when GEMINI_VOICE_API_KEY is unset. The template points to ai.google.dev to get one.

GEMINI_API_KEY=your-gemini-key
PORT=9900

PORT is the voice agent WebSocket port and defaults to 9900. The template notes that this socket binds loopback only, so another device cannot reach it directly; calling the agent from another machine requires opting into the Tier 2b settings described there, over the same Wi-Fi or your tailnet.

Dependencies are managed with pnpm at the workspace level, and package.json exposes the scripts. The start script runs the TypeScript voice agent.

pnpm install
npm run start

Once the process is up, the first useful task is the one the README leads with: put a paragraph on screen, say "make this paragraph shorter", and watch whether the rewrite lands in the original document. If that works, the same inline-tool path is what handles screenshots and quick edits. Anything larger should end up in tasks/ for the next proactive loop rather than blocking the voice session.

Alpha status, three external services, and the quota cliff

The README does not hide the state of the project. It labels it alpha and gives a table: 30 capabilities verified working, and 3 that need external setup, namely Twilio for phone, a Telegram bot, and a Discord bot. It also asks for contributors to help test and harden those capabilities and says to open an issue when something breaks. Take that at face value. Thirty verified capabilities is a lot of surface area for an early-stage project, and the README itself does not claim they are hardened.

The quota backoff is the limitation I would think about hardest. Backing the loop off from 15 to 30 minutes at 80% of a 7-day Claude quota means that on a busy week your agent silently does less. Nothing in the README describes what happens at 100%. If your work depends on the proactive loop running on schedule, this is a soft ceiling you do not control.

The wrong tool cases are clear enough. If you need a documented, versioned API with a deprecation policy, this is not it: the package.json version is 0.1.0 while the releases are at v0.12.0, and there is a CHANGELOG-PENDING.md sitting next to CHANGELOG.md. If you cannot leave a Mac running, the cron-driven loop and the 24/7 phone handling on a second machine have nothing to run on. If you are not comfortable with a process that writes its own code, SUTANDO_SELF_DEVELOPMENT_ENABLED=0 disables that while keeping owner tasks, health checks, and task delivery, but you lose the feature the project is named around.

Sutando against a plain Claude Code or Codex CLI session

The honest alternative is the thing Sutando wraps: a Claude Code or Codex CLI session you drive yourself from a terminal. That setup gives you the same model access, the same file editing, and a mature permission model, with no daemon, no cron entry, and no voice stack. What it does not give you is presence. You have to be at the keyboard to start a task, and there is no path from a phone call to a file edit.

The difference in approach is where the state lives. A CLI session is stateless between invocations unless you build memory yourself. Sutando keeps a workspace: tasks/ as the queue, crons.json per host as the schedule, skills/ and packages/ as the extension points, and a set of adapters that translate each channel into the same core agent. That shared memory across voice, Telegram, Discord, email, and web is the actual product. The cost is that you are now operating a service, with a port, a set of credentials, and a loop that runs whether or not you are watching.

A second alternative is a hosted assistant with a Mac client. Those remove the setup burden and the quota backoff, and they remove ownership at the same time. The README's closing line on this is blunt: it belongs entirely to you. Whether that is worth running your own cron job is the decision, and it is a decision about operations, not about model quality.

Licence, telemetry, and what upgrades cost you

Sutando is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is permissive enough that the licence is unlikely to be your blocker. Two other files deserve a look before you deploy: TELEMETRY.md, which the repository ships at the top level, and SECURITY.md. The README does not describe what TELEMETRY.md covers, so read it rather than assuming.

Upgrade cost is the real maintenance line item. The releases are frequent and thematically chunky: v0.10.0 added multi-gateway rooms, workstream isolation, self-diagnosis, and safe restarts; v0.11.0 added a collaborator tier with AG2 Space; v0.12.0 added durable delivery and task integrity stamps. Those names suggest that delivery semantics and isolation were still being defined as of v0.12.0. The last push to the repository was on 2026-09-15, so the code is moving.

There is also a contributor licence agreement in CLA.md. If you only run the software, it does not affect you. If you plan to send patches, read it first. And note that the repository carries both a generic AGENTS.md and a PERSONAL_CLAUDE.md.example, which is where the agent's instructions about your workspace live. Those files are part of your security boundary, not just configuration.

Editorial conclusion

Adopt Sutando if you own a Mac you can leave running, you already drive Claude Code or Codex CLI from a terminal, and you want voice and screen control that never leaves your machine. Do not adopt it if you need a documented stable API, if you cannot dedicate a host to a cron job that fires every 15 minutes, or if you are unwilling to hand a process the ability to write its own code. Before installing, read AGENTS.md and PERSONAL_CLAUDE.md.example to see what the agent is told about your workspace, decide whether SUTANDO_SELF_DEVELOPMENT_ENABLED=0 is the right default for you, and check KNOWN_ISSUES.md against the capabilities you actually plan to use.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sonichi/sutando on GitHub