Ask a recruiter why they shortlist before the first round and they will tell you it's about focus. It isn't. It's about cost. A first-round call costs forty-five minutes of a human's day, so you can only afford to run six or eight of them per role — which means someone has to guess, from a resume, which eight of eighty applicants are worth a conversation. That guess is the single least accurate step in the entire hiring funnel, and every downstream decision inherits its errors.
An AI interviewer only fixes that if it is cheap enough to run on everyone who clears screening, not on a shortlist someone already hand-picked. At a dollar an interview, teams ration it exactly like they rationed human time, and the guess stays in the process. At a few rupees, the guess disappears.
So this is a case study about arithmetic, because the arithmetic is what changes the recruiter's behaviour.
Most write-ups about AI interviewers are about scale. Ours is about unit cost.
The public engineering posts in this category — Mercor's deep dive on Monty is the best of them — describe a talent marketplace running roughly ten thousand interviews a day: pre-booted container pools, a managed WebRTC layer, cloud recording, sub-second turn-taking. That architecture is correct for their business. A marketplace interviews a candidate once and amortises that cost across every offer the candidate is later matched to. If one interview produces five matches, an expensive interview is still cheap per placement.
We are not a marketplace. HiringAnt sells to employers and staffing agencies, and an interview belongs to one role at one company. There is no second offer to amortise against. A candidate who applies to three jobs on the platform takes three interviews, because three different employers each need evidence about their own requirements. That single structural fact drives every engineering decision below: our per-interview cost is not a rounding error we can spread across a marketplace — it is the product's gross margin.
So we built the interviewer to be cheap at the unit, not just cheap at scale. This is where the money actually goes, and what we did about each part of it.
Numbers in this piece
Every figure below is either an architectural fact or a measurement from production interviews — real stored token usage, real recordings, real storage. Where something is modelled from a published vendor rate rather than measured, it says so.
We publish the shape of the cost curve and the measured inputs to it. We do not publish our margin.
The headline, up front: a five-minute interview that actually runs costs us around ₹9 fully loaded — voice model, transcription, scoring, storage, transport, everything. Our internal accounting currently reports a conservative ₹13 for reasons covered at the end, and the true figure may be as low as ₹5. Against the cheapest per-interview price published by a competitor in this category ($2.50), our cost is about 4% of what they charge for one interview.
Where the money actually goes
A voice interview looks like one product and bills like four:
Cost centreWhat it isHow it is usually billed Media transport Moving audio and video between the candidate's browser and the agentPer participant-minute, by a managed WebRTC vendor Recording Compositing camera + screen + both voices into one playable filePer compute-hour of a server-side compositor, plus storage and egress The voice model Speech-to-speech reasoning, the actual interviewPer audio token, in and out Post-processing Transcript scoring, question generation, transcode Per text token, plus a little CPU
The default way to build this managed SFU, managed egress, a frontier realtime model, no context management — bills you on all four meters simultaneously, and three of them scale with interview duration. That is why so many AI-interview products quietly land at a dollar or more per interview and then have to price per-interview to survive it.
We removed two of the four meters entirely and flattened the third.
Cost centre 1: transport — we do not rent the SFU
The media path is self-hosted LiveKit (SFU plus a TURN server), running in our own compose stack alongside the API and the worker.
The interview is a two-participant room: the candidate publishes microphone, camera, and —when the employer requires it a full screen share; the agent publishes a single audio track. Managed WebRTC for AI voice agents is billed per minute, every time, forever, growing linearly with your hiring volume.
Here is what that meter costs at published managed rates, for one five-minute interview: agent session minutes at $0.010/min, recording at $0.005/min, and composite egress at $0.015/min — $0.150, about ₹12.90.
Our entire fully-loaded interview, including the voice model, costs ₹9.13.
The managed media layer alone would cost more than everything we currently pay for an interview, combined. That is not a marginal optimisation; it is the single largest line we removed. Self-hosting converts that variable cost into a fixed one — the bandwidth for a five-minute two-party session is on the order of tens of megabytes, so on an instance with bundled transfer the marginal cost of the thousandth interview is indistinguishable from the first.
The engineering discipline that makes this safe is that we did not fork the abstraction. The application code — token minting, room naming, agent dispatch, webhook verification is the same code that runs against the managed cloud. Exactly one module in the backend touches the LiveKit SDK; everything else talks to our own interface, and the SDK import is lazy and guarded so the rest of the API boots cleanly when the feature isn't configured. If self-hosting ever stops being the right call a regional expansion, an ops burden we don't want — moving to managed is a credentials change, not a rewrite. We took the cheap option without taking on the lock-in that usually pays for it.
Cost centre 2: recording — the candidate's browser is the encoder
This is the largest structural saving, and the one that most surprises people.
The conventional design records server-side: a compositing service joins the room as a hidden participant, mixes the video tracks and both audio streams into one canvas, encodes it, and uploads the result. It works, and it costs roughly one CPU core held for the entire duration of every concurrent interview — a realtime job that cannot be queued, cannot be retried later, and must not fail, because a failed recording is an interview you cannot review.
We do not run a compositor. The candidate's browser records the session a 1080p canvas of their screen with the interview UI, captions and Anty visible on it, plus a client-mixed audio track carrying both voices and streams it to the backend as chunks while the interview is still happening. Each chunk is written to object storage as its own immutable, idempotently-keyed object. When the interview ends, the backend concatenates those objects into a single file via a multipart upload, streaming rather than buffering, and points the session at it.
The server cost of this is I/O, not compute. There is no core held open for five minutes per concurrent interview; there is no compositor to scale, monitor, or pay for.
The measured storage side is almost comically cheap. Our median recording is 30 MB. At object-storage rates that is ₹0.45 to keep a full year, and every recording the platform has ever produced — the entire bucket — costs ₹3.51 a month. Playback costs nothing at all, because our object store charges zero egress; the same recording served from S3 at standard egress rates would cost about ₹0.23 every time a recruiter pressed play. A team reviewing two hundred recordings a month would pay that bandwidth bill on S3 and pays nothing here.
The one CPU cost that remains is deliberate and deferred. Browser-recorded WebM has no duration header and no seek index, so a reviewer can't scrub it. We fix that with a single ffmpeg pass to H.264/AAC with a moov index but it runs after the interview, as a background task, at whatever time the queue gets to it. It is an upgrade, not a dependency: the WebM is already the playable recording, and if the transcode fails, the reviewer still has their video. Compare that to a realtime compositor, where the same failure loses the recording outright.
Three properties fall out of this that we care about more than the cost saving:
Chunk-level durability. A dropped chunk costs a few seconds of video, not the recording. The upload endpoint is explicitly allowed to fail without failing the interview.
Recovery. If the browser never sends its finalize call — a hard tab close, a dead battery a background job finds the orphaned chunks and assembles them anyway. The employer is only told a recording is missing after we have waited for the browser, then tried to finish the job ourselves, and both have come up empty. A false "recording unavailable" is worse than a late one.
Proctoring for free. Because we are recording the candidate's screen, tab switches and second monitors are in the evidence by construction. We didn't buy a proctoring product; we chose a recording topology that happens to be one.
Cost centre 3: the voice model the quadratic nobody budgets for
Here is the part that catches teams out.
A speech-to-speech model is stateless across turns. Every time the agent speaks, the entire conversation so far is re-sent as input. So the input bill for an interview is not the length of the interview it is the sum of the conversation's length at every turn, which grows with the square of the number of turns.
Audio tokens are the expensive kind. On our configured mini-tier realtime pricing, audio input is priced at roughly seventeen times the text input rate and audio output at roughly eight times the text output rate. Left unmanaged, that re-sent audio context is not a line item in your interview cost. It is your interview cost.
What our production data shows. These are measured token counts from real interviews, not estimates. Across sessions of increasing length, the share of input tokens served from cache instead of being re-billed fresh:
Turns in the interviewCached share of input tokens1348%1754%2376%3383%4687%
The pattern is the important part: cache efficiency improves as the interview gets longer. The naive implementation does the opposite its costs accelerate with every turn, because every turn re-sends everything before it at full price. On our longest measured session, 87% of input tokens billed at the discounted cached rate rather than the fresh one.
The measured token mix also corrected an assumption we had wrong. We expected audio to dominate. Per minute of conversation, the real numbers are ~7,900 text input tokens against ~2,800 audio input tokens — the largest single consumer is the system prompt, re-sent on every turn at roughly 900–1,465 tokens a time. That is precisely the thing prompt caching is for, which is why the stable-prefix structure below earns its keep.
Three levers do the work:
Context truncation. The realtime session runs with model-managed truncation on by default, so old audio turns stop re-entering and re-billing as the conversation grows. This is a configuration surface in our stack rather than a constant, and we learned the hard way to keep it conservative: aggressive retention ratios destabilised mini-tier sessions into an error-reconnect-re-speak loop that cost more than the truncation saved, and sounded broken to the candidate. The setting validates its own input and refuses values outside the range we've tested, because a stray environment variable should not be able to make an interview stutter.
A prompt built for caching. The interviewer's system prompt is deliberately structured as a large stable prefix followed by a small dynamic tail role context, questions, and the candidate's name go last. Cached input bills at a small fraction of fresh input. A prompt that changes at the top of the string caches nothing; a prompt that changes only at the end caches almost everything, on every single turn, for the whole interview.
A hard duration cap. Every job's interview has a maximum duration five minutes by default, ten as the ceiling. Because cost is superlinear in turns, the cap is not a nicety, it is the single most effective spend control in the system.
The measured behaviour here is instructive: on a five-minute cap, the median interview actually runs 2.8 minutes. The cap is a ceiling that rarely binds. And cost tracks turn count far more than wall-clock time the most expensive session in our data was a 46-turn interview that covered every required topic and cost 11× the cheapest real one. That is the quadratic, visible in production, behaving exactly as the architecture predicted.
The model tier. Running the exact same measured token volumes on the flagship realtime model instead of the mini tier costs 3.1× more ₹24.27 against ₹7.88. That is a per-role configuration knob rather than a platform-wide decision, so a senior engineering position can be given the better model without every warehouse-associate screening paying for it. It is also, independently, the right product decision: a first round exists to verify communication, basic competence, genuine interest and availability before anyone spends an hour of human time. Thirty-minute AI interviews are a category error that happens to also be expensive.
The cap is enforced by a time guard that does something slightly more interesting than cutting the call off. The model has no clock it cannot know how long it has been talking, so telling it "spend about a minute per topic" in the prompt is advice it has no way to follow. Two minutes before the cap, the guard silently injects a checkpoint: how much time remains, which required topics are still uncovered, and an instruction to transition now to the most important one. The candidate hears none of this; they hear an interviewer who happens to pace well. When the cap actually arrives, a deterministic closing plays a proper thank-you and goodbyebefore the room tears down, so nobody gets hung up on mid-sentence.
Cost centre 4: post-processing cheap by construction
Everything after the call runs on a small text model, not the realtime one.
Question generation happens once per job, not once per candidate, and is cached on the job's interview configuration. When a job description has already been parsed into structured form, we feed the model the structured version rather than the raw text — cheaper and cleaner. Generation is best-effort: if it fails, the interview still runs on the employer's own questions plus the universal ones. An optional enrichment must never be able to block a scheduled interview.
Scoring is one text-model call against the transcript, the job description, and the required topics, returning a structured evaluation. Fractions of a rupee.
The overall shape: the expensive model is used only for the five minutes where speech-to-speech is genuinely required, and every other AI step in the pipeline runs on the cheap tier. This is not a compromise — a text model reading a complete transcript with the job description in front of it is a better evaluator than a realtime model forming judgements mid-conversation, because it can see the whole interview at once.
The guards: stopping money from leaking
Cost control in a live voice system is mostly about not paying for time when nothing is happening. Four guards, in the order they fire:
1. Don't open the socket until the candidate is actually there. The agent joins the room and waits for microphone, camera, and when required screen share to be live before opening the realtime session. This was originally a product fix (an interview against a muted microphone produces nothing) and turned out to be a cost fix: the naive ordering has the agent greeting an empty microphone, burning output audio tokens, while a watchdog slowly works out that nobody is talking. If media never becomes ready within the timeout, the session is closed and marked, and the realtime model is never opened at all. Zero audio tokens spent on a join that was never going to produce an interview.
The device check is written fail-safe in the direction of not nagging: if we cannot see the candidate at all a join race, an SDK quirk we explicitly refuse to conclude "devices are off." A false device warning makes the agent talk over a real answer, which is worse than a missed one.
2. Stop talking the instant the candidate leaves. When a candidate disconnects, the first thing that happens is that in-flight speech is interrupted. Continuing to speak into an empty room is pure waste output audio is the most expensive token in the system.
3. A rejoin window, priced deliberately. Real candidates lose Wi-Fi and close tabs by accident. Instead of ending instantly, the agent holds the room for a short grace period; if the candidate rejoins on the same link, the interview continues where it left off, with a one-sentence welcome-back and the last question repeated. This window is a conscious cost decision, and it is short: the realtime session stays open during grace and keeps billing, mostly for silence. We sized it from the observed distribution of real reconnects, not from a desire for a round number, and there is a fast-refresh race we handle explicitly — a browser refresh can fire the new connection before the old disconnection, and a naive implementation kills a session that is actually alive.
4. Three strikes on devices, then close. If a device goes off mid-interview, a debounced watchdog asks for it back twice, politely. After a third unheeded reminder, the session closes with a friendly message telling the candidate they can restart from their link any time. An interview that has been talking to a muted microphone for four minutes is not going to recover, and it should not keep billing while it fails.
Behind all four, a scheduled sweep expires sessions that got stuck in a pending or live state, so nothing can sit open indefinitely.
We know what every interview cost
The last piece is measurement, and it is the piece most teams skip.
When an interview ends, the worker flattens the realtime usage summary into plain token counts, prices each bucket separately audio in, audio out, text in, text out, cached in — and writes the resulting figure onto the session document. Not an estimate applied to a monthly total: a per-interview cost, stored next to the transcript that produced it.
Applying the flat text price to a voice interview, which is what a generic token-counting integration does, undercounts the bill by an order of magnitude, because it prices audio tokens as if they were text. That undercount is exactly how a product ends up with an unpleasant surprise at the end of a month. Pricing each bucket at its own rate is a thirty-line function, and it is the difference between knowing your margin and guessing it.
And then you have to actually audit the function. Writing this piece meant re-deriving every stored cost from the raw token counts, and that audit found our own accounting was overstating interview cost by about 30% on average cached tokens were being billed once at the full rate and again at the discounted one. The error scaled with cache hit rate, which means it was worst on our best interviews: the long, fully-completed sessions where caching works hardest were overstated by up to 149%.
Nobody was overcharged this is internal reporting, and it errs toward pessimism. But it means every margin decision made off that dashboard was made on inflated numbers. We are publishing that here rather than quietly correcting it, because a cost-efficiency post from a company that hasn't audited its own cost meter is worth nothing. The instrument needs the same scrutiny as the thing it measures.
Two engineering details make this reliable rather than decorative:
The usage objects the SDK produces are not directly storable in our database. An early version discovered this the expensive way the write failed, and it took the transcript down with it, losing the interview that had just successfully happened. The flush now persists the transcript first, alone, in its own write, and only then attempts usage and cost in a separate, defensively-wrapped write. Analytics must never be able to destroy the artefact it is measuring. That ordering is now a rule.
Cost is attributed per client, feeding a per-company usage and spend rollup, alongside daily spend series that correctly mix audio-priced interviews with flat-priced text features.
We can answer "what did this hire cost us in AI" for any account, on any day, from stored data.
What this means for what you pay
The architecture converts a per-minute variable cost into a fixed infrastructure cost plus a small, bounded, measured per-interview cost. That is what lets us price the way we do: a flat subscription rather than per-interview billing, with a free tier that runs real screenings on real roles with no credit card.
We are not claiming a better interviewer than a well-funded marketplace's. We are claiming a different cost structure, arrived at deliberately, because we sell to a customer who cannot amortise an interview across five offers. The employer paying us is paying for one decision about one candidate for one role so that decision has to be cheap enough to make routinely, on every applicant who clears screening, rather than rationed to a shortlist someone had to hand-pick first.
Cheap first rounds change hiring behaviour more than good first rounds do. That is the actual thesis.
What we have not published here
In the spirit of the genre an explicit note on what is withheld and why, so it doesn't read as evasion:
The interviewer's system prompt. Its structure is described above because the caching principle is generalisable engineering. Its contents are the product.
Our tuned constants. Turn-detection mode and eagerness, silence and noise-gate thresholds, the truncation ratio band, watchdog debounce and strike timings, grace-window length. Every one of these was arrived at by breaking a real interview and fixing it; the reasoning is above, the values are not.
The scoring rubric and evaluation schema. How an interview becomes a number is the hardest part of this product and the least commoditised.
Our absolute per-interview cost and margin. The modelled arithmetic is here so the shape of the curve is reproducible. Our actual figures are not a customer's business.
Question generation and topic derivation. How a job description becomes the right six questions, and how the required-topic gate is derived, are not described.
