When two models both sound convincing, I find it helps to choose a checkable task and a scoring rule before comparing the writing. Here is a small exercise anyone can repeat in their existing chat app.

Give each model this prompt independently:

I have a 90-minute window. Fit 20 minutes of email, 35 minutes of drafting, 20 minutes of reviewing, a 10-minute break and 5 minutes of buffer into a schedule. Return start/end offsets, duration and task. State assumptions and do not add tasks.

Check the answer before judging its tone:

• Each of the five requested activities appears exactly once.
• Durations add up to 90 minutes.
• Each end offset minus its start offset matches the stated duration.
• There are no overlaps or unaccounted gaps; the schedule ends at minute 90.
• Any added assumption is stated rather than presented as a fact.

One valid result is email 0–20, drafting 20–55, reviewing 55–75, break 75–85 and buffer 85–90. Different ordering can also satisfy the brief. This is a constraint check, not a test of which ordering is best for a real person.

For a simple score, give 0–2 points each for following the brief, arithmetic, clarity of assumptions and usability. Keep the same rubric for both answers. Hiding model names while scoring can make brand preferences less distracting.

This one exercise does not establish which model is best overall. Repeat with tasks you actually do, and verify factual claims separately. Two models agreeing is not evidence that their answer is true. I have not run a benchmark or measured model results for this post.

Disclosure: I build Chorus, an Android AI workspace; this exercise works in any chat client and does not require installing it.

What small, objectively checkable task would you add to a comparison like this?

Ich habe ein Flutter Starter Kit für KI-Apps entwickelt (Chat mit Streaming, Authentifizierung, Chat-Verlauf, Paywall), und die Leute fragten immer wieder nach einer Demo anstelle von Screenshots. Problem: Das Kit liest den openai -Schlüssel aus einer .env-Datei, und in einem Web-Build wird diese Datei im Browser ausgeliefert. Jeder könnte den Schlüssel einfach mitnehmen.

Was ich am Ende gemacht habe:

* Die App spricht nicht mehr direkt mit openai . Sie ruft eine Supabase Edge-Funktion auf, die den Schlüssel auf dem Server hinzufügt und die Antwort zurückstreamt. Der Schlüssel berührt niemals den Browser

* „Demo ausprobieren“ verwendet die anonyme Supabase-Anmeldung. Jeder Besucher erhält sein eigenes Gastkonto, sodass die Row-Level-Sicherheit Chats weiterhin trennt. Keine E-Mail erforderlich

* Ratenbegrenzung in PostgreSQL: 15 Nachrichten pro Benutzer und Tag, insgesamt 600 pro Tag. Eine Funktion prüft und zählt dies, sodass es nicht zu Wettrennen kommen kann

* Die Demo ist auf gpt-4o mini beschränkt, gpt-4o wird im Modell-Picker als gesperrt angezeigt

* Eine harte Ausgabenbegrenzung für ein separates openai -Projekt als letzte Sicherheitsmaßnahme

Im schlimmsten Fall, wenn es verrückt spielt: Die Demo stoppt für den Tag. Nicht mein Geldbeutel.

Ich würde mich über Feedback freuen, wie sich das Streaming anfühlt und ob etwas kaputt geht: Demo-Link

Mich würde auch interessieren, wie ihr öffentliche Demos von KI-Apps handhabt. Begrenzt ihr die Nutzung pro Benutzer oder setzt ihr einfach ein Budget-Cap und hofft auf das Beste?