From AssemblyAI to Orchard in 60 seconds: a migration walkthrough

AssemblyAI is well-engineered, well-documented and well-priced — for the segment of the market that doesn't process audio at scale. Past a few million minutes a month, the bill stops being a line item and starts being a strategic conversation. The good news is that the migration off it is one of the smaller engineering projects you'll run this quarter.

The cost delta, at common volumes

AssemblyAI Universal with speaker labels prices at $0.0117/min batch and $0.0150/min real-time. Run a 5M-minute workload through it and the bill lands at $58,500/month batch or $75,000/month real-time. On Orchard the same workload costs $2,100/month on either tier — a ~96% reduction at production volume.

The mechanical swap

The migration has three parts: change the client initialization, rename a handful of response fields, and run the verification harness. Total engineering time on a normal codebase: under an hour.

1. Drop the AssemblyAI SDK and install the OpenAI SDK. Orchard is wire-compatible with the OpenAI Whisper API, so the official OpenAI Python or Node client is the cleanest path. If your code already imports openai for other reasons, this step is free.
2. Replace the client construction. Where your code reads aai.Transcriber() (Python) or new AssemblyAI(...) (Node), construct an OpenAI client pointed at Orchard's base URL instead: OpenAI(api_key=ORCHARD_API_KEY, base_url="https://api.orchardrun.com/v1").
3. Replace the transcribe call. Where your code reads transcriber.transcribe(audio_url), call client.audio.transcriptions.create(file=audio_file, model="whisper-large", response_format="verbose_json") instead.
4. Rename the response fields downstream. AssemblyAI returns text, utterances and words. The OpenAI/Orchard verbose JSON returns text, segments and (with diarization enabled) speakers. Most parsers need a 10-line shim; the response objects are structurally equivalent.
5. Run the verification harness. Pull 1,000 calls of recent production audio, hit both endpoints in parallel for 48 hours, diff the output. The diff should sit below the noise floor of your existing accuracy tests.

The field map, side by side

• AssemblyAI text → Orchard text. Identical semantics.
• AssemblyAI utterances[] → Orchard segments[] with speaker_id attached. Field names differ, payload identical: start/end timestamps in seconds, text, speaker label.
• AssemblyAI words[] → Orchard segments[].words[]. Per-word timestamps live inside the segment for cleaner serialization; flatten if your parser expects the top-level array.
• AssemblyAI audio_duration → Orchard duration. Same units (seconds).
• AssemblyAI language_code → Orchard language. ISO 639-1, identical values.

The migration is a configuration change and a response rename. The hard part is the spreadsheet that justifies it, not the code that ships it.

What you keep when you swap

• Speaker diarization — bundled, no separate API call required.
• Multilingual support — 60+ languages with stronger fidelity on regional accents most generic endpoints flatten.
• Word-level timestamps — same precision, same shape (nested under segments).
• Language detection — automatic on every request with no extra parameter.
• Verbose JSON — full response structure with segments, speakers, language, duration in a single API call.

When to stay on AssemblyAI

Two cases where the migration math doesn't hold:

• You're under ~100K min/month. The dollar saving doesn't justify the engineering attention this quarter.
• You're deeply wired into a specific AssemblyAI intelligence feature — Auto Chapters, Content Moderation, Entity Detection — and the downstream product depends on the exact heuristic of that feature. Re-implement on Orchard when the downstream owner has bandwidth.

Outside those two cases: the migration is the easiest line on your roadmap this quarter, and the math has paid for it before the second Orchard invoice arrives.