feat(azure-ai): support Cohere Parse OCR

[emerzon]

TLDR

Problem this solves:

• Azure Cohere Parse requests use the Mistral OCR route
• Cohere page pricing and model limits are missing

How it solves it:

• Adds Cohere routing, request, response, and usage transforms
• Adds exact model metadata and input validation

User Flow

Before: a developer cannot parse an image with an Azure Cohere Parse deployment

1. They configure azure_ai/Cohere-parse-v5 with an Azure endpoint
2. They send POST https://litellm-domain/v1/ocr with an image_url data URI
3. Azure receives a Mistral OCR request and the parse fails

After: the same developer receives normalized OCR pages and billed-page usage

1. They configure azure_ai/Cohere-parse-v5 with an Azure endpoint
2. They send POST https://litellm-domain/v1/ocr with an image_url data URI
3. The request returns 200 with pages and usage_info.pages_processed

Relevant issues

Linear ticket

Sources

• Azure model catalog
• Cohere Parse API
• Cohere Parse pricing
• Cohere on Azure

Validation notes

• France Central and West US Azure endpoints returned HTTP 200
• Direct requests used Bearer auth and exact model Cohere-parse-v5
• Both direct responses reported one page and one billed page
• A live LiteLLM gateway /v1/ocr request returned HTTP 200
• Native name parse-v5.0 returned DeploymentNotFound

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• The handful of test files covering my change pass locally, e.g. uv run pytest tests/test_litellm/<your_test_file>.py -v. Leave the suites (make test-unit-*, make test-unit) to CI: it finishes in ~15 minutes where a laptop takes an hour or more
• My PR passes all required CI/CD checks (e.g., lint, schema.d.ts sync check, etc.)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review)

Screenshots / Proof of Fix

The live requests used an image data URI because Parse currently accepts image input only

Before (4c51ca7)

1. This revision had no Cohere Parse dispatch, so no successful live gateway result was captured

After (10039d7)

1. POST https://<gateway>/v1/ocr used model cohere-parse-v5 and an image_url data URI
2. The gateway returned HTTP 200
3. POST https://<france-central-resource>/providers/cohere/v2/parse used Cohere-parse-v5
4. Azure returned HTTP 200 with one page and one billed page
5. POST https://<west-us-resource>.services.ai.azure.com/providers/cohere/v2/parse used the same payload
6. Azure returned HTTP 200 with one page and one billed page
7. Replacing the model with parse-v5.0 returned DeploymentNotFound

Type

New Feature
Test

Caveats (if any)

Medium

• Per-page pricing is provider-derived until Azure publishes its meter

Low

• The API currently accepts only image_url inputs
• document_url and PDF inputs fail before the provider call
• The retirement date comes from the live Azure catalog

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[devin-ai-integration]

PR #39427 labeled risk:medium (8 files, +510/-1; new azure_ai Cohere Parse OCR translation + model pricing entries — not isolated enough for low, no sensitive/broad area for high). No enterprise label, so Linear routing was skipped.

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing emerzon:litellm_azure_ai_cohere_parse (10039d7) with litellm_internal_staging (6c5fb0e)¹}

Footnotes

1. No successful run was found on litellm_internal_staging (bc2370f) during the generation of this report, so 6c5fb0e was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[codecov]

Codecov Report

❌ Patch coverage is 94.35484% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...m/llms/azure_ai/ocr/cohere_parse_transformation.py	93.85%	7 Missing ⚠️

📢 Thoughts on this report? Let us know!

[greptile-apps]

Greptile Summary

Adds Azure AI Cohere Parse OCR support, including model-aware adapter selection, provider request and response transforms, Python-path dispatch, model pricing metadata, and focused unit coverage

Confidence Score: 5/5

The PR appears safe to merge with no concrete correctness, security, or compatibility failures identified

The adapter selection, provider wire translation, response normalization, Rust-path exclusion, metadata, and tests form a consistent Cohere Parse integration

Important Files Changed

Filename	Overview
litellm/llms/azure_ai/ocr/cohere_parse_transformation.py	Implements Cohere Parse URL construction, input validation, request translation, and normalized page and usage responses
litellm/llms/azure_ai/ocr/common_utils.py	Selects the dedicated Cohere Parse adapter for the exact Azure catalog model
litellm/ocr/main.py	Bypasses the Mistral-only Rust OCR bridge for Cohere Parse requests
model_prices_and_context_window.json	Registers Cohere Parse OCR capabilities, limits, retirement date, and page pricing
tests/test_litellm/llms/azure_ai/test_cohere_parse_transformation.py	Covers routing, endpoint construction, authentication, validation, transformations, usage normalization, and metadata
tests/test_litellm/ocr/test_ocr_native_format.py	Verifies Cohere Parse requests remain on the compatible Python OCR path

_{Reviews (1): Last reviewed commit: "feat(azure_ai): add Cohere Parse OCR sup..." | Re-trigger Greptile}