IronStratum Get an API key

Speech to text API: two open-weight STT routes, one meter

A speech to text API turns audio into text over a network call. You send recorded audio or a live stream; a model returns words. This page is the map of that product on IronStratum: two open-weight routes, one built for finished recordings and one built for live speech, both metered by the same unit, audio time, against one prepaid wallet.

The catalog here is small on purpose and stated exactly. The hayamimi route is wired, measured, and proven against the live serving chain, and its card sits stopped until the specialty fleet wave starts while the beta runs. The streaming route, a model designed to transcribe and attribute speakers as speech arrives, is not in the catalog: its row is held back on a measured quality problem this page explains plainly. Nothing here is dressed up as broader or more ready than it is.

Last verified: 2026-09-11

What a speech to text API is

The contract is simple. A client sends audio, tagged with a model name; the service returns a transcript, usually with segment boundaries and a duration. For the file case the industry converged on a single request shape, the OpenAI audio transcription endpoint, which OpenAI's guide documents at POST /v1/audio/transcriptions: an audio file plus a model id, with finished files on one route and live speech on a separate realtime route. That convention is why transcription integrations move between hosts, and this platform's batch route speaks it, so the standard client libraries work here with a base URL change.

Two shapes of audio drive every design decision in this category. Finished audio, a file that already exists, wants the batch shape: upload it whole, wait, read one final answer. Live audio, speech that is still being spoken, wants the streaming shape: send audio as it arrives and read partial text while the speaker talks, then finals, then a polished refine pass. Vendors sell both faces under one product because the faces share a model but not a contract. Picking the wrong face is a common first integration mistake. Streaming at a pile of stored files buys latency nobody reads, and batch inside a live assistant buys silence the user watches.

The two routes on this platform

The hayamimi route serves the hayamimi project: an open-source, real-time speech to text system built to run on CPU hardware, no GPU and no large memory budget, published on GitHub. Its engineering idea is routing: instead of one general model for every language, it picks a specialist recognizer per utterance, a Japanese engine for Japanese, a Mandarin engine for Mandarin, and so on. That is why it holds its accuracy on languages where general models slide. Hosted here it carries 29 dedicated language codes and two faces: the batch upload, and a streaming face that emits draft text while the audio plays and refines it after. The route's wiring is complete and its measurements are published; the card sits stopped until the fleet wave starts, and its page carries the measured numbers, the audio limits, and copyable code tabs.

The streaming route belongs to VibeVoice-ASR-Streaming, Microsoft's model for transcribing speech and attributing speakers as it arrives, released under MIT with its model card naming ten languages and a design that folds speaker attribution into the transcription pass. This platform stood up a serving lane for it and ran the measurements, and one of those measurements is why the row is not in the catalog: on this platform's own three speaker test, the transcript attributed words to the wrong speaker. The row returns only when three conditions hold together: the checkpoint must write each speaker into its own output field instead of inline text markers, an attribution result that holds across a full multi speaker conversation, tested the whole way through, and a session length answer for long streams. None of those conditions carries a date. Until they hold, the VASR model page stands as the capability record and the integration design, written so a client built against it works unchanged on the day the row returns.

The catalog table below this copy renders from the platform's registry, which is the availability truth for every SKU on the site. Where a row stands at any moment, serving, wired and held, or dropped, is what that table says, not what a paragraph hopes.

Batch or streaming: choosing the shape

The choice is about the audio, not the model. Name the state of your audio and the shape follows.

Your audioThe shapeWhat you get
A recording that already existsBatchOne request, one final transcript, durations in the response
A backlog of filesBatch, chunkedLong recordings split client side into a few requests
Speech happening nowStreamingPartial text while the speaker talks, finals, then refine
An assistant or caption screenStreamingText fast enough for a reacting interface

Batch is the simpler build: no sockets, no event loop, one response to parse. Its discipline is chunking, because every batch face has a per request ceiling and long audio means several requests joined client side. Streaming is the reactive build: partials arrive while the words are still being said, which is what a caption bar or a voice assistant needs, and it is wasted effort on stored files. The guide Long audio and long text, streaming and chunking done right, linked in the guides block, goes deep on the boundaries.

The speaker diarization question

Ask the search results about speech to text and the word diarization surfaces immediately, in ads, in feature lists, in community threads. Diarization is the who-said-what layer: marking which speaker said each stretch of a conversation. It is genuinely hard. Three community threads this research read, spanning two years, carry the same complaint in different words. Multi speaker audio is where transcription breaks, and attribution errors are the failure that makes a meeting transcript unusable even when the words are right.

The designs on the market split into two camps. The separate stage bolts a diarizer onto a transcriber: the words come from one model, the speaker turns from another, and the two are stitched by timestamps. The unified design trains the speaker into the transcription itself, which is the camp the streaming model here belongs to: its technical report describes a design that commits each speaker label within seconds of the words and never revisits it. The catch sits in the output format. On the wire the label is prose, not data: the transcript simply contains a marker string, Speaker 1: in front of the words, and neither a speaker field nor a timestamp rides along. A pipeline that wants speaker as data is left parsing text or adding a pass. That detail lives in the fine print of every implementation this research read, including the big cloud ones that document speaker assignment as generic identifiers assigned during recognition.

This platform's own contribution to that honesty is a measurement. In testing the streaming checkpoint here, a three speaker conversation came back with words attributed to the wrong speaker, and that result, not a roadmap slide, is what keeps the row out of the catalog. The bar it must clear is written above and it is verifiable. The hosted hayamimi route, for its part, returns no speaker labels at all: its transcript is text, segments, and duration. If you need who said what through this platform today, the honest options are narrow: the local hayamimi application, which ships live turn labels while warning that its speaker count runs high, or a separate diarization pass against any transcript.

Whoever you buy from, the test is the same and cheap to run: take ten minutes of your own multi speaker audio, with overlap, with interruption, and score the claimed output yourself before wiring the vendor in. The guide Real-time speaker diarization, linked in the guides block, is built around that discipline.

How STT billing works here

Transcription is sold by audio time everywhere; the pricing conversations and pricing pages quote per audio hour. This platform meters by the audio second on both routes: the duration of the speech processed is the bill, whether the audio arrived as one upload or one stream. A request refused at the door, a bad format, an unknown model id, bills nothing. On the streaming face, metering follows the durations reported by final events, so a slow network never inflates a bill.

The spend limit is the prepaid wallet. Calls draw down the balance, and a request that arrives after the balance is gone is refused with a named error rather than running into debt. The bill is usage alone: no subscription and no per seat fee. Keys are revocation boundaries: each key revokes on its own the instant its project changes; every other key on the wallet keeps working, while per key spending caps are planned, not yet part of the surface. No rate appears by hand on this page or the model pages; every rate shows up on the pricing page, generated from the registry at build time, which is the one place a change appears first. The guide How to avoid API bill shock, linked in the guides block, covers the habits that keep a metered endpoint predictable; the wallet stop here is those habits made structural.

One market fact worth knowing before you compare rate cards: batch and streaming are usually priced as two different numbers for the same model, because immediacy is a feature someone pays for. Compare the unit and the face, not just the number.

Running the weights yourself

Both routes serve open-weight projects, and the license terms permit running them yourself. The hayamimi repository documents its local install, a Python environment and a model download, and it runs on ordinary CPUs, which is its design point. The streaming model's weights and serving recipe are public under MIT for anyone with a GPU. The local road is real, and neither model's page hides it.

The tradeoffs are the ordinary ones. Locally you own the process, the storage, the updates, and the accuracy verification, and in this corner of open source there is a maintenance lesson worth stating: several once popular speech engines are now archived or unmaintained, so a self hosted stack is only as durable as the project behind it, and checking a project's recent activity is part of the install. Hosted, you get a measured lane, honest metering, the wallet ceiling, and revocable keys, and the weights stay downloadable, so switching roads later costs nothing but setup.

Getting started

  1. Request access on the console. Entry runs by invite during the beta; the console screen holds the wallet balance, the API keys, and the full spend record.
  2. Create an API key. Scope it to a single project: a revocation retires one project's access and nothing else.
  3. Take the route that matches your audio. For finished recordings, open the hayamimi model page, read its measured limits, and copy a code tab with your key in it. For live speech and speaker attribution, read the VASR page first: it states exactly what is built, what is measured, and what the listing waits on, so the client work can happen now, ahead of the switch.
  4. Check the rate card. The pricing page holds every rate, rendered from the registry, and the models index lists every SKU: chat, speech, embeddings, rerank, and parsing, all on the same wallet.

The catalog table

Specialty models — kind and unit price
ModelKindPrice
hayamimi-sttspeech to text$0.60 / audio-hour
whisperspeech to text$0.25 / audio-hour

Token prices per 1M unless the unit says otherwise; a dash means the value isn't set yet — confirmed when the model goes live. Everything here is served by the same API that bills you: GET /v1/models. The full list with model details lives on the model index.

Guides

Questions

What does a speech to text API do?
It takes audio in over HTTP and returns text out. You send a recorded file or a live stream, a model on the other end turns the speech into words, and you get back a transcript, usually with segments and a duration. The same routes feed captions, meeting notes, voice agents, voicemail backlogs, and search over recorded audio. On this platform the hayamimi route follows the request shape of the OpenAI audio transcription endpoint, batch upload and streaming face both, so client libraries written for that shape work here with a base URL change. The streaming route's WebSocket face carries its own frame protocol, documented on its model page.
What does a speech to text API cost?
Across the market, transcription is quoted by audio time, and most rate cards quote per audio hour. The two routes here meter by the audio second: the duration of the speech you actually sent is what bills, and a request turned away before transcription starts costs nothing. Spend draws down a wallet you charge in advance, and the ceiling is applied to arriving work: once the balance is gone, the next request is refused with a named error. A transcription already in flight when the balance empties runs to completion and bills, so the overshoot is bounded by that one request's audio seconds, never an open-ended loop. Nothing on this page states a rate. The pricing page carries the current rates, rendered from the registry the meter reads.
Can you get speech to text for free?
Free means two different things and the honest page separates them. The model weights are free in the licensing sense: both routes here serve open-weight projects whose code and weights can be downloaded and run on your own machine at no license cost. Hosting the model for you is the metered half of the offer: the route trades that upkeep work for a bill measured in audio seconds against a prepaid wallet. Free tiers elsewhere are usually evaluation-sized allotments that end. When free means paying nothing for a license and running your own machine, both models have that road, and their pages link the official downloads.
Which languages do the routes cover?
Coverage belongs to the route, not the category, so the honest answer is per model. The hosted hayamimi set covers 29 dedicated language codes. The list runs Japanese, Mandarin, Korean, Cantonese, English, and 24 European languages, and Japanese is the best measured. Its local install can fall back to many more languages that the hosted endpoints do not carry. The streaming route's model targets ten languages, Chinese and English among them. Blanket language counts are a marketing habit; the exact list is a fact of the model page, and each one carries it.
Does either route do speaker diarization?
Read any diarization claim carefully, because this is where transcription marketing outruns the models. The hosted hayamimi route returns text without speaker labels; its local application ships live turn labels, with the project itself warning the speaker count runs high, so treat them as turn indicators, not a count of people. The streaming model was built to transcribe who said what in one pass, and this platform's own testing watched it attribute words to the wrong speaker on a three speaker recording, which is why its catalog row is held back until a checkpoint passes a multi speaker test. Ask any vendor for scored output on your own multi speaker audio before trusting a checkbox.
Batch or streaming: which shape do I need?
Start from the audio. If the recording already exists, in a file, a call, a voicemail box, a video archive, use the batch shape: upload the whole thing and read one final transcript, chunking long recordings into a few requests. If the words are still being spoken, in a live caption, an assistant, or a monitoring screen, use the streaming shape and consume partial text as it lands. Streaming costs engineering; batch costs patience. Only build the streaming leg when something on your screen reacts to the words while they are being said.
Can I transcribe audio on this platform today?
Here is the exact state. The hayamimi route is wired, measured, and proven through the gateway, and its card sits stopped until the specialty fleet wave; the platform is in an invite only beta, and the card lights up with that wave. The streaming route's catalog row is dropped: the lane is built and its measurements are published, and the row returns only when the checkpoint writes each speaker into its own output field, correctly attributes speakers across a full multi speaker conversation, and long streams get a session length answer. None of those conditions carries a date. The models index shows where every row stands, updated as the registry changes.