Blog

Live calls punish hesitation. You can have the right idea, the right wording, and the right instinct, and still sound weaker than you are if the answer arrives a beat too late. We optimize for time to first answer token before almost everything else because that first beat decides whether the assistant feels like calm support or dead weight. In practice, the experience of using a meeting assistant is shaped less by benchmark theater and more by whether the first useful sentence lands quickly enough to keep your own thinking rhythm intact when the room gets tense.

ViewFraming Auto stays at the top of our stack for that reason. It is the fastest path we have ever shipped - answers routinely land under 1.5 seconds, and in live sessions it most often feels ready to move at conversation speed, not demo speed. That difference matters when every pause sounds louder than it should. Gemini Flash 3.1 Lite stays close behind because it is still quick, scales well, and gives a very strong option when you bring your own key and want speed with a familiar ecosystem behind it. The difference is not that Gemini is weak. The difference is that ViewFraming Auto more often feels like the sharper tool when the cost of even a small delay is your own confidence.

ViewFraming Auto is not a single model with a fast name. It is a composite stack - we route across several of the fastest available models in parallel, applying caching and request-routing logic that selects the path most likely to respond first for the shape of question you just asked. A single fast model like Gemini Flash 3.1 Lite can only ever be as fast as that model's best case on that particular request. ViewFraming Auto's latency ceiling is lower because the routing layer picks the winner across multiple fast options in real time, and response caching means repeated context patterns do not add inference overhead on top of each other. That is why under 1.5 seconds is a ceiling for ViewFraming Auto, not a starting point.

The table below is the cleanest version of that opinion. It is not meant to pretend these models live in a sterile benchmark lab. It is meant to reflect what matters in a real live-call loop: how quickly the first answer appears, whether the stream keeps up, and whether the price feels justified once real pressure enters the conversation.

Because vendors publish different official speed metrics, this table uses the concrete numbers each company actually discloses instead of inventing a fake apples-to-apples benchmark. What matters to us is still the same question: which stack keeps the answer moving when the call is live.

Once the model decision is clear, the audio stack becomes the next bottleneck. The same composite principle that makes ViewFraming Auto fast for answer generation applies here too. Rather than routing everything through a single cloud STT provider, ViewFraming Auto Audio combines local on-device recognition with cloud providers, selecting the fastest available path per session. When the device can handle it locally, latency effectively disappears. When cloud gives better accuracy for the language or accent in the room, it routes there instead. No single provider can win that tradeoff on its own because each one only covers half of it.

Apple Speech is still worth keeping as a fallback. The local path is attractive and the privacy story is clean, but the dedicated cloud stacks feel stronger when meeting pressure exposes every weak transcription choice. ViewFraming Auto Audio already folds local inference into its routing, so if you are on a managed plan you get the best of both without configuring anything.

For people who do not want to manage keys, we run managed models on our side, but we try very hard to earn that convenience. The routing has been heavily tested, the prompt and timeout behavior have gone through repeated iteration, and we spend deep engineering work on the unglamorous details that make the product feel reliable instead of lucky. We care about answer quality, stability, and recovery behavior just as much as raw model speed, which is why we are comfortable offering higher rate limits while still keeping a generous per-session token budget in place. If that tradeoff matters to you, the privacy note and legal page are the right places to read the boundary clearly: requests go directly to your provider when you bring your own key, and managed setups carry their own privacy tradeoffs.

There are two ways to look at token usage in a session. The budget token is the hard ceiling you configure - the maximum number of tokens a single session is allowed to consume before the assistant stops. The costing token is just that same number expressed from the other side: what the provider actually charges you for. Same count, two different lenses. Setting a budget token limit means you already know your worst-case spend before the session starts.

We enforce a session cap on managed plans for two reasons. The first is predictability. A deep technical session with long transcript context can accumulate tokens faster than it feels like in the room. Without a ceiling, costs drift in ways that are hard to reason about after the fact. The second is fairness. Managed infrastructure is shared, and an uncapped session that runs unusually long puts pressure on rate limits that other sessions depend on. The cap keeps the system stable for everyone.

The ceiling we set is generous. After running several hundred real sessions across both technical and behavioral tracks - short loops, long loops, candidates who talk a lot, candidates who keep things tight - 3 million tokens covers every realistic scenario comfortably. You are not going to hit the wall in a normal meeting. The cap is there to protect against runaway usage, not to interrupt you mid-session.

To make that concrete, here is what 3 million tokens translates to at current provider rates for the two models we recommend most. The estimate uses a realistic session split of roughly half input, half output - system prompts, transcript context, and prior answers on the input side; generated coaching and answer drafts on the output side.

Inside the app, the status bar at the bottom of the overlay panel shows two small pills during every session so you can see where you stand at a glance.

C is the costing token counter - it tracks usage on app-managed AI (ViewFraming). Y is your own token counter - it tracks usage when you bring your own provider key. Both show spent / limit in compact form (e.g. 0.5M/3M). When either pill turns red the session has hit its cap and responses pause.

If you bring your own API key, you set the token budget yourself in Settings → AI & Providers → Token Budget. The Token Limit field is the number that maps to the Y pill in the overlay - that number feeds directly into your provider spend, so the cost table above is your ceiling. The Warning Threshold slider turns the Y pill amber before you hit the hard cap, giving you a heads-up mid-session.

Free-tier keys from both providers have enough quota to run a lite session without touching paid credits. If you want higher rate limits and more headroom for back-to-back sessions, a pay-as-you-go key unlocks that, and the in-app budget limit keeps your monthly bill from drifting higher than you expect.

One important clarification: the token cap only applies to the live call overlay. Everything else - document review, follow-up drafting, pre-call prep, and post-call feedback - runs without a session cap. Those features are powered by the same fine-tuned models we have spent a lot of time optimising for quality, so use them as much as you need.

On managed plans we go further. The routing, prompt structure, and context-trimming logic have been through repeated iteration specifically to spend fewer tokens per useful answer. That means the effective cost per session is lower than the raw per-token rate suggests, rate limits are higher than what a standard free-tier key gets, and the whole thing stays behind the same 3M cap as a hard backstop. If you want to understand the privacy tradeoff that comes with managed routing versus your own key, the detail is in the legal page - the short version is that managed requests go through our infrastructure and your own-key requests go directly to your provider.

Reading about high-stakes conversations is not the same as practicing them. The gap between knowing an answer and delivering it clearly under observation is a performance gap, not a knowledge gap - and the only way to close it is through repeated simulation with feedback. ViewFraming practice mode is built around that loop: you answer questions out loud, the AI evaluates your response against a structured rubric, and the overlay surfaces targeted feedback immediately after each answer while the session is still fresh.

When you start a practice session you configure the role type and conversation format - technical, behavioral, or system design. ViewFraming asks you questions in sequence. Your microphone captures your spoken answer. The transcript updates in real time as you speak, and when you finish the AI evaluates your response and shows the structured breakdown in the overlay panel before the next question loads. The loop is designed to feel close to the actual live-call rhythm - because the stress response you are training down only responds to simulation, not to reading.

The overlay during a practice session looks different from the live assistance mode. Instead of streaming a suggested answer, it shows structured feedback on the answer you just gave - organized into the three layers the AI coaches you toward.

The answer structure ViewFraming coaches toward has three distinct layers, shown as separate zones in the overlay. The keyword appears as a chip at the top - the core concept or technique your answer should be anchored in. Naming it immediately gives the caller a model to attach the rest of your answer to, and signals that you know which domain you are operating in. The detail layer explains what the keyword means, how it works, and why it applies to the question. The example layer grounds it - a concrete instance from your own experience, or a scenario that demonstrates applied knowledge rather than theory.

An answer that leads with keyword, develops the detail, and closes with an example is structurally complete. The other person can follow it, probe it, and ask follow-up questions on any layer. Most weak answers are missing one layer - usually either the keyword (too vague to anchor) or the example (too abstract to be credible). The overlay shows you exactly which layer your answer was weak on and gives you the specific language you could have used instead, so the correction is actionable, not just a score.

The banner overlay is the notification that appears the moment ViewFraming finishes processing your spoken answer. It slides in over the current screen - visible only to you, excluded from screen recording the same way the answer panel is. It shows a compact version of the feedback: whether your answer hit all three layers, what the keyword should have been if yours was unclear, and a one-line note on the example. The banner clears on your next input so the feedback loop stays fast without interrupting your flow into the next question.

Progress tracking shows patterns across sessions, not scores per individual answer. After several sessions you start to see which question types you consistently nail the keyword layer on, which ones you over-index on detail at the expense of example, and which formats need the most targeted repetition. Technical questions tend to surface weak examples - people who know the concept well often cannot produce a specific concrete use case on demand. Behavioral questions tend to surface weak keywords - the answer has a good story, but it does not open with the competency it is demonstrating.

The most effective use of practice mode is targeted repetition on the format where your tracker shows a consistent gap. If behavioral questions always show a weak keyword layer, run three behavioral-only sessions focused explicitly on opening every answer with the competency label before telling the story. The framework stays the same across formats - keyword, detail, example - but the way each layer manifests shifts. Behavioral answers take a STAR-structured story as their example layer (Situation, Task, Action, Result). Technical answers take a specific project or implementation detail. System design takes a named trade-off or constraint you have actually reasoned through.

Once the framework is internalized through practice, the live overlay during a real live call changes function. You see the keyword chip appear and recognize the structure you would build yourself. The AI confirms the direction; you fill in the personal detail and example from your own experience. The overlay becomes a safety net for the moments when pressure collapses recall - not a script to read from. That is the point of the practice loop: to reach the state where you only need the net.