Shipping “fast mode” AI that breaks more often is not a clever optimization. It’s a trust leak. And trust is the one thing these systems don’t get to lose twice.
A new Tencent paper is basically a warning label: when they switch a multimodal model into a “non-thinking” mode, responses come back faster, but the chance of user-visible failures goes up a lot. Not subtle failures that only a researcher notices. The kind that regular people see and think, “Wait, what?” The paper uses a benchmark called PatternEval with 2,415 prompts. And instead of grading the model only on whether it gets the “right answer,” it checks things like logical contradictions and performative reasoning — whether the model acts like it’s reasoning when it isn’t, or talks itself into nonsense.
That framing matters. Because the whole industry has been grading itself on the easiest test: did it say the fact that matches the answer key. Real life isn’t an answer key. Real life is whether the model holds together under pressure when the user’s request is messy, emotional, ambiguous, or mixed with images and context.
The uncomfortable truth is that “non-thinking mode” is exactly what a lot of product teams want. Not because they’re evil, but because latency is a tax you feel in your bones. When a chatbot pauses, users bounce. When an assistant lags while you’re on a call, you swear at your laptop. Speed makes demos look magical.
But speed that raises visible failure rates is not a free win. It’s borrowing against the future. Every time the model contradicts itself, or confidently performs reasoning it didn’t actually do, you train the user to stop relying on it. And once people start double-checking you, you’re not an assistant anymore. You’re a fancy autocomplete that creates homework.
Imagine you’re a customer support lead and you flip on fast mode to handle more chats per hour. The replies come quicker. Your dashboard looks better. Then the model starts giving answers that sound authoritative but don’t match your own policies, or it contradicts itself two messages later. Now your agents have to jump in mid-thread, fix the confusion, and calm down angry customers. You didn’t save time. You moved the work to the most expensive part of the process: damage control.
Or say you’re a student using a multimodal tool to interpret a chart from a screenshot. In “thinking” mode, maybe it takes a bit longer but it stays consistent. In non-thinking mode, it responds instantly, but it mixes up labels or invents a relationship that isn’t there. The student doesn’t need the model to be slow. They need it to be stable. Fast wrong answers are worse than no answers because they look usable.
The more multimodal you get, the more dangerous this trade becomes. Text-only mistakes are often easy to spot. Mix in images and context, and people assume the model “saw” what they saw. When it fails, it feels like betrayal, not a bug.
I also like that this paper doesn’t just worship “correctness.” Logical contradiction and performative reasoning are exactly the kinds of failures that make people feel gaslit. You ask for help, it answers, you follow up, and it reverses itself with the same confidence. Or it writes a neat little chain of reasoning that looks like thinking but is really just decoration. That’s not just an accuracy issue. That’s a relationship issue.
Now, the pushback is obvious: plenty of users prefer fast responses and can tolerate some mistakes. For casual brainstorming, joke writing, or rough drafts, speed might matter more than reliability. And there’s a fair argument that you should let users choose: a fast lane and a careful lane.
But here’s where I’m opinionated: you can’t dump that choice on users without also owning the consequences. Most people won’t read mode labels. They’ll feel the system as one personality. If “fast” sometimes turns into “nonsense,” they won’t blame the mode. They’ll blame the product. And they’ll be right.
The paper hints at something else that should make teams nervous: if you’re going to deploy faster modes, you need specialized evaluation for them. That’s not glamorous work. It slows down shipping. But without it, you’re basically guessing how often you’ll embarrass yourself in public.
And it won’t fail evenly. The wins will go to teams chasing short-term engagement metrics — quick replies, more sessions, lower compute. The losses will land on users who don’t have the time or skill to audit every answer. It’ll also land on the humans behind the scenes who have to clean up when the model confidently walks off a cliff.
What I don’t know — and what I wish more people would be honest about — is whether “non-thinking” failures are predictable enough to contain. Maybe you can route only certain kinds of prompts into fast mode. Maybe you can detect when the model is about to contradict itself. Maybe the right fix is not “always think,” but “think only when it’s actually risky.” The paper suggests evaluation is key, but it doesn’t magically solve the product temptation to chase speed.
So here’s the real question I’m left with: if faster modes increase visible failures, should AI products be allowed to default to speed anyway, or should they be forced to default to reliability even if it costs engagement?