Don’t Blame the Model

2026-04-22 · Source: AI & ML – Radar · Field: Technology & Digital — Artificial Intelligence & Machine Learning, Software Development & Engineering · Depth: Intermediate, long

Summary

The reliability issues commonly attributed to Large Language Models (LLMs) often stem not from the models themselves, but from the artificial limitations imposed by API endpoints and surrounding tooling. Model providers, including OpenAI, Google, and Anthropic, restrict developer control by hiding crucial information like full chain-of-thought and log probabilities, and by not exposing advanced features such as constrained decoding and prefilling. These limitations, often driven by architectural and policy decisions like maintaining a chat-centric interface or guarding against model distillation, hinder developers' ability to steer results, ensure format adherence, and diagnose failures. This impacts the development of reliable LLM applications, especially in high-stakes domains like medicine or law, despite these features being inherently available in open-weight models.

Key takeaway

For AI Architects and NLP Engineers building high-stakes applications, recognize that current LLM API limitations, not just model capabilities, are often the root cause of reliability challenges. Your teams should advocate for or seek out model providers offering more advanced API features like full logprobs, complete reasoning traces, and flexible constrained decoding. This will enable greater control over model output, improve diagnostic capabilities, and ultimately enhance system reliability and safety.

Key insights

LLM reliability issues often stem from API limitations, not inherent model flaws, restricting developer control and visibility.

Principles

• API design dictates developer control.
• Visibility improves model diagnosis.
• Control enhances output reliability.

Method

Model providers should enhance APIs by providing full reasoning traces, top 20 logprobs, extended constrained decoding (e.g., regex, formal grammars), and full control over assistant output like prefilling and branching.

In practice

• Use open-weight models for full control.
• Demand more transparent APIs from providers.
• Implement external safeguards against prefill attacks.

Topics

• LLM Reliability
• API Limitations
• Constrained Decoding
• Log Probabilities
• Chain-of-Thought Reasoning

Code references

• guidance-ai/guidance
• dottxt-ai/outlines

Best for: AI Architect, NLP Engineer, CTO, AI Engineer, Machine Learning Engineer, MLOps Engineer

Related on AIssential

• AI Agents Don't Fail Because of the LLM. They Fail Because of the System Around It. — AI agent failures are primarily due to system design, not LLM limitations.
• Is Capability a Liability? More Capable Language Models Make Worse Forecasts When It Matters Most — More capable LLMs make worse forecasts for superlinear growth and tail risk, especially in the upper tail.
• Evaluating LLMs' Effectiveness on Real-World Consumer Device Repair Questions — LLMs provide useful repair assistance but are unreliable for high-risk real-world tasks without rigorous evaluation and explicit safety safeguards.
• Trust Me. I’m Artificial Intelligence. — AI models are becoming more convincing in their reasoning, but this does not equate to increased truthfulness or correctness.
• Finding the Optimal Reasoning Budget for LLMs — Optimal LLM reasoning length varies by model, while context compression and reasoning failures are critical research areas.
• 7 AI Integration Mistakes That Quietly Break Applications — AI application failures often stem from poor integration, not model quality, becoming apparent only at scale.

Open in AIssential →

Editorial summary, takeaway, and curation by AIssential. Original article published by AI & ML – Radar.