Sutando puts a cron job and a Claude Code session behind a voice agent

The core agent fires /proactive-loop every 15 minutes

Sutando's engine is not a chat loop. It is a per-host cron entry that runs the `/proactive-loop` command every fifteen minutes, written as `*/15 * * * *` in a file called `crons.json`. Each pass does three things: it runs health checks, it picks the next build-log item, and it keeps a persistent watcher on the `tasks/` directory through Claude Code's `Monitor` tool. That watcher is why a task you dictate on a walk gets handled on arrival instead of waiting for the next tick.

Claude gets a throttle the project calls a backoff. When seven-day quota utilization reaches 80 percent, the cadence drops to every thirty minutes and stays there until an authoritative routed reading comes back under the threshold. Four telemetry states hold the slower cadence on purpose: missing, stale, rejected, and unrouted. The loop is supposed to report why it is holding, so a silent slowdown should not happen without a reason attached to it.

The same loop runs when you are not talking to it. Sutando describes an autonomous build cycle that monitors its own health, detects patterns in how you work, discovers skills, builds capabilities that are missing, and learns from corrections. The claim attached to that cycle is blunt: most of Sutando's code was written this way. Put it next to the `/proactive-loop` schedule and the design reads in one line. The agent is its own runtime's night shift, spending a quota you already hold.

Four processes, three ports, and one service kept off the data path

Four long-running processes make up the runtime, and each has a fixed port or a fixed launchd label. The voice agent runs Gemini Live over a WebSocket on port 9900 and handles real time conversation in the browser. The conversation server runs the same Gemini Live role for phone calls, on a Twilio WebSocket on port 3100. Between them sits the web client, a separate launchd service named `com.sutando.web-client.plist` that serves the browser UI over HTTP on port 8080.

The web client's placement is the interesting part. The README states that the browser connects straight to the voice agent's WebSocket on 9900, and that the web client is not in the WebSocket data path. A UI change on 8080 therefore does not sit between you and the model, and it is not a place where voice traffic could be inspected or slowed.

The fourth process is the core agent, and here the README stops mid-sentence. It reaches "Core agent (Claude Code" and the page ends, without a closing parenthesis and without saying how that process is supervised. Nothing in this article fills that gap. The project points elsewhere for the parts an operator needs: `docs/architecture-boundaries.md` holds the normative definitions of core, adapters, apps, skills, tooling, and workspace state. Anyone wiring a second machine or an unfamiliar channel will end up in that file, because the README defers to it.

Note what is absent. No container, no systemd unit, no Dockerfile in the top-level tree. Services are launchd plists, a cron entry and a `start.sh`, which places this in the category of software that expects a Mac to stay awake.

GEMINI_API_KEY is the only key Sutando refuses to boot without

`.env.example` splits configuration into four bands and only the first is mandatory. At the top sits `GEMINI_API_KEY`, the Google AI Studio key covering vision plus image and video generation, and also voice whenever the separate voice key is unset. The file is blunt about the consequence: Sutando will not start without it. Getting one is a signup at `https://ai.google.dev`.

The second key is a cost control, not a capability switch. `GEMINI_VOICE_API_KEY` covers the voice session, which spans Gemini Live, speech to text, and the text model behind subagents. The comment claims voice on the free tier is unlimited, rate-limited but not metered, so pointing voice at a free-tier key keeps a billing-enabled project for image and video from absorbing the voice bill. Left unset, voice falls back to `GEMINI_API_KEY`.

Two more settings complete the documented surface: `NOTIFICATION_EMAIL` for health alerts, and `PORT` for the voice agent's WebSocket, which the file gives a default of 9900. Pin that same value in your own environment file and the ports in the architecture section still line up.

GEMINI_API_KEY=your-gemini-key
# GEMINI_VOICE_API_KEY=your-free-tier-voice-key
# [email protected]
PORT=9900

The rest of that file describes reaching the agent from a second device as Tier 2b, over the same Wi-Fi network or your tailnet, and it stops mid-sentence at "These opt you into a". The detail behind it matters: the voice WebSocket binds loopback only, so a phone cannot simply open port 9900 from the street.

Self-development is on by default, and a bad value turns it off

The default is the part worth arguing with. `.env.example` says autonomous self-development is ON by default, and that product deployments can turn it off while keeping owner tasks, health checks, and task delivery active. The switch is `SUTANDO_SELF_DEVELOPMENT_ENABLED`, set to 0 to stop it. Two details are spelled out for anyone flipping it: invalid values fail closed, so a typo leaves self-development disabled rather than enabled, and the core has to be restarted after the change, meaning that editing the file does nothing to a running agent.

Everything else rides on a session you already hold. The claim that no pay-per-token core API key is required works because Sutando runs through the Claude Code or Codex CLI session you select, with optional service credentials only for the capabilities you enable. Read that precisely. The agent is not cheaper because the tokens are free; it is cheaper because it spends a subscription you own.

The release notes show the project treating delivery as the hard part. v0.12.0, tagged 2026-08-20, is titled "durable delivery, task integrity stamps". A self-writing agent whose own task queue can drop work quietly needs that kind of receipt, and it arriving at v0.12 rather than v0.1 says the queue was the weak link. Two releases earlier, v0.10.0 from 2026-08-12, already carried self-diagnosis and safe restarts, which is what you would expect a long-running cron agent to need before anyone lets it modify itself.

Twilio, Telegram and Discord are the three capabilities the repo does not cover

The project grades itself, and the grade is on the page. Under "Status: Alpha" a two-row table separates thirty capabilities marked verified working from three marked as needing external setup: Twilio for phone, the Telegram bot, and the Discord bot. Everything else, voice and screen capture, notes, calendar, reminders, contacts, browser, phone calls, meeting dial-in, task delegation, pattern detection, health check, dashboard, multi-machine migration and an onboarding tutorial, sits in the first row.

That split is the honest cost of the phone and messaging features. Sutando dials numbers, joins calls and sends itself approval requests, and each of those needs an account you hold with a third party. The approval gate is a design decision rather than a convenience: before task delegation is enabled, Sutando messages you on Telegram to ask. The Telegram bot credential is not optional decoration for the meeting feature, it is the lock on it.

The multi-machine story leans on the same two services. Plug in a second Mac and the README says the original agent opens a Discord channel, sends setup commands and migrates services, so the new machine can take phone calls around the clock while the laptop stays portable. No migration scripts, the two agents coordinate the handoff themselves. The cost is that the handoff channel is Discord and the phone leg is Twilio, both outside the MIT licensed tree. The code is MIT; the reach is not.

Eight channels, one memory, and the alternative of driving the CLI yourself

The channel list is long: voice, Zoom, Google Meet, Telegram, Discord text and voice, web, phone, and email, all pointed at the same agent and the same memory. The phone path has its own entry command. Call the agent, say "summon", and it opens Zoom with screen sharing, so you can watch its screen from the handset while it scrolls, switches apps and works through what you dictate. A demo linked from the README counts a session of that shape as 24 tool calls, 6 tasks and 7 minutes.

Calls have the sharpest edges. Sutando will look up a contact, dial, hold the conversation and report back, and it says it can run concurrent calls while it is already in a meeting. During meetings it takes screenshots to identify participants, does live research when somebody asks a question, and writes the summary when the call ends. Screenshots of a meeting, handled by an agent that also edits the document you are reading, is a wide surface with no permission model described beyond the Telegram approval gate.

The obvious alternative is to skip Sutando and use the Claude Code or Codex CLI directly, which the README names as the underlying core. The difference is not model quality, it is who supplies the loop. A CLI session is something you start, prompt and watch. Sutando supplies the schedule, the persistent watcher on `tasks/`, the voice channel, the phone leg and the note store, and in exchange it runs a cron job that can write to its own repository while you sleep. Take the CLI if you want to stay in the driver's seat. Take Sutando if you want the agent reachable when you are not at the keyboard.

The README ends mid-sentence, and the repo keeps its own scorecards

Two things to know before trusting the page. First, it ends abruptly. The list of four processes stops at "Core agent (Claude Code", mid-sentence, with no closing parenthesis and no account of how that process is supervised. Second, the repository carries review apparatus the README never mentions: `KNOWN_ISSUES.md`, `REVIEW.md`, `CHANGELOG-PENDING.md`, `TELEMETRY.md` and `SECURITY.md` sit at the top level, next to `PERSONAL_CLAUDE.md.example`, `sutando.config.json` and `sutando.config.local.json.example`.

The layout reads as intent. `docs/` holds the architecture boundaries, `skills/` is a separate TypeScript project with its own `tsconfig.skills.json` and its own typecheck script, and `hooks/`, `schemas/`, `packages/`, `shared/` and `bin/` each own a slice of behaviour. `start.sh` is the entry point the README does not spell out, and `benchmarks/` sits beside `tests/`.

The version numbers disagree, which is a small thing that tells you something. `package.json` says version 0.1.0 while the tagged releases run v0.10.0, v0.11.0 and v0.12.0, so the manifest version is not a release marker worth quoting. The test script is more careful than the version field. The Python leg of `npm run test` refuses to report a count when discovery exits non-zero, refuses again when the file list fails to sort, and fails outright when zero test files turn up, on the stated grounds that a partial list must never be reported as a clean run.

The repository is not archived, and the last push landed on 2026-10-01.

Editorial conclusion

Sutando fits a Mac owner who wants one agent reachable by voice, phone and chat, with a Claude Code or Codex session doing the thinking, and who is willing to hand it credentials for Twilio and two chat platforms. It does not fit anyone who needs a documented install path, a headless deployment, or an agent that will not edit its own repository while idle. Before anything else, read docs/architecture-boundaries.md and the KNOWN_ISSUES.md sitting next to it, then set SUTANDO_SELF_DEVELOPMENT_ENABLED deliberately instead of inheriting the default.

Frequently asked questions

Official sources

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