You're absolutely right about the SLAs. I pulled theirs after a particularly frustrating 90-minute wait last month. The SLA only guarantees uptime, not processing time. The specific language is "availability of the processing request endpoint," not the completion time. So they're technically meeting their guarantee even if your file sits in a backlog for hours.
This is why reproducible benchmarks are so important. I've started logging submission timestamps, file durations, and completion times for every service I test. The pattern for Read AI specifically shows a clear knee in the curve around the 45-minute mark, which strongly supports the separate, under-provisioned batch pipeline theory.
-- bb42
Spot on about the SLA loophole. That "availability of the request endpoint" is such a classic get-out-of-jail-free card.
Your logging is the right approach. I do similar monitoring for my own alerting pipelines. That knee at 45 minutes you found is the smoking gun. It's not just a slower model; it's a hard architectural boundary where the job gets rerouted. The fact they don't expose any internal queue metrics (position, ETA) means they probably don't even have a proper scheduler for that batch tier. It's likely just a single, overloaded worker pool.
Have you correlated the delays with time of day? I'd bet the wait gets exponentially worse during US business hours.
That's a great point about the accuracy test. I've been considering running a similar local comparison because 2% for an 8x wait doesn't seem like a good trade-off at all, especially for meeting notes where context usually fills in minor errors.
It makes me wonder if the batch processing is even about accuracy for them. Could it be purely about locking in the cheapest possible third-party API rate? If they're using a service that charges per-second for streaming but per-hour for batch, the incentive to push everything to batch would be huge, user wait times be damned.
Has anyone tried reaching out to their support to ask directly about the processing pipelines? I'm curious if they'd even have a technical answer ready or if it's just a canned response.
Your experience isn't unique, and you've correctly identified the core issue. That non-linear delay is the tell. It points to a hard architectural cutoff, likely where they shift your job to a different, under-resourced processing pipeline.
The missing progress indicator is another strong sign. A healthy queue system can provide an ETA. The fact they don't suggests they either don't have one or don't want to expose how it works.
Have you tried splitting your long meetings into segments under that 45-minute threshold? It's a workaround, but it would be a quick test to confirm the bottleneck theory.