Fact-check AI answers with a model from another family.

Debate has two modes and picks one for you: it checks the facts on the web when the answer contains any; otherwise, a second AI rereads it without the web. In Fact check mode, the app extracts the claims in the answer, looks them up on the web, labels each one and cites clickable sources in the final version; it never invents a source. In Review mode, a model from another family reads the answer and criticizes it without browsing the web. Fact check starts when the answer contains verifiable facts (figures, dates) on a factual question, or when it says it cannot confirm something; code and opinion questions go to Review. You can also choose the mode yourself.

We measured Review on 20 questions that cannot be verified. Before our iteration, the final version invented a fact in 10 of the 20; afterward, in 1 of the 20, with no invented source. One in 20 is not none: that’s why Fact check goes to the web as soon as the answer has facts to verify, and why it is worth opening the sources.

Viewpoints is a premium tab for topics that divide people. Two advocates from different families each argue one position with their own web sources, then a synthesis brings them together. It costs about 21 credits per topic on average and is for subscribers. Compared with a balanced answer from a single model, a judge preferred Viewpoints in 83 to 90% of the cases we measured (6 then 15 topics), and on the 4 traps where the facts are settled, they were presented as settled 4 times out of 4.

A model that rereads its own answer fixes nothing more: we measured it. Same bugs, same mistakes, and the judge preferred the reread version in only 15% of the open tasks. A model that missed something the first time tends to miss it again, probably because the gap comes from how it was trained, not from haste.

A critic from the same family did no better, and sometimes worse. Asked to review a DeepSeek answer, a DeepSeek critic raised more points, raised more false alarms, and the corrected code ended with 46 seeded bugs fixed out of 49, versus 47 for the answer alone. It also missed a reversed riddle that the answer had fallen for: models of one family share their blind spots.

A critic from another family saw that riddle, recounted a counting question the answer had gotten wrong (155 instead of 153), and found the last two bugs in the code. That is why the app never lets a model review its own family: the critic is chosen on our server, and the browser only sends the depth you picked.

A reviewer that approves everything is worthless, and one that invents problems to look thorough is worse. The critic therefore works under strict rules: quote the exact line or claim, explain why it is wrong with evidence (a counter-example, a computation, the requirement it breaks), propose the fix, and ignore style. If, after a real check, it finds nothing serious, it says so and states what it verified.

In the study, the critic from another family raised about two points per review. On the code, 17 of the 19 points that named a function pointed to a real seeded bug. In a third of the cases it said there was nothing serious to report; the answer then stays as it was and the final step is skipped.

The author does not obey blindly either. It is told to accept a point only once it has verified it, and to explain each rejection. In 15 of the 20 final versions, at least one point was set aside with a reason. You see both lists under the final version: what changed, and the points set aside.

We also measured a longer exchange: two models taking turns for two or three rounds, each answering the other point by point, then a synthesis. It did no better than the single review on code, got one more question wrong, was preferred by the judge in only half of the open tasks, cost three times as much and took two to three times longer.

So the app does one round, done well: a draft, a critic from another family, a corrected final version. When the critic finds nothing, the exchange stops there, which happened in a third of the test cases.

The classic advice still holds. Ask for sources and open them. Redo a calculation yourself. Run code before trusting it, ideally with a test that covers the edge cases: empty lists, dates around a birthday, numbers that are not numbers. Rephrase the question to see if the answer holds. And ask a different model, because two models from different families rarely make the same mistake.

Debate automates the last step and keeps a written trace of it. It is most useful where an error costs something: code you are about to ship, a calculation behind a decision, a summary of a contract, a plan with trade-offs, an important email. For a short exchange or a matter of taste, the answer alone is usually enough, and faster.

It does not replace your judgment. In Review mode the critic does not browse the web, and a point both models agree on can still be wrong. What it does is put a second, independent reading in front of you, with the reasons on the page.