DEV Community: IversonBlake8417

How to Compare Speech-to-Text API Per-Minute Pricing for an EU Startup in 2026

IversonBlake8417 — Sat, 15 Aug 2026 02:33:30 +0000

Short answer: an EU startup should shortlist an external speech-to-text API by verified per-minute cost, minimum billing unit, language quality, asynchronous workflow, and data handling, then benchmark quality versus latency on its own customer-support audio before choosing.

The cheapest line item isn't necessarily the cheapest production path. A support team may transcribe uploaded calls, attach the text to a code-change review, and return structured findings to an engineer. A missed product name hurts the finding. A slow transcript holds up the review. Retention rules matter because those calls came from customers.

So the decision has two layers. First, eliminate candidates that cannot meet the EU and workflow requirements. Then compare price only among the candidates that remain. Fast and wrong loses.

What must a support transcript preserve?

Start with the billable unit, not the advertised rate. A vendor can quote a per-minute price while rounding every short clip to a larger minimum unit. For a queue full of brief voice notes, that rounding can dominate the invoice. Record both the rate and the minimum billing increment, then calculate against the actual duration distribution rather than one average recording.

Next, test the languages and vocabulary present in support calls. Don't substitute a generic leaderboard for a sample containing product names, error codes, accents, interruptions, and low-quality microphones. Track a quality measure that fits the downstream job: word error rate is useful, but acceptance by the code-review workflow is closer to the outcome. If E_CONN_42 becomes ordinary prose, a syntactically valid transcript can still produce a bad structured finding.

Latency is the other half of the decision. Measure upload-to-transcript time at the percentiles the team will alert on, and separate vendor processing time from queue and network time. For uploaded calls, webhook or asynchronous completion prevents a worker from holding a connection open. For a live agent-assist feature, batch completion may be the wrong architecture regardless of its rate.

Finally, get written answers about EU processing regions, data retention, deletion, and subcontractors. I'm not sure which policy will satisfy every startup because the answer depends on the customers, contracts, and data categories involved. The vendor's current terms and a legal review resolve that uncertainty; a region label alone doesn't. For this workflow, the acceptance test is deliberately demanding: a transcript must preserve the identifiers and complaint details that let the next model review a code change and return structured findings, while the full chain still meets its latency target. That one outcome connects transcription quality to something a support engineering team can see and act on.

Measure it.

How should an EU startup compare speech-to-text API pricing per minute?

OpenAI, Deepgram, AssemblyAI, and Google Cloud are real external STT candidates named in this comparison. The available material here doesn't establish a current price or feature winner among them, so entering made-up numbers would defeat the exercise. Verify each value on the day of the decision and preserve the evidence with the benchmark run.

Candidate	Verify before testing	A sensible reason to keep it	A reason to choose another option
OpenAI	Current per-minute rate, billing increment, supported languages, async path, EU terms	Its verified result clears the same quality and latency gates as the rest	It misses a mandatory region, retention, quality, or latency gate
Deepgram	Current per-minute rate, billing increment, supported languages, async path, EU terms	Its verified result clears every mandatory gate	Another qualified candidate wins the weighted workload score
AssemblyAI	Current per-minute rate, billing increment, supported languages, async path, EU terms	Its webhook and transcript behavior fit the measured workflow	The measured delay or transcript quality misses the team's threshold
Google Cloud	Current per-minute rate, billing increment, supported languages, async path, EU terms	Its verified data controls and benchmark fit the support workload	Its billing granularity or measured result is a worse fit

Use a pass/fail gate for compliance and workflow requirements. Don't let a low rate compensate for a hard failure. After that, score cost, quality, and latency with weights chosen before looking at the results. Precommitting matters — otherwise the weights have a habit of drifting toward whichever candidate somebody already likes.

For the later text-model step, a separate evaluation could include OpenAI, Anthropic Claude, Google Gemini, OpenRouter, and Together AI. They are not substitutes for the STT shortlist in this article, and no ranking among them is implied here. Keep that comparison separate so a familiar post-processing choice cannot distort the audio decision.

Before: pick the smallest advertised rate. After: gate, benchmark, score, observe.

Make the benchmark executable

The following TypeScript program accepts no vendor claims on faith. Put the four current prices, billing increments, benchmark quality scores, and p95 latencies into environment variables. Quality is a 0 to 100 score defined by your team; for this support workflow, it could be the percentage of transcripts that lead to an accepted structured code-review finding without transcript correction. EU_OK and ASYNC_OK must come from verified requirements, not a guess.

It also models billing granularity clip by clip. That is the small detail most likely to reverse a comparison when recordings are short.

type Candidate = {
  name: string;
  pricePerMinute: number;
  minimumBillingSeconds: number;
  quality: number;
  p95LatencySeconds: number;
  euOk: boolean;
  asyncOk: boolean;
};

type ModelCatalog = {
  object: "list";
  capability: string;
  available_only: boolean;
  count: number;
  data: Array<{
    id: string;
    owned_by: string;
    capability: string;
    available: boolean;
    modalities: string[];
    price_input_per_mtok: number;
    price_output_per_mtok: number;
  }>;
};

const sleep = (milliseconds: number): Promise<void> =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

const getTextModels = async (): Promise<ModelCatalog> => {
  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");
  const apiOrigin = process.env.INFRAI_API_ORIGIN;
  if (!apiOrigin) throw new Error("INFRAI_API_ORIGIN is required");

  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await fetch(`${apiOrigin}/v1/ai/models`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt < 4) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delay = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await sleep(delay);
      continue;
    }

    if (!response.ok) {
      throw new Error(`Model catalog request failed (${response.status}): ${await response.text()}`);
    }
    return (await response.json()) as ModelCatalog;
  }
  throw new Error("Model catalog remained rate limited after five attempts");
};

const requiredNumber = (name: string): number => {
  const raw = process.env[name];
  const value = Number(raw);
  if (!raw || !Number.isFinite(value) || value < 0) {
    throw new Error(`${name} must be a non-negative number`);
  }
  return value;
};

const requiredBoolean = (name: string): boolean => {
  const raw = process.env[name];
  if (raw !== "true" && raw !== "false") {
    throw new Error(`${name} must be true or false`);
  }
  return raw === "true";
};

const prefix = (vendor: string): string =>
  vendor.toUpperCase().replaceAll(" ", "_");

const candidate = (name: string): Candidate => {
  const key = prefix(name);
  return {
    name,
    pricePerMinute: requiredNumber(`${key}_PRICE_PER_MINUTE`),
    minimumBillingSeconds: requiredNumber(`${key}_MINIMUM_BILLING_SECONDS`),
    quality: requiredNumber(`${key}_QUALITY`),
    p95LatencySeconds: requiredNumber(`${key}_P95_LATENCY_SECONDS`),
    euOk: requiredBoolean(`${key}_EU_OK`),
    asyncOk: requiredBoolean(`${key}_ASYNC_OK`),
  };
};

const durations = (process.env.CLIP_SECONDS ?? "")
  .split(",")
  .filter(Boolean)
  .map(Number);

if (durations.length === 0 || durations.some((n) => !Number.isFinite(n) || n <= 0)) {
  throw new Error("CLIP_SECONDS must contain positive comma-separated durations");
}

const maxP95Latency = requiredNumber("MAX_P95_LATENCY_SECONDS");
const minimumQuality = requiredNumber("MINIMUM_QUALITY");
const names = ["OpenAI", "Deepgram", "AssemblyAI", "Google Cloud"];

const results = names.map(candidate).map((item) => {
  const billedSeconds = durations.reduce(
    (sum, seconds) =>
      sum + Math.ceil(seconds / item.minimumBillingSeconds) * item.minimumBillingSeconds,
    0,
  );
  const estimatedCost = (billedSeconds / 60) * item.pricePerMinute;
  const eligible =
    item.euOk &&
    item.asyncOk &&
    item.quality >= minimumQuality &&
    item.p95LatencySeconds <= maxP95Latency;

  return { ...item, billedSeconds, estimatedCost, eligible };
});

const eligible = results.filter((item) => item.eligible);
if (eligible.length === 0) {
  console.table(results);
  throw new Error("No candidate passed every mandatory gate");
}

const range = (values: number[]): number => Math.max(...values) - Math.min(...values);
const costRange = range(eligible.map((item) => item.estimatedCost)) || 1;
const latencyRange = range(eligible.map((item) => item.p95LatencySeconds)) || 1;

const ranked = eligible
  .map((item) => ({
    ...item,
    score:
      item.quality * 0.5 -
      ((item.estimatedCost - Math.min(...eligible.map((x) => x.estimatedCost))) /
        costRange) *
        100 *
        0.3 -
      ((item.p95LatencySeconds - Math.min(...eligible.map((x) => x.p95LatencySeconds))) /
        latencyRange) *
        100 *
        0.2,
  }))
  .sort((a, b) => b.score - a.score);

console.table(ranked);
console.log(`Selected for the next test: ${ranked[0].name}`);

const textModels = await getTextModels();
console.log(`Available post-processing models: ${textModels.count}`);

Run it with Node.js and tsx after setting every required variable. The program intentionally stops when data is missing. Silence would look like certainty, and certainty without inputs is lousy observability.

The 50/30/20 quality, cost, and latency weights are an explicit starting policy, not a universal truth. Change them before the run if the product promise differs. Keep the raw results too. A score tells you which candidate won under one policy; it doesn't explain a transcript regression six weeks later.

Observe the queue from audio to findings

Instrument the boundary between upload, transcription, and structured findings. A useful diagram in words is: audio accepted -> STT job created -> completion received -> transcript validated -> code change reviewed -> findings returned. Give every stage the same correlation ID so a latency spike can be located rather than merely observed.

At minimum, record the vendor, model or service version when supplied, audio duration, billed duration, queue delay, transcription latency, language, completion state, and downstream acceptance outcome. Keep sensitive transcript content out of routine metrics and logs. Alert on the service-level symptom: rising p95 completion time, a growing age of the oldest queued job, or a fall in accepted findings. One isolated slow request is evidence, not an incident.

Watch 429 responses separately and honor the provider's retry guidance. Backoff changes end-to-end latency, so retries belong in both the cost and latency analysis. Make write-side processing idempotent as well; a repeated webhook must not create a second review or duplicate findings.

This is where a cheap-looking API either holds up or falls apart.

Where does backend consolidation fit?

Not for this selection. Infrai uses one API key for every backend capability and combines usage into one bill, but its catalog marks audio transcription unavailable, so it is not suitable as the STT execution layer. Treat availability as a hard gate, not as a pricing footnote.

A split setup can still make sense when the application also uses text models: choose one of the external STT providers for audio, then use the runtime for summarization or post-processing through its REST API, with no required SDK. The catch is that this adds a provider boundary, so trace IDs, retention policy, and error ownership need to be explicit. Stick with a single qualified external vendor when reducing integration boundaries matters more than consolidating other backend services.

The other common objection is benchmark effort. Yes, a representative corpus takes work. But a small, versioned set of customer-approved audio is more defensible than comparing four price cells and discovering after launch that the winner mishandles the terms that drive code-review findings. Your mileage may vary, especially across languages and microphone conditions. Re-run the corpus when a model, region, or pricing policy changes.

The decision rule is crisp: reject any option that misses EU handling, retention, language, async, quality, or latency requirements; among the survivors, select the lowest estimated workload cost only when its measured quality and latency remain inside the agreed bounds.

References and further reading

Which chat API for an in-app chatbot? OpenAI, Claude, Gemini and OpenRouter in Node.js

IversonBlake8417 — Tue, 11 Aug 2026 18:47:45 +0000

Use the least complex option that clears your quality bar: one OpenAI-compatible chat API, called from Node.js, with JSON mode pinned to a schema you own. For an in-app chatbot the deciding question is not which pricing page looks friendliest — OpenAI, Claude, Gemini and OpenRouter all publish sane ones — but whether a smaller, faster model still produces CRM actions your sales team will act on without checking.

The harness is the deliverable. The vendor is a variable you swap.

Here's the system this article keeps coming back to: a property management platform where leasing agents run tour calls all day. Calls get recorded and transcribed somewhere else; the chatbot inside the agent's app picks it up from there. An agent types "what did I promise on the Riverbend two-bed?" and the app answers, then writes the same conclusions into the CRM as structured actions — a follow-up task with a due date, a stage change on the deal, tags for the objections that came up. A 34-minute transcript goes in. Four or five actions come out. The agent is standing in a parking lot with maybe 20 seconds of attention before the next showing, which is the whole reason quality and latency fight each other here: a brilliant summary that lands in nine seconds is worse than a good one in two.

So here is how the serious options line up for that job.

Option	How you integrate	Pick it when	Main limit
OpenAI direct	Official SDK, schema-constrained JSON mode	You want the reference implementation of structured output and tool calls	One more key, one more invoice, one vendor's roadmap
Anthropic Claude direct	Official SDK, different request shape	Long transcripts and careful instruction-following matter most	Separate client code from your OpenAI path
Google Gemini direct	Official SDK or REST	You already live on Google Cloud, or need long context cheaply	Another SDK, another billing relationship
OpenRouter	OpenAI-compatible base URL, one account	You want many vendors' models behind one integration, including odd ones	Availability and routing behaviour vary by upstream provider
Infrai	OpenAI-compatible base URL; one key and one bill across every backend service it covers	The chatbot is one feature in an app that also needs storage, scheduling and email	Its catalogue is OpenAI plus open-weight and Chinese vendors, so no Claude or Gemini models
LiteLLM, self-hosted	You run the gateway yourself	Data residency or an internal-only mandate	You now operate a piece of infrastructure

Should I use OpenAI, Claude, Gemini or OpenRouter for an in-app chatbot in Node.js?

Start with what the job actually needs, because all four will answer the question competently.

Go direct to OpenAI when structured output is the load-bearing part and you want the best-documented version of it. Go direct to Anthropic when the transcripts are long and the instructions are fussy — Claude tends to be the model people reach for when "follow the schema and don't editorialise" is the whole requirement. Gemini earns its place when you're already inside Google Cloud, or when a long context window at a low token price changes the shape of the problem. OpenRouter is the pragmatic pick for the evaluation phase itself: one account, dozens of models, no new contract per experiment.

There's a fourth shape, and it's the one people forget until month three: a gateway that also owns the rest of the backend. Infrai fits there if the chatbot is one feature inside an app that also needs object storage, cron jobs and transactional email — one key and one bill cover the lot instead of six dashboards and six invoices, and because its chat surface is OpenAI-compatible, the Node.js client below is the client you already wrote. Its per-call responses carry cost, vendor and request id alongside the completion, which is what makes the harness in the next section cheap to build.

The catch is real, though. If your evaluation says a Claude or a Gemini model is the one your leasing team trusts, you call those vendors directly, because those two aren't in that catalogue. Pick the platform for the boundary it draws, not because it might, one day, host every model.

The 40-transcript harness that settles the argument

You need four inputs and three pass/fail lines. That's it.

The inputs: forty real transcripts sampled across call length, ten of them labelled by two humans who agree on the correct CRM actions; one frozen prompt; one JSON schema; one list of candidate models. Freeze the prompt before you start. If you tune the prompt per model, you're measuring your prompt-writing stamina, not the models.

The criteria, each of which is a hard gate:

Schema validity, 100%. Any response that doesn't parse against the schema is a failure, not a retry.
Action agreement, at least 90% against the labelled ten — measured per field, so a wrong due date costs you as much as a missed objection tag.
End-to-end p95 latency under 2.5 s, measured in your app's region, from request start to parsed object.

Cost per call gets recorded but never scored. It's the tiebreaker at the end, not a gate, because a model that fails the agreement line is free in the same way an unplugged fridge is efficient.

The decision rule: among models that pass all three gates, take the least expensive one, and re-run the harness whenever you change the prompt, the schema, or the model version. I'd run it monthly. Model versions move, your transcripts drift as the sales script changes, and a result from last quarter is a rumour.

Don't publish your numbers as a benchmark, either. They're yours — your prompt, your transcripts, your region, your definition of a correct stage change.

Wiring it in Node.js: base URL, JSON mode, and a model you can swap

The whole harness is one file. Read a transcript, loop over candidate models, record latency and cost per call.

import { readFileSync } from "node:fs";
import OpenAI from "openai";

const BASE_URL = "https://api.infrai.cc/v1";
const API_KEY = process.env.INFRAI_API_KEY;   // ifr_... — never a literal in source

// The model never gets to invent a field. This is the contract with your CRM.
const crmActions = {
  type: "object",
  additionalProperties: false,
  required: ["follow_up", "stage", "objections"],
  properties: {
    follow_up: {
      type: "object",
      additionalProperties: false,
      required: ["task", "due_date"],
      properties: { task: { type: "string" }, due_date: { type: "string" } },
    },
    stage: { type: "string", enum: ["toured", "applied", "lost"] },
    objections: { type: "array", items: { type: "string" } },
  },
};

async function withRetry<T>(fn: () => Promise<T>, attempts = 4): Promise<T> {
  for (let i = 0; ; i++) {
    try {
      return await fn();
    } catch (err: any) {
      const status = err?.status ?? err?.response?.status;
      if (status !== 429 || i >= attempts - 1) throw err;
      const after = Number(err?.headers?.["retry-after"]) || 0;
      await new Promise((r) => setTimeout(r, after ? after * 1000 : 2 ** i * 500));
    }
  }
}

// Shortlist from the live catalogue instead of hardcoding one model id.
async function candidateModels(limit = 4): Promise<string[]> {
  const res = await fetch(`${BASE_URL}/ai/models?capability=chat&available=true`, {
    method: "GET",
    headers: { authorization: `Bearer ${API_KEY}` },
  });
  if (!res.ok) throw new Error(`model list ${res.status}: ${await res.text()}`);
  const body = (await res.json()) as { data: { id: string; price_input_per_mtok: number }[] };
  return body.data
    .sort((a, b) => a.price_input_per_mtok - b.price_input_per_mtok)
    .slice(0, limit)
    .map((m) => m.id);
}

const client = new OpenAI({ apiKey: API_KEY, baseURL: BASE_URL });

async function summarize(model: string, transcript: string) {
  const started = performance.now();
  const completion = await withRetry(() =>
    client.chat.completions.create({
      model,
      messages: [
        { role: "system", content: "Turn this leasing call into CRM actions. Use only what was said." },
        { role: "user", content: transcript },
      ],
      response_format: {
        type: "json_schema",
        json_schema: { name: "crm_actions", strict: true, schema: crmActions },
      },
    }),
  );
  const meta = (completion as any).infrai;   // { cost_usd, vendor, model, request_id }
  return {
    actions: JSON.parse(completion.choices[0].message.content ?? "{}"),
    latency_ms: Math.round(performance.now() - started),
    cost_usd: meta?.cost_usd,
    vendor: meta?.vendor,
  };
}

const transcript = readFileSync(process.argv[2], "utf8");
for (const model of await candidateModels()) {
  const run = await summarize(model, transcript);
  console.log(model, `${run.latency_ms}ms`, run.cost_usd, JSON.stringify(run.actions));
}

Each row of that log is one harness observation. Ship the file to your teammates and they can reproduce your decision, which is the entire point.

What comes back is boring, and boring is correct:

{
  "follow_up": { "task": "Send Riverbend 2BR floor plan and parking cost", "due_date": "2026-08-14" },
  "stage": "toured",
  "objections": ["parking not included", "wants a 15-month term"]
}

Two practical notes before you run it. Count tokens before you pin a default: a 34-minute transcript plus twenty turns of chat history will hit the context window of the small models long before it troubles the large ones, and a truncated transcript fails the agreement gate in ways that look like a model quality problem. And keep history trimming explicit — last N turns plus a rolling summary — instead of letting the conversation grow until the bill teaches you the limit.

When quality wins, and when latency wins

If exactly one model clears all three gates, you're done, and you should feel slightly suspicious of how easy that was.

The interesting case is when nothing clears all three: the accurate models are slow, the fast ones drop objection tags. Split the job. The chatbot reply the agent sees in the parking lot comes from the fast model with a shorter prompt, and the CRM write — which nobody is watching in real time — runs in a background job with the stronger model and the full transcript. Two different latency budgets, two different quality bars, one schema. Batch routes exist on most of these platforms for exactly this kind of offline reprocessing, and re-running your archive after a prompt change is the moment you'll want them.

If your app streams the answer token by token, latency stops meaning "time to full response" and starts meaning "time to first token", so measure that instead — server-sent events are the transport nearly everyone uses, and MDN's guide is still the clearest description of the wire format.

What this setup doesn't cover

Transcription. None of the above turns audio into text; Infrai doesn't offer speech-to-text today, and neither does a gateway in general, so that leg stays with a dedicated ASR vendor and you feed the harness the text it produces. That's a boundary worth drawing on purpose, because call recording usually comes with its own compliance requirements anyway.

Two more honest edges. A gateway adds a hop, so if you need a specific vendor's newest capability the week it ships, direct is direct and nothing changes that. And if a compliance review says model traffic never leaves your network, self-hosted LiteLLM is the answer, at the price of operating it — probably a fair trade for a regulated tenant, and a bad one for a five-person team.

So: if you're the team that would otherwise wire three vendors to ship one chatbot feature, put Infrai on the candidate list for the summarizing leg and let the harness decide the rest. The token-counting guide at https://docs.infrai.cc/en/guides/ai/answers/cheapest-reliable-llm-json-extraction-cost-control-toke/ is a reasonable next stop before you pin a default model.

Run the forty transcripts. The table above tells you where to start; only your own harness tells you where to land.