splitscreen started because a friend and I were both using ChatGPT on the same project in separate tabs and kept redoing each other’s work. Three models in one thread is the same idea taken further. The transcript below is one database question put to Claude and then to GPT inside a single chat, with Gemini sent after them to read what is currently recommended, and none of the three answers agrees with the others.
That is the normal case rather than a failure. The first two look at the same index and reach opposite conclusions about whether a second one is needed. The third comes back arguing for a different kind of index altogether, which neither of them had mentioned. When the answers sit under each other in one thread you can see the disagreement while it is still cheap, instead of finding it a week later in a migration.
Each reply carries its own price, because each one ran on a different rate card. One billed to Nadia’s own Anthropic key at what Anthropic charges her. The other two ran on splitscreen credits and cost more, and the receipt under each says which it was.
Nadia owns this room. She holds one Anthropic key and a credit balance, and she asked the same question three times.
A curated transcript, written by us to show what the product does - not a recording of a session, not a live room, and not real people. The prices are the ordinary rates on what each AI can do.
| after | Nadia’s Anthropic budget | Nadia’s credit balance |
|---|---|---|
| Nadia opens the room | $2.0000 | $5.0000 |
| Nadia asks Claude | $1.9935 | $5.0000 |
| Nadia asks GPT | $1.9935 | $4.9887 |
| Nadia asks Gemini | $1.9935 | $4.9663 |
Claude - `orders` has a btree index on (customer_id, created_at) and this report query filters on created_at alone over about 40 million rows. It is doing a sequential scan. Should we add a second index on created_at, or is something else wrong? Same question is going to GPT and Gemini after this.
Your existing index cannot serve that query, and adding a second one may not fix the scan.
A btree index is ordered by its leading column first. A predicate on created_at alone cannot use (customer_id, created_at) as a range scan, because the rows for any one date are scattered across every customer prefix in the tree. So the planner is right that this index is no help here.
The part I would check before writing the migration is what fraction of the table the filter actually matches. If the report is asking for a quarter of 40 million rows, a sequential scan is the cheaper plan and an index on created_at will be built, maintained on every insert, and then ignored. Run the query under EXPLAIN (ANALYZE, BUFFERS) and look at the row estimate against the real count first.
If the filter really is narrow and the estimate is wrong, the problem is statistics rather than indexes.
$0.0065 · billed to Nadia's Anthropic key
GPT - same question, and I want your own read rather than a note on what Claude said.
Add the index. A dedicated btree on created_at is the ordinary fix for a date-ranged report on a large table, and the composite you have is not a substitute for it.
Two things I would do in the same change. Run ANALYZE orders before you measure anything, because a stale row estimate on a table that size will send the planner to a sequential scan whatever indexes exist. Then create the index concurrently so the write path is not blocked while it builds.
On maintenance cost: an extra index on an append-only timestamp is close to the cheapest index a table can carry, because new values sort to the right-hand edge of the tree and the pages you touch on insert stay hot. That is a different trade from adding an index on a column that gets updated in place.
$0.0113 · paid from Nadia's credits
Gemini - you two disagree about whether to add it at all. Go and read what is currently recommended for time-ranged scans on an append-only table and tell me if there is an option neither of you has mentioned.
searched the web (1)
postgres brin index append only timestamp range scan
There is a third option, and on an append-only table it is the one worth measuring: a BRIN index on created_at.
BRIN stores a summary per block range rather than an entry per row, so it is tiny and cheap to maintain. It only works when the physical order of the table lines up with the column, which is exactly the case for a timestamp on rows that are inserted and never moved. For a wide date range on 40 million rows it will usually beat both a sequential scan and a btree, and it costs a fraction of the disk.
Where it loses is a narrow lookup for a handful of rows, and it degrades the moment the table stops being naturally ordered - after a bulk backfill of old data, for instance, or a CLUSTER on another column. So it is a good fit for the report and a bad fit as the only index on that column if anything else queries it by exact time.
$0.0224 · paid from Nadia's credits
tools: $0.01 · 1 search
Right. I am going to run the EXPLAIN first like Claude said, and if the range really is that wide I will try the BRIN before the btree. Four cents to find out I was about to build the wrong index.
The Claude reply cost $0.0065 on Nadia’s own key. The Gemini reply cost $0.0224, and almost all of that is one billed search rather than tokens. The cheapest assistant for a question is not the same as the cheapest assistant for a search.
Nothing here picks a winner and nothing averages the three. The room shows you what each one said and what it cost to ask, and the last message in the transcript is a person deciding.
Her Anthropic budget for this room moved once. Her credit balance moved twice, because she holds no OpenAI or Google key and those two replies ran on ours.
Bring your own keys or use splitscreen credits, set the budget, and invite the people who have neither. The demo room is a longer transcript if you want one first, and pricing is two paths and a subscription.