Microsoft Foundry Adds Command A+, Chandra OCR 2, and GLM-OCR: A Cloud Strategy Read on the New Open-Model Deployment Path

Microsoft added three Hugging Face models to its Foundry catalog this week, and while the announcement reads like a routine model drop, the strategic signal underneath it matters more than the individual checkpoints. The provider battle is no longer about who trains the most capable frontier model in-house. It is about who can take an open-weight model off Hugging Face and turn it into secure, billable, scalable inference with the fewest steps. Microsoft is betting that the deployment path itself is the product.

What changed

Three models landed in Microsoft Foundry through its Hugging Face integration: Cohere Labs' Command A+ in a W4A4 quantized build, Datalab's Chandra OCR 2, and Z.ai's GLM-OCR. They cover two distinct workloads that enterprises actually pay for: agentic reasoning and document understanding.

The mechanical change is that you can now browse the Hugging Face collection inside the Foundry model catalog, or click "Deploy on Microsoft Foundry" from the Hugging Face website and land in Foundry with inference already configured. That second path is the interesting one. It collapses the usual gap between discovering a model and standing up a production endpoint with networking, scaling, and access controls in place. Anyone who has manually containerized a vision-language model and wrestled with GPU scheduling knows that gap is where weeks disappear.

For a cloud consultant, the headline is not the models. It is that Microsoft is positioning Foundry as the managed runway for the open ecosystem, the same way AWS Bedrock and Google Vertex AI Model Garden are positioning themselves. The differentiation is moving down the stack into deployment ergonomics and per-token economics.

The three models, and why each one is a different bet

Command A+ (W4A4): reasoning that fits on less hardware

Cohere Labs' Command A+ is a 218B-parameter Sparse Mixture-of-Experts model with 25B active parameters per token, a 128K input context, and 64K output. On paper that is a heavy model. The W4A4 quantization is the entire point: 4-bit weights and 4-bit activations push a model of this class onto a single accelerator that would otherwise demand a multi-GPU node.

The technical subtlety here is worth understanding before you commit budget. Reasoning models are unusually fragile under quantization because errors compound across long decoding sequences. A small rounding error early in a chain-of-thought trace can cascade into a wrong final answer. Cohere's mitigation is to post-train the quantized student model against the full-precision teacher's output distribution, using fake quantization in the forward pass and straight-through estimators on the backward pass. In plain terms, they teach the compressed model to imitate the uncompressed one rather than simply rounding the weights and hoping for the best. This is why the W4A4 build can claim a usable speed-to-quality balance where a naive 4-bit conversion would degrade badly.

The model also expands language coverage from 23 to 48 languages and adds vision input, with stated gains in document understanding, math reasoning, and enterprise QA. The deployment pitch is straightforward: agentic and multilingual workloads that previously required a multi-accelerator footprint may now run on a single instance, which directly changes the hourly cost of keeping an endpoint warm.

Chandra OCR 2: accuracy-first document conversion

Datalab's Chandra OCR 2 is a 5.3B vision-language model that converts images and PDFs into Markdown, HTML, and JSON while preserving layout. It posts 85.9% on the olmOCR benchmark and 77.8% on a multilingual benchmark, a 12% jump over the first version, with coverage across roughly 90 languages including Indic scripts and right-to-left writing systems.

The practical value is in what it removes from your pipeline. Chandra OCR 2 handles multi-level tables, nested structures, forms, math, and mixed handwriting, emitting structured output with bounding boxes. That eliminates the post-OCR layout reconstruction step that usually sits between raw text extraction and anything you can actually query. For a compliance intake workflow, say a state election commission processing scanned candidate filings with checkboxes, signatures, and handwritten fields, the model can extract printed and handwritten content, identify form structure, and return consistent JSON that feeds directly into validation logic.

This is the accuracy end of the OCR spectrum. At 5.3B parameters it is not the cheapest thing to serve, but it is aimed at documents where getting the structure wrong has downstream consequences.

GLM-OCR: throughput-first document parsing

Z.ai's GLM-OCR takes the opposite position. At 0.9B parameters it is roughly six times smaller than Chandra OCR 2, built on the GLM-V encoder-decoder architecture. It scores 94.62 on OmniDocBench V1.5 and ranks first on that benchmark while serving at high concurrency. It covers Chinese, English, French, Spanish, Russian, German, Japanese, and Korean, and uses Multi-Token Prediction and full-task reinforcement learning to keep accuracy stable across document types.

The deployment story is cost and throughput. A sub-1B model has a small enough footprint that you can run dense batches cheaply, which is exactly what a high-volume customer onboarding platform needs when it processes identity documents, invoices, and proof-of-income statements at scale. You trade some of Chandra's layout depth and language breadth for the ability to push far more pages per dollar.

Provider comparison: how to read the choice

The two OCR models are not competitors so much as two points on a curve, and choosing between them is a classic accuracy-versus-throughput decision.

Dimension	Chandra OCR 2	GLM-OCR
Parameters	5.3B	0.9B
Benchmark	85.9% olmOCR	94.62 OmniDocBench V1.5
Languages	~90	8
Best fit	Complex layouts, handwriting, compliance	High-volume structured ingestion
Cost profile	Higher per page, fewer fallbacks	Lower per page, scales wide

The benchmark numbers are not directly comparable because they measure against different test sets, so resist the temptation to read 94.62 as "better than" 85.9. They answer different questions. Chandra is graded on messy, multilingual, handwritten reality. GLM-OCR is graded on structured document parsing where its compact architecture is tuned to win.

The practical pattern for a document pipeline is to route by difficulty. Send clean, high-volume, single-language documents to GLM-OCR and reserve Chandra OCR 2 for the filings that include handwriting, exotic scripts, or nested tables where a reconstruction error is expensive. That tiered routing is where the cost savings actually materialize, rather than picking one model for everything.

Against the broader provider field, the comparison is less about these specific models and more about the catalog. AWS Bedrock leans on its Marketplace and a curated set of partner models with managed throughput provisioning. Google Vertex AI Model Garden offers a deep open-model selection with tight coupling to its own TPU economics. Microsoft's play with the direct Hugging Face handoff is to minimize the friction of the discovery-to-deployment transition, which is genuinely the slowest part of standing up open models on any cloud. If your team's pain is operational rather than model selection, that path has real weight.

Business impact and migration considerations

The economic argument behind all three models is the same: smaller serving footprints. The W4A4 Command A+ build can collapse a multi-accelerator reasoning deployment to a single instance, and both OCR models are small enough to serve cheaply. Each reduction in active hardware is a direct line item, because inference endpoints bill on the compute you keep running, not on the cleverness of the quantization.

For teams already on Azure, the migration cost of adopting these models is low. The Foundry deployment is configured with secure, scalable inference on arrival, so the integration work is mostly downstream wiring rather than infrastructure plumbing. For teams on AWS or Google weighing a move, the calculus is harder and the honest answer is that you should not migrate a workload to chase a single model. The lock-in concern is real: once your document pipeline depends on Foundry's deployment surface, monitoring, and access model, moving it elsewhere means rebuilding that integration layer, even though the underlying weights are open and portable.

The sensible posture is to treat the open weights as the portable asset and the managed runtime as the convenience you are renting. Validate the W4A4 quantization against your own reasoning traces before trusting it in production, because benchmark scores do not guarantee that the specific kind of multi-step reasoning your application relies on survives 4-bit activation compression. Test the OCR models on your actual document mix rather than the benchmark corpus, since real intake forms rarely look like the clean test sets. Cohere offers a Hugging Face Space to trial Command A+ prompts before you deploy, which is the right place to do that validation without paying for an endpoint.

The larger takeaway for cloud strategy is that the open-model ecosystem and the hyperscaler managed-inference business are converging into the same workflow. Microsoft is making the bet that the team which removes the most friction between a model card and a production endpoint earns the inference spend, regardless of who trained the model. For organizations planning their next 18 months of AI infrastructure, the question is shifting away from which provider has the best proprietary model and toward which provider makes the open ecosystem cheapest and least painful to operate. You can read more in the Hugging Face on Azure documentation.