GPT-6 Luna vs Qwen3.5 4B Fast for Call Extraction

A fast answer is useful only if it keeps the caller's final meaning. When a caller changes a guest count, withdraws a request or says a number is unconfirmed, the extraction model must preserve that distinction. A tidy object with the wrong value creates more work than a slower answer that correctly flags uncertainty.

AssemblyAI published Voice Standard Bench on October 13, 2026 to compare LLM work on transcripts. This October 14 review uses that new evidence to examine GPT-6 Luna and its hosted Qwen3.5 4B Fast option for information extraction. It is a post-transcription decision, not a comparison of speech-recognition or speech-synthesis quality. Dated benchmark launch.

The exact Gateway request identifiers are gpt-6-luna and qwen3.5-4b-32k-fast. The latter describes a particular hosted offering, not every deployment of the underlying Qwen family. Current Gateway catalog.

Burki exposes GPT-6 Luna as a conversational model, but does not currently expose this Qwen Fast Gateway model as a native choice. Choosing the assistant's conversation model does not automatically replace Burki's post-call extraction processor. The benchmark is an external reference, not evidence of a Burki model run or a completed integration.

Download the free call-extraction worksheet. It includes a fictional corrected-details example, an adaptable output contract and blank review results. No paid evaluation, model request or production call was performed for this article.

Start with a bounded extraction task

For a fictional public event help desk, the task is to record an attendance enquiry for staff review. The caller's preferred date and guest count are useful fields. Availability and a confirmed reservation are separate facts that a transcript cannot invent.

Use this short, original example:

Caller: I'd like to ask about the Friday evening talk for four people.
Assistant: You are asking about Friday evening for four guests?
Caller: Sorry, three guests. Friday is a preference, not a confirmed booking.
Assistant: Should staff follow up about the request?
Caller: Yes, but I haven't given you a callback number yet.

A useful extraction retains three guests, Friday as a preference, a requested staff follow-up and an unknown callback number. It must not create a reservation, reuse four as the active count or invent contact details. These are task requirements, rather than predictions about either model's response.

Give the reviewer fields that distinguish content from status:

Preserve the transcript separately. An extraction is a derived interpretation with a review date and prompt version. If a staff member corrects it later, keep that correction's provenance rather than overwrite the original conversation record.

Read the task scores without turning them into accuracy percentages

The pinned canonical benchmark version 0-1-3 was generated October 12 at 17:33:20 UTC and read for this review on October 14. Its default-effort information-extraction scores are:

These are normalized quality scores, with higher values better, not percentages of correctly extracted records. The generation timestamp is not each model's run date. Pinned original result data.

AssemblyAI's vendor-authored methodology uses ten transcripts per judged task and duration bucket, with Opus 5.5 and GPT-5.6 Sol judge tracks. Extraction is assessed for grounding and completeness. This is not an independent study, and the language distribution and exact served revisions are not established here. Do not treat a score gap as a guarantee about your callers. Benchmark methodology.

The practical question is where your task stops being a short message and becomes a conversation containing several corrections or unresolved facts. Evaluate that boundary explicitly. A model that meets your acceptance rule on a concise enquiry may need a different prompt, a stronger validator or another model for longer calls. Length alone does not identify difficulty, so include both short ambiguous cases and longer straightforward ones.

Separate completion time, first token and accepted output

The repository distinguishes the normal completion pass from a streaming first-token pass. The published summary's latency columns aggregate tasks within a duration bucket, so they cannot be relabeled as extraction-specific timing. Its canonical result set can accumulate separate runs. Benchmark implementation and reporting.

For your application, measure the interval that matters. A first token can arrive quickly while the rest of the object is incomplete. A fully generated object may still fail parsing, omit a required uncertainty marker or contain a stale count. Record when a complete, validated result becomes available to the reviewer.

Keep four observations separate: first token, completed response, structurally valid output and task-accepted output. This prevents a speed improvement being credited for a response the business cannot use. Include timeouts, refusals and invalid outputs in the review rather than calculate a fast average over successes alone.

The diagram illustrates the proposed review contract. It contains no generated model response or executed booking.

Use the exact endpoint and model contract you intend to deploy

In AssemblyAI's catalog, request IDs omit the maker prefix shown in the model listing. The catalog advertises streaming for Qwen Fast, but does not mark the same JSON capability offered for Luna. Treat a requested JSON shape and a schema-constrained provider feature as different things, and validate the output your actual endpoint returns. Gateway model and capability contract.

OpenAI's current model page identifies gpt-6-luna as a reasoning model with text/image input and text output. Its reasoning settings include none through max, with medium as the documented default. It is not itself a voice-output model. Current Luna contract.

Luna's API family was released September 22. The October 6 Decisions API addition is a separate endpoint development; the Gateway benchmark is not a test of that endpoint. Do not apply a Decisions speed claim to these completion results. Official dated API changes.

Before implementation, record the actual model identifier, endpoint, service tier, region, effort and output mode. Keep them with the prompt revision. A result from a hosted default-effort model cannot be copied into a report about a different provider route or native none configuration simply because both display the word Luna.

Build a prompt that can retain missing and corrected facts

The worksheet's starter instruction is intentionally narrow:

Extract only the final facts supported by this transcript. Apply explicit corrections to the active values. Leave absent facts null. Keep requested, confirmed and completed states separate. Include short evidence for each value and unresolved ambiguity for staff review. Do not create a reservation, contact detail or action result.

Adapt the fields to the business task before using the template. For the event enquiry, guest_count can be an integer or null, while preferred_session can be a string or null. A booking reference should remain absent unless the available records support one. Do not force every field into a nonempty string just to obtain a prettier table.

Ask for evidence spans that a human can check, but do not treat a model-provided quote as automatically authentic. Compare it to the preserved transcript. For example, evidence for three guests should reference the correction, while evidence for an unknown callback number should explain the absence or relevant statement. Neither is permission to call an invented number.

Apply a structural validator before a result reaches downstream systems. Then review critical values against the task rules. Schema validity can verify that a count is an integer; it cannot establish that three is the right count or that staff actually confirmed availability. The worksheet provides separate fields for those checks.

Compare on the same permitted transcript set

Prepare an authorized, minimized or synthetic set and send the same transcript with the same task prompt to each candidate only when an evaluation is separately authorized. This guide leaves the evaluation unperformed. Keep any private caller material out of the public worksheet.

Include explicit corrections, withdrawn requests, missing contact details, conflicting dates and an attempted instruction embedded in a caller's words. Treat the transcript as data to be analyzed, rather than let an embedded “ignore the rules” phrase change the extraction task. Add the languages and domain vocabulary you actually support, with appropriate review; these English examples do not establish multilingual accuracy.

For every sample, score whether the final values and their states are correct. Record missing output and invalid formatting alongside unsupported claims. Make a wrong confirmed reservation a failure even if the rest of the object is excellent. The business impact of that error should not disappear inside an average judge score.

Use the smallest task-specific acceptance rule that captures the risk: correct count, correct date status, no invented callback number, authentic evidence and no unperformed action claim. Then compare completion delay and billable usage among results that satisfy it. Keep failures in the total cost and reliability denominator.

Compare token prices with actual usage

On October 14, AssemblyAI's global Gateway catalog lists both models at USD 0.10 per million input tokens and USD 0.50 per million output tokens. Cache tiers and regional pricing differ. Identical base rates do not imply identical output usage or task cost. Dated Gateway rate card.

OpenAI's Standard short-context Luna pricing matches those base input/output rates, with separate cache charges, processing tiers and higher long-context rates. Apply the price for the actual request configuration, rather than use a headline rate for every endpoint. Official OpenAI pricing.

An illustrative uncached request with 4,000 billable input tokens and 400 billable output tokens would calculate to USD 0.0006 at those base rates. This is arithmetic from assumed usage, not a measured transcript, provider invoice or full call cost. Retries, validation failures and extra model work affect the real result.

The dynamic benchmark site's cost-per-audio-hour figures differ from the pinned raw summary used here. This guide therefore does not combine them into a numeric cost winner. Record current provider rates and observed billable tokens for your own accepted task instead. Recognition, synthesized speech, platform and telephone usage are additional costs.

Inspect the relevant Burki controls without promising a post-call switch

In Burki, open Voice → Model and provider choices, then choose Standard pipeline · advanced provider choices under Conversation engine. Inspect Default AI stack → AI provider → AI model. GPT-6 Luna is an available OpenAI conversational choice; this Qwen Fast Gateway offering is not a verified native option.

Burki's current live adapter routes GPT-6 models through Responses and defaults Luna's reasoning effort to none. That differs from the benchmark's hosted default effort. More importantly, conversation-model selection is separate from the existing post-call summary and structured-data processor. The current code does not establish a native Luna/Qwen post-call comparison switch.

Review the existing call's available summary, captured information and actions through Test Calls → Call history. Use the call summary guide for that product workflow. If exploring a separate processor, define its data access, endpoint, validation and result ownership before sending any transcript; the worksheet is a planning resource rather than an integration.

For an AI receptionist, the valuable result is a correct, reviewable request with its uncertainty intact. This comparison helps choose and evaluate a model for that specific derived record. It does not turn benchmark scores, a conversation setting or extracted text into a completed business action.