notes from ElevenLabs TTS experiment

Start by locating the ElevenLabs TTS render path and the code that handles the response header, then trace how durable work and cleanup are currently represented. Done means retaining the history-item-id before returning audio, retrying delayed deletion, checking both history endpoints, alerting on terminal failure, and using separate read and write scopes.

Alert text is user data. Design for minimizing what ElevenLabs ever holds; deletion is cleanup, not prevention.

enable_logging=false does not work. Measured: a ZRM request returned HTTP
200 and a history-item-id header — it wrote a history entry exactly like the
logging-on request, with no eligibility error. ZRM is gated to eligible
Enterprise accounts; on a normal key the parameter is accepted and silently does
not apply. Never treat a 200 as proof of non-retention.

Deleting the history item does work, but not immediately. Measured at +3 ms
after the audio response completed:

• DELETE /v1/history/{id} → 404 history_item_not_found
• GET /v1/history/{id}/audio → 200, audio present

The audio is live and fetchable on their servers before the history record is
addressable for deletion. A 404 on DELETE means "not there yet", not "nothing
stored" — never infer deletion from it.

Therefore: a delayed delete queue, not an inline delete.

• Persist the history-item-id (response header) durably at render time,
  before returning audio to the user. It is the only handle; a crash between
  render and delete orphans data nothing can later remove.
• Delete after a delay, with backoff retries on the not-found case.
• Alert on terminal failures. A failed delete is silent and leaves live audio.
• The delay is unmeasured — a 0/250/750/2000/5000 ms ladder was written but never
  confirmed against the live API. Measure it and set the first attempt past the
  window; don't assume.

Verification must handle inconsistent error shapes. DELETE-missing is 404,
but GET /v1/history/{id} on a missing item is 400 with
detail.status: invalid_id (not 404). Check both the history item and its
/audio endpoint — in one run the audio outlived the record.

Keys need their own scopes for cleanup: speech_history_write to delete,
speech_history_read to verify. A TTS-only key gets 401 missing_permissions
and the cleanup silently no-ops. Provision this before launch.

Even a verified delete is weaker than ZRM. ElevenLabs states debugging and
moderation logs may retain related data, and backups may persist up to 30 days.
User-facing copy must say "deleted from history" — never "never stored."