Live numbers.

How these numbers are collected

Every figure above is read from the running production system at the moment this page was regenerated, which happens at most every ten minutes. Nothing is cached longer than that, nothing is entered by hand, and there is no editorial step between the database and the table. If a number looks bad on a given day, it is on this page that day.

Traffic

Page views come from a first-party analytics beacon we wrote and host ourselves — no Google Analytics, no third-party tag, no cross-site identifier. It records the page path, the referrer, the browser language and the screen size, and it does not set a tracking cookie. “Unique visitors” is therefore an approximation derived from coarse signals rather than a persistent identity, and it will undercount people who return on a different device and overcount anyone who clears state between visits.

The beacon is blocked by most ad blockers, which we have chosen not to work around. That means the real traffic figure is somewhat higher than the one shown. We would rather publish a number that is honestly low than defeat a reader’s privacy tooling to make a marketing chart look better.

“All time recorded” means since the beacon was deployed, not since the project started. Traffic before that point exists but was never measured, and we are not going to estimate it.

Answer reliability

The reliability figures come from the completion checker built into the response engine. After a model finishes streaming, the checker looks at the finish reason the provider returned and at the shape of the text itself — an answer that stops mid-sentence, mid-list or mid-code-block is treated as truncated even when the provider claims it completed normally, because providers frequently do.

• Responses observed — how many completed answers the checker has inspected. This is a rolling production sample, not the total number of messages ever sent.
• Completed successfully — the share that finished cleanly on the first attempt.
• Detected as truncated — the share the checker flagged as cut off. Note that this and the completion rate can sum to more than 100%: an answer that was truncated and then repaired counts in both, because it was both.
• Auto-continuation succeeded — of the truncated answers, the share the engine repaired automatically by asking the model to continue from where it stopped, then stitching the halves. This is why a user usually does not see a truncation even when one happened.

What these numbers do not tell you

Reliability is not quality. An answer can complete perfectly and still be wrong, and this page cannot tell the difference — the checker reads structure, not truth. Model quality is a separate measurement with a separate method, and it is published separately on the benchmark page rather than folded in here where it would look like the same kind of evidence.

The sample is also small. At a few hundred observed responses, a single bad hour from one provider moves the percentages visibly. Treat the direction as meaningful and the second decimal place as noise.

Why publish this at all

Because numbers that only appear once they are flattering are not evidence, and a reader can tell. Putting the traffic and reliability figures on the record while they are small is the thing that makes the same page worth citing when they are not. There is no “10,000+ users” on this site, and there will not be one.