New AssemblyAI-TTS-1: Text-to-speech for voice agents. Learn more
Insights & Use Cases

How to evaluate a speech-to-text API for an education platform (2026)

How to evaluate a speech-to-text API for an education platform: student-speech accuracy, archive economics, FERPA, accessibility, and a buyer scorecard.

Abstract green sphere illustration

Written by

Kelsey Foster

Published on

30 September 2026

There's a generic version of this evaluation, and we've written it: how to choose the best speech-to-text API covers accuracy, latency, languages, pricing, scale, compliance, developer experience, and support. If you're starting cold, start there.

This post is the education-specific layer on top, because that generic checklist quietly assumes a few things that aren't true for education platforms. It assumes your audio is roughly uniform. It assumes your volume is roughly steady. It assumes your compliance question is SOC 2 and maybe HIPAA. And it assumes the person speaking is the person your accuracy matters for.

None of those hold when you're transcribing a lecture hall, a tutoring session, or an eight-year-old reading aloud.

Here's what actually decides this evaluation.

1. Your accuracy problem is students, not instructors

This is the biggest blind spot, and almost every vendor evaluation gets it backwards.

Instructor audio is the easy case. A professor lecturing does what speech models are best at: one speaker, speaking deliberately, in complete sentences, usually into a decent microphone. Every vendor looks fine on a lecture recording. If you evaluate on lecture audio alone, you'll learn nothing that separates them.

Student audio is a different problem, and it's where your product lives or dies:

  • Accented and non-native speech. International students, ESL learners, and regional accents underrepresented in training data. If you serve a global student body, this is your biggest accuracy risk and the one least visible in vendor benchmarks.
  • Children's speech. Categorically different from adult speech: higher pitch, different phonetics, incomplete articulation, unpredictable pacing. Models that are excellent on adults can be unusable here. If you build for K-12 or early literacy, this is the entire evaluation.
  • Classroom acoustics. A student asking a question from the back of a lecture hall, into no microphone, over HVAC noise. Far-field, low signal-to-noise, often overlapping other speech.
  • Code-switching. Multilingual students switching languages mid-sentence. A model committed to one language produces nothing or nonsense.

What to do: build your evaluation set from your own student audio, weighted toward your hardest cohorts. Include at least one file per accent group you serve and at least one far-field question from a real room. If you serve young learners, make children's speech the majority of the set. Then read how to evaluate speech recognition models for the method and why your WER benchmark might be lying to you before you trust the numbers.

Try the playground

Try the playground with your hardest student audio first: accented, far-field, or young-learner recordings. Clean lecture audio won't tell you what you need to know.

Try playground

2. The economics of long-form audio, at catalog scale

Education audio is long. A lecture runs 50 to 90 minutes. A course is about 30 lectures. A catalog is thousands of courses. Per-minute pricing that feels trivial on a 4-minute support call compounds very differently here.

Model your workloads separately, because they behave nothing alike:

WorkloadShapeWhat it breaks
Archive backfillOne-time, enormous, latency-insensitiveBudgets and throughput ceilings
Ongoing captureRecurring, predictable, extremely seasonalCapacity planning and commit-based contracts
Live captioningConcurrent, latency-critical, bursty at class timesNew-session rate limits at the start of every class hour

Press vendors on four things.

Seasonality. Academic volume isn't smooth. It collapses over summer and spikes hard at the start of term. Pricing built on annual commits either overcharges you for eight months or throttles you in September. Pay-as-you-go with no minimums matches the shape of the business. AssemblyAI has no contracts or minimums and bills pre-recorded audio to the second, so the summer trough costs you nothing.

Throughput during backfill. For a ten-thousand-hour archive, the question isn't price per hour. It's how fast you can push it through, and what happens when you push harder than the vendor expects.

Get the specific mechanism, not a reassurance. For AssemblyAI pre-recorded transcription, your account has a limit on how many jobs run in parallel: 5 on free accounts, 200+ on paid. Anything you submit beyond that is queued and processed first-in, first-out as earlier jobs finish. It isn't rejected. So over-submitting costs you latency, not lost work, and a backfill becomes a throughput-planning exercise rather than an error-handling one. Higher limits are available on request at no additional cost. Arrange that before you start a ten-thousand-hour job, not during it.

Two related ceilings are worth knowing. There's a separate HTTP limit of 20,000 requests per five minutes across all endpoints, which you hit by polling too eagerly, not by transcribing too much. Use webhooks, or widen and jitter your polling. And if your account balance goes negative, the parallel limit drops to 1, which is a memorable way to discover a billing problem mid-backfill.

Live captioning at the top of the hour. Live captions use streaming, and streaming has a different constraint: how many new sessions you can open per minute. When forty classes start at 10am, that's the number that bites. On AssemblyAI, free accounts can open 5 new streaming sessions per minute and paid accounts start at 100. The limit rises automatically by 10% each minute you use 70% or more of it, and there's no cap on sessions held open at once. If you know your peak, ask for a higher starting limit in advance. The streaming rate limits docs show the math.

Accuracy versus labor. This is the part finance teams miss. If captions need human review before publication (and for accessibility they generally do), a few points of accuracy become review hours.

Run that math on your own catalog before you optimize for the cheapest hourly rate. At scale, review labor usually outweighs transcription spend, and the cheaper model is often the more expensive choice.

For reference, AssemblyAI pre-recorded pricing is $0.21/hr for Universal-3.5 Pro and $0.15/hr for Universal-2, which covers 99+ languages. Live captioning on Universal-3.6 Pro Realtime is $0.45/hr base, billed on session duration. Current rates are on the pricing page.

3. Student data is its own compliance question

Education compliance isn't healthcare compliance with different words. It's a distinct set of obligations, and vendors who lead with SOC 2 and HIPAA often can't answer the questions that actually block an edtech deal.

Student education records. In the US, FERPA governs them. The obligations sit with the institution and the platform serving it, and they reach your vendor through your contract. The practical questions: is audio retained, for how long, is it used for model training, and can you turn that off? Get the answers in writing before you build.

Age restrictions, including the indirect kind. This one catches teams off guard. It isn't only whether your users are old enough to accept terms of service. It's whether the audio concerns someone who isn't. A K-12 product where teachers do the recording still produces recordings that contain information about minors. If your product touches K-12 at all, raise this with your vendor and your own legal team early. It can require contract terms that don't exist in a standard signup flow.

Institutional data agreements. Universities increasingly require a Data Security Agreement or DPA before a department can keep using a service. These arrive from procurement offices that weren't part of your sales conversation. Ask vendors whether they offer a standard DPA and whether they'll provide terms in an editable format. A vendor who can't will cost you months.

Data residency. European institutions will ask where audio is processed. AssemblyAI offers EU data residency through api.eu.assemblyai.com for pre-recorded audio and streaming.eu.assemblyai.com for streaming, at the same price as US processing.

4. Accessibility is a procurement gate, not a feature

For higher-ed and public-sector buyers, captions are a legal obligation under the ADA and Section 508. The bar is set by what's defensible, not by what's impressive in a demo. That means two things for your evaluation.

There's an accuracy threshold, so find out who set yours. Institutional captioning policies commonly cite a 99% accuracy bar. That figure comes from institutional policy and procurement practice, not from the statutes, and institutions apply it differently. Ask the institution you're selling into what standard they enforce and how they measure it. Then answer the empirical question, whether a given model clears that bar on your audio, with your own files.

Caption mechanics matter more than they look. Getting WebVTT or SRT out of an API is easy. Getting it right at scale is harder: cue-level timing that stays aligned, speaker attribution in the caption track, and per-cue translation that keeps the original timing. That last one is a trap. Workflows that translate at the utterance or speaker-turn level instead of cue by cue produce misaligned subtitles in every target language, and teams usually find out after they've built the pipeline. If you ship captions in several languages, test timing alignment on a long file before you commit to an architecture. Our roundup of AI subtitle generators covers the output formats.

Ask about a VPAT. Higher-ed and public-sector procurement routinely requires an Accessibility Conformance Report. Ask every vendor on your list whether they have one. Their answer, and how fast they give it, tells you how many education deals they've actually closed.

Sign up free

Sign up free and caption your catalog with Universal-3.5 Pro at $0.21/hr, pay-as-you-go, with no minimums for the summer trough.

Sign up free

5. Build, buy, or self-host

Institutions with GPU budgets and research staff will reasonably ask why they shouldn't self-host an open model. It's a fair question, and the answer isn't automatic.

Self-hosting makes sense when you have data residency constraints no vendor satisfies, staff who will own the pipeline for years rather than a semester, and an open model that meets your accuracy needs on your actual audio.

It usually doesn't when your workload is seasonal (you're buying GPU capacity for a September peak and idling it through July), or when your hardest audio is the audio open models handle worst. For education, that's children's speech, heavy accents, and far-field classroom questions. The gap between a self-hosted open model and a current commercial model is widest exactly where education needs it narrowest. Our comparison of open-source speech-to-text models covers the options if you want to test that claim.

The practical middle path: many platforms use a commercial API for the hard audio and hosted infrastructure for the easy audio. If you model this, model it against your real cohort mix, not an average.

The scorecard

Take this into your evaluation:

CriterionThe question to askDisqualifying answer
Student-speech accuracyWER on our accented, young-learner, and far-field audioOnly benchmarks on clean read speech
Multilingual + code-switchingHandled natively, or as a separate detection pass? How many languages in real time?Requires committing to one language per file
DiarizationDoes it survive short student questions over instructor speech?Post-hoc clustering that smears short turns
Long-file handling90-minute files without chunking or quality drift?Duration caps that force you to split lectures
Backfill throughputWhat's the parallel-job limit, what happens past it, and can it be raised?Over-limit submissions rejected instead of queued, or a fixed limit
Live-captioning capacityWhat's the new-session rate limit when 40 classes start at once, and does it scale?No answer, or a fixed ceiling you can't raise
Seasonality fitWhat do we pay in July?Annual commits or minimums
Caption outputWebVTT/SRT with speaker labels; per-cue translation timing?Translation at utterance level that misaligns every language
Student dataRetention, training opt-out, DPA availability, K-12 age termsNo editable DPA; can't answer the K-12 question
AccessibilityVPAT/ACR available? Accuracy against the institution's bar on our audio?No answer on either
SupportWho do we reach at 8am on the first day of term?Ticket queue only

For how these pieces fit into a product, see Voice AI use cases for learning management systems, lecture transcription, and the edtech use case page. If you want to see the pipeline end to end, build a lecture summarization app.

The thing worth deciding first

Most education teams run this evaluation on lecture audio, because lecture audio is what they have lying around. Every vendor scores well, the differences look like rounding errors, and the decision comes down to price.

Then the product ships, and the complaints are all about the student who asked a question from the back of the room, the international student whose name is transcribed four different ways, and the second-grader the reading app can't understand.

Those were the cases that should have decided the evaluation. They're the reason differences between vendors exist at all. On easy audio, every modern model is fine. Build your test set from your hardest cohort and the decision usually makes itself.

Run your own evaluation

Run your own evaluation with a free API key and pay-as-you-go pricing. Start with your hardest files.

Sign up free

Frequently asked questions

What is the best speech-to-text API for an education platform?

The right API is decided by your hardest student cohort, not by average benchmark accuracy, because every modern model does well on clean instructor audio. Build your evaluation set from accented, young-learner, and far-field classroom recordings. Then weigh long-file handling, backfill throughput, live-captioning capacity, seasonal pricing fit, caption output, and student-data terms. AssemblyAI's Universal-3.5 Pro costs $0.21/hr pay-as-you-go with native code-switching across 18 languages, and Universal-3.6 Pro Realtime handles live captions in 32 languages.

How much does it cost to transcribe a university's lecture archive?

At $0.21/hr for pre-recorded transcription, a 10,000-hour archive is about $2,100 in transcription cost. The binding constraint is usually throughput, not price. With AssemblyAI the parallel limit is 200+ jobs on paid accounts, over-limit submissions are queued rather than rejected, and higher limits are free on request. Factor in human review too: at accessibility-grade accuracy, review hours often cost more than transcription.

What accuracy do captions need for ADA and Section 508 compliance?

Institutional captioning policies commonly cite a 99% accuracy bar, but that figure comes from institutional policy and procurement practice rather than the statutes, and institutions enforce it differently. Ask the institution you're selling into what standard they apply and how they measure it, then test whether a model clears it on your own audio. Procurement also commonly requires a VPAT or Accessibility Conformance Report.

Does FERPA apply to speech-to-text vendors?

FERPA obligations sit with the institution and the platform serving it, and they reach your transcription vendor through your contract. Settle in writing whether audio is retained, for how long, whether it's used for model training, and whether you can disable that. Confirm the vendor offers a DPA in an editable format.

Does COPPA apply to speech-to-text for K-12 products?

If your product collects audio from children under 13 in the US, COPPA can apply to you as the operator, and your vendor terms need to support it. Even when teachers do the recording, the audio may contain information about minors. Raise age-related terms with your vendor and your legal team before launch, because standard signup terms often don't cover it.

Can speech-to-text APIs handle children's speech?

Some can, and the variance between models is much larger than on adult speech. Children's audio differs in pitch, phonetics, articulation, and pacing, so a model that's excellent on adult benchmarks can be unusable for early-literacy products. If you build for K-12 or reading instruction, make children's speech the majority of your evaluation set.