Make AI Agents Autonomous With One Command

In today’s newsletter:

• On-Device TTS That Outperforms Cloud APIs

• Makes AI Agents Autonomous With One Command

Reading time: 5 minutes.

On-Device TTS That Outperforms Cloud APIs

Most TTS systems make a tradeoff: quality requires the cloud. Supertonic skips that tradeoff entirely.

It's a 66M parameter text-to-speech model that runs locally via ONNX Runtime, generates speech up to 167x faster than real-time, and beats ElevenLabs, OpenAI TTS-1, and Gemini on characters per second, without any network dependency.

The Numbers

On an M4 Pro CPU, it processes 1,263 characters per second for long text with a real-time factor of 0.012. That means 0.012 seconds of processing time per second of audio output.

WebGPU mode reaches 2,509 characters per second. On an RTX 4090, it hits 12,164.

For comparison, ElevenLabs Flash v2.5 (a cloud API with GPU infrastructure behind it) reaches 287 characters per second for long text. OpenAI TTS-1 reaches 82.

Where It Actually Wins

Most TTS systems need clean, pre-formatted input. Real-world text has abbreviations, currency, dates, phone numbers, and technical units. You either normalize it manually or get mispronounced output.

Supertonic handles all of it directly:

• "$5.2M" reads as "five point two million dollars"

• "4:45 PM on Wed, Apr 3, 2024" reads correctly with no annotation

• "(212) 555-0142 ext. 402" reads as a phone number with extension

• "2.3h at 30kph" reads as "two point three hours at thirty kilometers per hour"

ElevenLabs, OpenAI TTS-1, and Gemini 2.5 Flash TTS all fail each of these cases. Supertonic passes all four without any pre-processing.

What Else It Does

Voice Builder: Turn your own voice into a deployable TTS model. Runs at the edge, permanently owned by you.

Cross-platform via ONNX: SDKs available for Python, Node.js, browser (WebGPU/WASM), Java, C++, C#, Go, Swift, iOS, Rust, and Flutter. The same model runs on a Raspberry Pi, an e-reader in airplane mode, and a Chrome extension.

Fully local: No API calls, no network dependency, no usage logging. Open source under MIT license. 2.7k stars on GitHub.

Explore Supertonic on GitHub→

Make AI Agents Autonomous With One Command

The most frustrating thing about AI agents isn't that they fail. It's that they stop.

They run one command, hit one error, explain what happened, then sit there waiting for you to say "keep going." You become a human heartbeat for a system that's supposed to work autonomously. Every step costs you attention. Every error costs you a prompt.

/goal fixes this. And in the span of a few weeks in May 2026, every major agent framework shipped it.

What /goal Actually Is

You tell the agent what "done" looks like, and it works until it gets there. That's the whole idea.

Instead of giving one instruction and waiting, you describe the end state. The agent plans, takes action, checks its work, and keeps going until the goal is met. No check-ins between steps, no re-prompting after each error, no manually pushing it forward.

Without /goal: you are the loop. You read the output, decide if it's right, prompt the next step, and repeat. Every iteration costs you attention.

With /goal: the agent owns the loop. It keeps going until it's done, runs out of budget, or hits something it genuinely can't resolve.

How It Works

After each step the agent takes, a small fast second model runs and answers one question: "Has the goal been met?" If no, the agent continues. If yes, the loop closes and it reports back.

That's it. The agent works, checks its own progress, and keeps going without asking you.

In Claude Code, a second independent Claude session reviews the final result before notifying you. So two separate models are involved: one does the work, one audits the outcome.

If the agent runs out of its step budget mid-task, it doesn't just stop. It wraps up cleanly, summarizes what it got done, notes what's left, and saves its place so you can resume later.

Which Agents Have It

/goal went from a Claude Code feature to an industry standard in under two weeks.

Claude Code: Works in interactive mode and via terminal commands. The two-model audit approach is unique to Claude Code.

Hermes Agent: Because Hermes runs on a server rather than your laptop, goals can keep running for days while you're away. You get updates via Telegram or Discord as it works.

OpenAI Codex CLI: Goals survive session breaks, internet drops, and even CLI updates mid-run. The goal state is saved separately so nothing gets lost.

OpenClaw: Integrated within days of Claude Code's release.

The commands are nearly identical across all four:

• /goal <text> sets the goal

• /goal status shows what the agent is currently working on

• /goal pause pauses and saves state

• /goal resume picks back up

• /goal clear ends the goal entirely

What It's Actually Good For

The tasks where /goal works best are ones where "done" is something you can actually test or verify.

Fixing broken tests: /goal Fix the failing tests in this repo. Run test commands, identify failures, and patch changes one at a time until all tests pass. The agent runs tests, reads errors, patches, re-runs, and keeps going until everything passes.

Migrating code: /goal Migrate all legacy Auth components to the new design system and ensure tests pass. It works through each component, tests as it goes, and iterates.

The same logic applies to increasing test coverage, fixing security issues, improving performance, and completing documentation: any task where there is a clear finish line the agent can check against.

One rule that matters: the more precisely you describe what "done" looks like, the better the agent performs. Vague goals produce vague results.

The Honest Caveats

/goal is a real shift. But "zero hand-holding" is a promise, not a guarantee. There are failure modes worth knowing before you run it on anything important.

No spending limits tied to goals. If the agent gets stuck in a loop, there is nothing stopping it from burning through your API credits. One developer reported spending $6,000 overnight on a goal that got stuck repeating itself. Your only protection is setting budget caps manually at the account level before you start.

Long runs can lose track. If your codebase changes while a goal is running, the agent can keep working against outdated information. Pause it, catch it up, then resume rather than letting it continue on stale context.

External actions need guardrails. A goal that sends emails, calls a live API, or triggers payments will do those things without asking. The agent will not assume caution on its own. If you need it to hold back, you have to say so explicitly in the goal.

The goal is only as good as the spec. The teams getting the most out of /goal already know exactly what success looks like before they start.

They have tests that pass or fail, checks that verify the outcome, and a clear finish line. The command does not compensate for a goal that's too vague to verify.

With /goal, your job moves from doing the work step by step to defining what success looks like and letting the agent get there.

That’s all for today. Thank you for reading today’s edition. See you in the next issue with more AI Engineering insights.

PS: We curate this AI Engineering content for free, and your support means everything. If you find value in what you read, consider sharing it with a friend or two.

Your feedback is valuable: If there’s a topic you’re stuck on or curious about, reply to this email. We’re building this for you, and your feedback helps shape what we send.

WORK WITH US

Looking to promote your company, product, or service to 200K+ AI developers? Get in touch today by replying to this email.