Voice is the first medium the web never learned to save

September 13, 2026 · ThreadGrab

OpenAI shipped GPT-Live 1 into the API, and the interesting part is not the model. It is the billing unit. Voice sessions cost $0.05 per minute, metered per second, and anything the voice model delegates - reasoning, tool calls, the model that actually composes the answer - is billed separately. For the first time, a company can buy a conversation and pay for it the way you pay for a phone call.

Which raises a question the docs do not answer. When the session ends, what do you have?

A post is a document. It has a permalink, a visible timestamp, and a copy that survives an HTTP fetch. You can archive it a year late and still get the same bytes. A voice session is the opposite: it exists while a socket is open, and the moment it closes, the record either exists in something you wrote or it does not exist at all. There is no going back to fetch yesterday's call.

That asymmetry is what this article is about. I archive public posts for a living, and the arrival of a metered, full-duplex voice API breaks a comfortable assumption I had been making for years - that any content worth keeping would still be there tomorrow to collect.

What GPT-Live 1 actually is, in the docs' own terms

The model card is unusually plain. GPT-Live 1 is described as a full-duplex voice model that "can listen and speak at the same time, and delegate reasoning and tool use to a backend agent." Full duplex is the load-bearing phrase. This is not speech-to-text feeding a language model feeding text-to-speech, three steps in a queue. It is one model handling a conversation where interruption is normal and both directions are live.

Two details in that table matter more than they look. First, "billed separately" for backend usage means the per-minute price is a floor. A voice session that thinks hard is a voice session plus a text model bill plus whatever the tools cost. Second, rate limits are measured in concurrent sessions rather than requests per minute, which is the correct unit for something that occupies a socket for the duration of a conversation - and it is also a hint about what kind of object a session is.

Between the audio and text modalities there is a distinction worth naming, because it decides your architecture. Audio is both an input and an output, and the same platform exposes the transcription endpoints separately. A transcription session is one-way: audio in, text out, built to describe speech. A live session is two-way and built to converse. If all you want is a searchable record of what was said, the transcription path gets you text with far less machinery. If you want a voice agent, you are building the record yourself on top of it.

The three things a voice session leaves behind

Ask what survives a closed socket and the answer is smaller than people assume. There are exactly three categories of artifact, and only one of them is created by you.

The streamed transcript, if your client kept it

Live voice APIs emit events as the conversation runs - partial and final transcripts, turn boundaries, function-call payloads. Those events arrive at your client, which means your client can write them down. This is the highest-value artifact and the easiest to lose: if you only forward the events to a UI and never persist them, the transcript is a rendering, not a record. Persisting it is a two-line change to your event handler and a permanent change to what your archive can answer later.

The audio, if you asked for it

Audio is input and output on this model, so both directions can be captured. Keep in mind this cuts both ways: an audio file is the highest-fidelity record and the least usable one. You cannot grep it, you cannot diff it, and it costs storage proportional to the conversation rather than to what was said. In practice audio is the evidence and text is the index, and the honest archive keeps both rather than pretending one of them is sufficient.

The session metadata, which nobody captures and everybody needs

This is the category that gets skipped, and it is the one that decides whether the archive is interpretable in eighteen months. A transcript with no session id cannot be matched to a billing line. A transcript with no model id cannot be explained when the voice changes. A transcript with no endpoint recorded cannot be reproduced when the API surface moves. None of these fields are hard to write; all of them are impossible to reconstruct after the fact.

Capturing a live session: what to write down

The collection step has to run while the socket is open, so the right place for it is inside whatever process already handles the events. Here is the shape I use - a minimal event handler that writes a durable text record as the conversation runs, with the metadata that makes it interpretable later:

# Persist a GPT-Live 1 session as a durable text record.
# Run this inside the process that already handles the stream events.
import json, pathlib, datetime

SESSION_ID = "sess_abc123"          # from v1/live/sessions
MODEL_ID = "gpt-live-1"
ENDPOINT = "v1/live/sessions"
OUT = pathlib.Path("voice-archive") / SESSION_ID
OUT.mkdir(parents=True, exist_ok=True)

def utc_now():
    return datetime.datetime.now(datetime.timezone.utc).isoformat(timespec="seconds")

transcript = OUT / "transcript.jsonl"

# One JSON object per event, appended as it arrives. JSONL is the right
# container: it is line-greppable, append-only, and survives a crash
# mid-session without losing the turns that already landed.
def on_event(evt):
    row = {
        "captured_at": utc_now(),
        "session_id": SESSION_ID,
        "model": MODEL_ID,
        "type": evt["type"],                  # speech_started / transcript / response
        "role": evt.get("role"),              # "user" or "assistant"
        "text": evt.get("text"),
        "turn": evt.get("turn"),
    }
    with transcript.open("a", encoding="utf-8") as fh:
        fh.write(json.dumps(row, ensure_ascii=False) + "\n")

JSONL rather than a single JSON document, and the reason is worth stating: a conversation is an append-only sequence, and an append-only container means a crash at minute nine still leaves you nine minutes of transcript. Convert it to a single object at the end if you want, but do not make the file's validity depend on the session ending cleanly.

The second half is the metadata file. It is small, it is boring, and it is what turns a pile of text into an archive:

# Write the metadata alongside the transcript, once, at session close.
cat > voice-archive/$SESSION_ID/session.provenance.txt <<EOF
session_id: ${SESSION_ID}
model: gpt-live-1
endpoint: v1/live/sessions
started_at: $(date -u +%Y-%m-%dT%H:%M:%SZ)
billed_unit: 0.05 USD per minute, metered per second
backend_calls: separate billing, model recorded per call
consent: announced at session start, flag stored alongside transcript
retention: audio 90 days, transcript and metadata indefinite
note: transcript is the index, audio is the evidence
EOF

The note line at the bottom is not decoration. Whoever opens this folder in two years needs to understand within five seconds which file they should trust for a quote and which one they should trust for tone. That is a design decision, and the only place it can live is in the archive itself.

The consent question, handled as an engineering problem

Recording law is jurisdictional and I am not going to pretend this is legal advice. But the engineering shape is stable across the jurisdictions I know of: when a human is on one side of the recording, the rules attach to that human, and several places require every party to agree. A metered voice API makes this more common, not less - the whole pitch is that buying a conversation is now cheap and easy.

So treat it the way you would treat any other compliance flag: make it loud and make it data. Announce at session start rather than burying it in terms. Store the consent state as a field next to the transcript, not as an assumption in someone's memory. Write the retention window into the metadata so a future deletion request is a lookup rather than an archaeology project. The failure mode to avoid is the ordinary one - a recording that exists, that nobody can explain the provenance of, that nobody is sure is legal to keep.

Why the model version is the least durable part

Here is the thing about building an archive on top of gpt-live-1: it is a snapshot name. Snapshots get deprecated. Endpoints get superseded - this model is already reachable through Live, Chat Completions, Responses and Realtime, which tells you the surface is still moving. Pricing tiers get restructured, and the concurrent-session limits that look generous at Tier 5 are a policy that can change without your archive noticing.

None of that is a reason not to build. It is a reason to build so the model is the replaceable part. Keep the audio. Keep a text transcript. Keep a small file that names the model id, the endpoint, and the date. If the meaning of your archive depends on which voice answered, record that as a field the same way you record which account posted a thread - because the platform changing underneath a saved artifact is the failure mode I write about every week, and voice has no equivalent of a permalink to fall back on.

This is the same instinct as archiving a thread rather than bookmarking a link. The bookmark proves the thing existed and still resolves to something. The copy proves what it said. Voice is the case where that distinction stops being a preference, because the something it resolves to next week might be a different voice, a different model, or nothing.

The stack, end to end

1. Announce - state at session start that the conversation is recorded, and store the consent flag next to the transcript.
2. Capture live - persist transcript events and audio as they pass through your client. This is the only step that cannot be run late.
3. Stamp - write session id, model id, endpoint, and a UTC timestamp into a metadata file at session close.
4. Separate evidence from index - audio for tone and proof, text for search and quoting, and a note in the metadata saying which is which.
5. Re-verify before citing - when quoting a call from months ago, read the transcript, check the model field, and do not assume the current API behaves like the one that produced it.

Where ThreadGrab fits

ThreadGrab captures public X, Bluesky and LinkedIn content into Markdown with timestamps and the source URL, so what you saved keeps the identity it had when you saved it. It does not record calls and it does not touch audio - the voice pipeline above is a script you run yourself, against a socket you already own.

What the two have in common is the rule, and the rule does not care about the medium: the copy you control, stamped with when you took it, is the only version that still means what it meant. A post has a permalink that slowly becomes a lie. A voice session never had one to begin with. Both are solved the same way, and only one of them gives you a second chance to solve it.

FAQ

Last verified: September 13, 2026. Primary source: the OpenAI model card for GPT-Live 1 at platform.openai.com/docs/models/gpt-live-1, which is the basis for the $0.05 per minute billing unit, the per-second metering, the separate backend billing, the text/audio modalities, the unsupported features list, the endpoint list, the July 31, 2025 knowledge cutoff, and the concurrent-session rate-limit tiers. The openai.com announcement page returned HTTP 403 to every automated fetch and was not used. The audio-capture design, the JSONL schema, and the metadata template are the author's own and are not vendor guidance. Recording law varies by jurisdiction; consent requirements should be checked against local rules and this article is not legal advice.