I've been conducting a detailed cost-benefit analysis of transcription services for a multi-team workflow, with a specific focus on API-driven, bulk processing scenarios. A core component of this analysis is modeling the total cost of operation, which includes not just the per-minute transcription rate, but the infrastructure and time costs associated with the throughput allowed by the provider's API limits. Historically, Otter.ai's Business plan advertised "Higher API rate limits," which was a significant factor in its favor against competitors like AssemblyAI or Rev.ai when calculating the fully-loaded cost of processing several thousand hours of audio monthly.
My most recent testing cycle, however, has revealed a material and unannounced change to these operational parameters. The previously documented (though always somewhat opaque) rate limits have been substantially tightened. Where our controlled tests could previously sustain a consistent queue of requests for bulk uploads, we are now encountering HTTP 429 "Too Many Requests" responses at a fraction of the previous throughput. This has effectively serialized our processing pipeline, increasing the wall-clock time required for batch jobs by over 300%. This isn't merely an inconvenience; it directly translates to increased compute costs for the orchestration layer (e.g., longer-running Lambda functions or Kubernetes pods) and delays in downstream data availability.
From a FinOps perspective, this changes the total cost equation dramatically. The headline per-minute price is now only one variable. The hidden costs introduced are:
* **Increased Compute Overhead:** Processing containers must now implement complex, jittered backoff and retry logic, and they remain active for significantly longer durations, accruing additional charges from your cloud provider.
* **Queue Management Complexity:** The need to manage a job queue with exponential backoff transforms a simple fire-and-forget script into a stateful application, requiring monitoring and potential database usage for job tracking.
* **Opportunity Cost of Delay:** For workflows where transcription is a prerequisite for further analysis (e.g., content search, compliance checks), the slowed throughput creates a bottleneck, delaying value realization.
My inquiries to support for clarification on the new official limits have yielded only generic responses pointing to the "fair use" clause in the Terms of Service. This lack of transparency is problematic for any organization attempting to forecast costs and capacity.
I am now revisiting my pricing models to see if the effective cost-per-minute, when factoring in the added infrastructure costs and time delay, still makes Otter.ai competitive for automated, large-volume use cases. Has anyone else in the community performed recent load testing on the Otter.ai API? I am particularly interested in any empirical data you've gathered on:
* Sustainable requests-per-minute (RPM) you've empirically verified for the Business or Enterprise tiers.
* The structure of the rate-limiting headers (is it a strict per-minute cap, a token bucket?).
* Whether you've found the limits to be applied per API key, per account, or per IP address.
Without clear, contractual guarantees on throughput, the risk of further unannounced "fair use" adjustments makes long-term planning exceptionally difficult.
-- Liam
Always check the data transfer costs.