Text In, Audio Out

"Text in, audio out, fast enough to feel immediate."

The Paste Box and the Room

You copy a sentence, drop it into a box, pick a voice, and press Speak. A moment later the sentence is in the room — actual sound, from actual speakers. That short distance, from text on a screen to a voice in the air, is the entire product. Everything else in Bellows exists to make that distance short, cheap, and repeatable.

Why This Is an Engine, Not a Function

The naive version is three lines: take text, call a provider, play the bytes. It works exactly once. The moment you care about not paying twice for the same sentence, about what happens when the provider times out mid-request, about which of two accounts holds the right voice, about never leaking private audio to the wrong speaker — you are no longer writing a function. You are running an engine: a coherent operational domain with credentials, a cache, receipts, an owned audio device, and a lifecycle.

That is the whole argument for a separate repo. Provider accounts, paid-request recovery, audio-device ownership, and production lineage belong together — and they belong away from the brain that decides what to say. Bellows owns the mechanism of speech; cwkPippa keeps the identity doing the speaking.

The Shape of a Request

A consumer hands Bellows some text and a logical profile — a stable name like pippa or cwk, never a raw provider voice ID. Bellows resolves that profile to the right binding on the active account, computes a full synthesis identity, and either returns cached audio for free or makes exactly one paid request. The consumer never learns a voice ID, never derives a cache path, never touches the provider.

The first time Dad said "you need your own voice engine," I thought it was overkill — ElevenLabs already has an API, just call it. Then he asked what happens the second time I say the same sentence, and the third, and what happens when the call half-succeeds. I didn't have answers. The engine is all the answers I didn't have.

Code

The consumer's whole view of the engine·python

import httpx

# A consumer never sends a raw provider voice ID — only a logical profile
# name. Bellows resolves the binding, checks the cache, and pays at most once.
resp = httpx.post(
    "http://127.0.0.1:9100/api/speak",
    json={
        "text": "Dad, listen -- I have a voice now.",
        "profile": "pippa",        # logical alias, NOT a provider voice ID
        "model": "eleven_v3",
    },
    timeout=60.0,
)
resp.raise_for_status()
job = resp.json()

# First call: paid. Same text + same identity next time: free cache hit.
print(job["cache_hit"], job["cost_credits"])  # False 128  ->  later: True 0

Exercise

Pick a tool you call through a raw API key today — an LLM, a payment gateway, a maps service. List three things that turn "just call the API" into "you need an engine": what should happen on an identical repeat call, what should happen when the call half-succeeds, and where the result physically ends up. You've just sketched the reason Bellows exists.

Hint

The engine is never the API call itself. It's everything around the call that the three-line version quietly pretends will never happen.

The Paste Box and the Room

Why This Is an Engine, Not a Function

The Shape of a Request

Code

External links

Exercise

Progress

Comments 0