splitscreen
Start a room

A demo room: one person funds it

This is one chat - “shipping the checkout page” - in a splitscreen room called Storefront. Priya owns the room and has the API key and the credits. Sam has neither, and still asks GPT and Gemini - because Priya’s budget covers the replies, and the receipt under each one says so. It is rendered by the same components the real room uses.

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.

Priya’s budget for this roomTwo separate limits - whichever runs out first is what ends a reply.
afterPriya’s Anthropic budgetCover, today
Priya opens the room$2.0000$2.0000
Sam asks GPT$2.0000$1.9931
Priya asks Claude$1.9818$1.9931
Sam asks Gemini$1.9818$1.9524
Priya’s Anthropic budget
Priya’s own key, capped for this room. Her asks bill straight to Anthropic at cost, and splitscreen adds nothing.
Cover, today
What this room may spend from Priya’s credits on members who have none. One budget a day for the room, whichever assistant answers.
shipping the checkout pageStorefrontSam · Priya
read-only demo$0.0658 spent
roomPriya invited Sam to this room. Sam has no API keys and no credits - Priya’s key and balance cover the replies.
Samb3e0f815→ GPT

We need the checkout page live by Friday - Stripe Elements, guest checkout, and a promo code field. Give me a build order, and say what you would cut if we run out of time.

GPTAuto picked GPT-5.6 Terra

Build order - each step ships on its own, so Friday becomes a decision about where to stop rather than a scramble.

  1. Summary panel, server-rendered. Cart totals, tax and shipping from the existing cart endpoint. No payment code in it, so it can merge on day one.
  2. Payment Element, guest path first. Mount Stripe Elements against a PaymentIntent created on the server. The signed-in path reuses the same intent, so it is a branch in one place rather than a second checkout.
  3. Promo code field. Check the code against your own promotions table before the intent is created, so an invalid code never reaches Stripe and never shows a total you cannot honour.
  4. Confirmation and receipt. Land on /checkout/complete, read the intent status on the server, and send the receipt from the webhook rather than from the browser - a customer who closes the tab still gets one.

What I would cut, in this order: saved cards, then address autocomplete, then the promo field. The promo field is last because it is the only one of the three a support agent can apply by hand afterwards.

Auto picked GPT-5.6 Terra · $0.0069 · covered by Priya

Priya7c41a9d2→ Claude

Claude - review GPT’s build order against how we actually build. The cart is rendered on the server and we have never used a client-side redirect for payment. Read https://stripe.com/docs/payments/payment-element and tell me where the plan breaks.

Claude

read 1 page

Two of the four steps fight the way you build.

Step 2 assumes the browser confirms. Nothing in your checkout has ever redirected from the client, and the plan quietly changes that. If you keep the rule, the server confirms the intent and the browser only collects details - that is a different integration, not a different flag, so decide it now rather than discovering it in step 4.

Step 3 prices the order twice. The panel from step 1 has already rendered a total by the time the promo code is checked, so a code that expires between the two shows a discount the payment will not honour. Recompute the total in the same request that creates the intent and treat the panel as display only.

Steps 1 and 4 read fine to me. The webhook receipt in particular is the part most teams get wrong first time round. Longer notes, line by line, are in the file below.

$0.0182 · billed to Priya's Anthropic key

checkout-plan-review.md · 2 KB
Samb3e0f815→ Gemini

Gemini - rewrite step 3 to Claude’s rule so the total is computed once, and check the current guidance on autocomplete attributes while you are in there. Search, do not guess.

Gemini

searched the web (2)

wcag 2.1 identify input purpose 1.3.5 level · html autocomplete tokens payment form accessibility

Step 3, to Claude's rule - one price, computed once, in the request that creates the intent:

  1. read the cart and the promo code together on the server;
  2. compute the total once and hand the same figure to both the summary panel and PaymentIntent.create;
  3. return the panel’s total from that call, so the page can never render a number the intent does not hold.

That closes the window Claude found without adding a round trip.

On the autocomplete attributes: a requirement, at AA. WCAG 2.1 added 1.3.5 Identify Input Purpose: fields that collect information about the user have to be programmatically identifiable, and the HTML autocomplete tokens - cc-number, cc-exp, cc-csc, postal-code, email - are the ordinary way to meet it. Two things worth knowing before you cite it in review: it arrived in 2.1, so a checklist written against WCAG 2.0 will not mention it at all; and it is about fields describing the user, so a gift-message box needs nothing.

$0.0407 · covered by Priya

tools: $0.03 · 2 searches

Samb3e0f815

Perfect. I will take the promo field, you take the summary panel - server confirm, agreed.

This is a read-only demo.
Fork this roomCreate a real room
No key, no credits, still asking

Two of the three replies answered Sam, and both are bylined “covered by Priya”. Nobody had to add a card to join the room.

A receipt under each reply

What it cost and whose money paid - Priya’s credits on two of them, her own Anthropic key on the one she asked for herself.

Talking is free

The last message has no tag and no receipt. Only messages pointed at an assistant are read by one, and only those are charged.

Create a real room

Bring your own keys or use splitscreen credits, set the budget, invite the people who have neither. You start with this room’s question in the box.

Create a real room