gpt-6-luna on Azure OpenAI loses digits in scanned documents: image gets ~2.4x fewer input tokens than the same request on OpenAI API

Fcabla 0 Reputation points
2026-10-07T15:31:16.37+00:00

We run OCR on scanned invoices and contracts (A4, around 200 dpi) with gpt-6-luna through the Responses API. On Azure the model keeps dropping digits from 10-digit reference numbers. The exact same request against api.openai.com reads them fine. I have reproduced it on two unrelated Azure OpenAI resources, so I don't think it is a config problem on our side.

What we send

  • Responses API (/openai/v1/responses), one input_image, detail: high, reasoning effort low
  • Deployment gpt-6-luna. Azure answers with x-ms-served-model: gpt-6-luna-2026-09-22
  • Test image: a synthetic scanned invoice, 1654x2339 px PNG, 7 reference values to read. Two of them are Contrat n° 8010099123 · Bon de commande 7730009876, printed at a normal body font size
  • 3 calls per variant, same bytes and same prompt everywhere

Results

Endpoint Model Input tokens What it reads for the two references
OpenAI API gpt-6-luna 3,427 8010099123 and 7730009876, correct, 3 of 3 calls
OpenAI API gpt-5.4-mini 3,427 correct, 3 of 3
Azure, resource A (Spain Central) gpt-6-luna 1,433 801009123 and 773009876, a repeated digit dropped in each, 3 of 3
Azure, resource B (West Europe, brand new resource, other subscription) gpt-6-luna 1,433 same wrong values, 3 of 3
Azure gpt-5.4-mini 1,433 correct, 3 of 3

Things I tried on Azure with gpt-6-luna that did not help: detail: auto or no detail at all (5,071 tokens, and the output is character for character the same wrong 801009123 / 773009876), the PDF as input_file (3,464 tokens), chat completions instead of responses. 19 calls, 19 misses. Upscaling the image 2x changes nothing, Azure still counts 1,433 input tokens. The only thing that works is cutting the page in two and sending both halves as two input_image items (2,413 tokens, reads everything). That is not a real fix for a document pipeline.

Why I think it is the image encoding on Azure

  • Same bytes, Azure counts 1,433 image tokens and OpenAI counts 3,427. Azure is feeding the model roughly 2.4x less image.
  • On Azure detail: high gives fewer tokens than detail: auto, yet the model output is identical in both cases. On the OpenAI API high is the maximum.
  • OpenAI acknowledged an image-encoding bug in GPT-6 Sol and Luna and shipped a server-side fix on 2026-09-25, with no new model id: API changelog and the developer community thread. Azure serves version 2026-09-22, which predates that fix.

Questions

  1. Has the 2026-09-25 image-encoding fix for GPT-6 Sol/Luna been applied on Azure OpenAI?
  2. Does Azure use a different image preprocessing or tile budget for the GPT-6 family than the OpenAI API? Is there any way to get the full detail: high resolution on Azure?
  3. Is a newer gpt-6-luna model version planned?

I can share the apim-request-id of the failing calls privately if that helps.

Azure OpenAI in Foundry Models
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jerald Felix 18,760 Reputation points Volunteer Moderator
    2026-10-07T16:16:39.5+00:00

    Hello Fcabla,

    Greetings! Thanks for raising this question in the Q&A forum.

    Based on the testing you have already performed, this does not appear to be an issue with your prompt, image resolution, or the detail setting.

    The most significant indication is that the same image and prompt produce approximately 3,427 input tokens through the OpenAI API but only around 1,433 tokens through Azure OpenAI with gpt-6-luna. You have also reproduced the same behavior across two independent Azure OpenAI resources, while gpt-5.4-mini processes the same document correctly.

    Azure currently documents gpt-6-luna as version 2026-09-22

    The current Azure OpenAI documentation lists:

    gpt-6-luna (2026-09-22)

    Microsoft documentation also confirms that gpt-6-luna supports image input and both the Responses and Chat Completions APIs.

    There was an image encoding fix after this model release

    OpenAI documented an image-encoding issue affecting GPT-6 Sol and GPT-6 Luna and published a server-side fix on September 25, 2026.

    At present, I am not able to find public Microsoft documentation confirming that this September 25 image-encoding fix has also been rolled out to the Azure OpenAI serving path.

    Therefore, it would not be safe to assume that the behavior of the Azure-hosted 2026-09-22 deployment is currently identical to the OpenAI API for image preprocessing.

    The token difference is worth escalating

    Azure documentation states that detail: high should use a higher-resolution representation of the image and therefore consume more image tokens to capture finer details.

    Since your Azure requests consistently show substantially fewer input tokens and lose the same repeated digits, despite using detail: high, this is strong evidence that the issue should be investigated at the service/backend level.

    Open an Azure support request with the reproducible case

    I recommend opening an Azure support request under Azure OpenAI / Microsoft Foundry and providing:

    Azure OpenAI resource and region

    Deployment name

    x-ms-served-model: gpt-6-luna-2026-09-22

    apim-request-id from several failing requests

    Request timestamps in UTC

    Input token counts from Azure and OpenAI

    The synthetic test image

    Exact request payload

    Expected and actual extracted reference numbers

    Confirmation that the issue reproduces across Spain Central and West Europe

    This should allow the Azure OpenAI engineering team to confirm whether the September 25 image-encoding fix is present in Azure or whether there is a separate Azure-specific image preprocessing difference.

    Use the working model/workaround temporarily

    Until the Azure behavior is confirmed or corrected, using gpt-5.4-mini, which you have already verified works correctly, would be the safer option for production document extraction.

    Splitting the document into smaller image regions is also a valid temporary mitigation, but as you mentioned, it should not be necessary as the permanent solution for a document processing pipeline.

    Regarding a newer gpt-6-luna version, the currently published Azure documentation still lists 2026-09-22. I would not want to speculate on the release date of another Luna version until Microsoft publishes it in the model availability documentation.

    Your reproduction is detailed enough that I would recommend treating this as a possible Azure service parity/backend issue rather than continuing to tune the prompt.

    If this answer helps you kindly accept the answer which will help others who have similar questions.

    Best Regards,
    Jerald Felix.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.