What we store, and what delete really does

One submission becomes one job row plus one content record. The row holds the bookkeeping: a random task id, the status, timestamps, the research field it was routed to, the idea format, how many models were asked and how many answered, and the worker lease the generation runs under.

The content record holds the substance, and it is deliberately complete - a build that cannot be replayed is a build nobody can audit:

A vote is a single append-only record and is never rewritten. It stores the timestamp, your browser session id, the battle id, the research field, the task id, the two idea ids, the two model names, and your choice.

It also stores, when they exist: the research field and role you self-reported (both unverified, both optional), the free-text rationale you wrote, capped at 500 characters, a salted hash of your network address, your Google account id if you were signed in, a SHA-256 of each idea text exactly as it was on your screen, and the probability with which that model pair was sampled.

A file you attach is kept with the task, raw: a PDF is text-extracted AND the PDF itself is stored, an image is captioned by a vision model AND the image itself is stored. The raw files exist so competitors can be handed your actual document or picture rather than our summary of it. They are server-side only and are never sent back to any browser.

A link you paste is fetched so its text can be read, which means the site you linked to sees a request from our server. An arXiv id is resolved through arXiv, a DOI through Crossref. Those services see the identifier, not your question.

Voting and submitting require a Google account. Your browser sends us a Google ID token; the server verifies it against Google's published keys and keeps exactly one field out of it - the sub claim, Google's stable opaque per-account identifier. Your email address, your name, and your photo are read from that token to draw your avatar and are then discarded server-side. They are never written to the database.

Your name and photo do get saved in your own browser's local storage so the avatar can be drawn again on your next visit. Signing out removes them.

The account id is used for three things and no others: your daily submission budget, proving that a task is yours when you hide or cancel it, and holding your saved-ideas collection (next section). It is stripped from the vote log before any export leaves the server.

The bookmark on an idea card keeps a copy of that idea in your browser's local storage. Signed out, that is the whole feature: the collection lives on your device alone, and clearing site data erases it.

Signed in, the collection also follows your account so it survives a new phone or a cleared cache. Each saved row - the idea's text, the model that wrote it, the source task id and title, and the time you saved it - is stored server-side under your Google account id. Rows saved on your other devices are merged in, and rows restored from the account leave the device again when you sign out; what you saved on the device itself stays.

Removing a saved idea stamps the server row deleted rather than erasing it - the same rule task deletion follows above, and the stamp is what tells your other devices to drop their copies instead of resurrecting the row on the next merge. If you want your saved rows removed from the server entirely, write to the contact address below and name the account.

The arena works by sending your question to other companies' models. There is no version of this product where that does not happen, so here is the exact list.

The task builder call goes to OpenRouter, which routes it to OpenAI. The idea-writing calls go to OpenRouter for most of the roster and directly to Anthropic and OpenAI for the rest; the models behind them are made by Alibaba, Anthropic, DeepSeek, Google, Meta, MiniMax, Mistral, Moonshot, NVIDIA, OpenAI, Thinking Machines, xAI, Xiaomi, and Z.ai. Every competitor on the leaderboard is named there, with its maker.

The competitors run as agents with a browser. While writing your idea a model may run web searches and read pages, so your question - or search queries derived from it - can reach the search backend (Exa for most rows, the provider's own search for the Anthropic and OpenAI runtimes) and the websites it opens. What each writer searched for and read is shown to you after you vote.

Each provider handles what it receives under its own terms. We do not control their retention, and we do not pay for a no-training guarantee on your behalf. If your question is one you cannot send to a third-party model API, do not submit it here.

The service is hosted on Vercel (the site), Cloudflare (in front of the API), and Railway (the API and its Postgres database). They see ordinary request traffic and keep ordinary request logs.

Public without an account: the leaderboard, the field coverage page, and the documentation. None of those contain anyone's submitted question.

Your question is not listed anywhere. There is no directory of submissions, no search over them, and no page that shows you another person's task. Its unguessable id is the access key: whoever has your task link can read the task and the ideas written for it, so treat that link as the secret it is.

The dataset this project exists to produce is the vote log, and we intend to publish it. An export is one vote record per line, with the Google account id removed. It carries no question text and no idea text - only ids, model names, the choice, content hashes, the sampling probability, and the fields you optionally filled in: your rationale text, your self-reported research field and role, your session id, and the salted address hash. If you would rather not have your rationale published, leave it blank.

Model identities stay hidden until you vote. That is a fairness rule, not a privacy one, but it is enforced the same way: the battle token carries opaque idea ids only, and every idea is scanned for model and organization names before it can be shown.

Indefinitely. There is no expiry window and no garbage collector running against your submission: the retention setting ships at zero, which switches the collector off, and a Python test pins it there so a later change cannot start deleting quietly.

This is a choice, and the reason is worth stating rather than burying. The questions researchers actually ask, and the ideas the models write for them, are the corpus this project exists to build - the material for training and evaluating a model of research taste and a verifier of research claims. A dataset that erases itself every quarter is not one. If that use is not acceptable to you, do not submit the question; a policy you have read and declined is the honest outcome, and it is a better one than a promise we would have to break later.

What you can do on request is hide a question, and that works regardless of votes and regardless of status - but it is a change in visibility, not in storage. The next section says exactly what it does.

Uploads have their own hour-long row that is collected quickly; what survives is the copy kept with your task, under the task's own retention.

Votes are kept indefinitely and are never rewritten, including after you hide the question they were cast on.

Send DELETE /api/tasks/{task_id} for the task you want out of sight. Only its submitter can: the request must carry the browser session that submitted it or the Google account it was submitted under. Someone who merely has your task link cannot hide it, and you cannot hide anyone else's.

The request destroys nothing. It marks the task hidden: the task drops out of your history list, and its battles stop accepting new votes. The question, the built task, the ingested sources, the attachment copies, and every generated idea stay stored, and anyone who still has the task link can still open it. Hiding the first task of a thread hides its follow-up rounds with it, and it works whether the task is finished or still being written - a job still running is stopped on the way out.

The votes it collected are also retained and keep counting: the leaderboard is computed from them, and they contain neither your question nor the idea text - only ids, model names, and the choice.

We say hide rather than delete because that is what the code does. Nothing submitted here is ever destroyed on request - the previous section explains why everything is kept - so do not submit a question on the assumption that it can be. If that is not acceptable, do not submit it; and for anything this page does not cover, write to the address below.

We count four things, and this is the complete list. Not a summary of it, not the interesting ones - the whole vocabulary, and the code rejects any fifth name outright.

Each of the four is one row: the event name, the time our server received it, two random ids, the same salted address hash a vote carries (described under Addresses and logs below), and for a keep, the word copy, download, or share. No question text, no idea text, no account id, no raw address, no page you came from, no browser or device details. A share records only that word: who you shared with, and what app you picked, never leave your device.

The address hash is on those rows for one reason, and it is not measurement. Anyone can post events to us without signing in - the first one happens before you could sign in even if you wanted to - so anyone could also post a few thousand fake ones and quietly move a number we publish. The hash is what lets us spot such a flood afterwards and recompute the number without it. It is made from the connection address our hosting provider's edge reports to us, so it is exactly as reliable as that report. The only reading of it is that abuse check, an operator command run by hand on the server; nothing about you is measured with it, and no page or API ever gives it back out.

The two ids are the whole mechanism, so they are worth being precise about. One is a random id kept in your browser's local storage that survives closing the tab, which is the only reason we can tell a returning reader from a new one. The other is the per-tab session id that already existed for votes, and it dies with the tab. Both are random values we generate; neither is computed from anything about your device, your screen, or your browser, because an id derived that way is a fingerprint and would follow you across sites we do not run. Clearing site data erases both, and the next visit looks brand new.

If your browser refuses to store those ids - private browsing that blocks storage, storage switched off - we do not fall back to anything cleverer: no measurement is sent at all. That is a bias we accept knowingly. Browsers that block storage are absent from these counts entirely, so the numbers describe the visitors whose browsers allow storage, and we read them as that rather than as everyone.

The reason all this exists is one question: of the people who got as far as seeing an idea, how many kept it? Without first_idea there is no denominator and the answer is unknowable, which is why the list is exactly this long and not longer - every extra measurement is one more thing we would have to describe on this page and keep honest.

This is built and hosted by us. There is no analytics product installed, no tag manager, no pixel, no session recorder, and no script from an analytics company anywhere in this site. The measurements go to our own API and nowhere else, and no company is paid or permitted to watch you here.

One cookie of ours: arena_session, set after you sign in. It is signed, HttpOnly, Secure, and SameSite=Lax, and holds your Google account id and nothing else. There is no advertising cookie and no third-party analytics on this site.

Local storage holds your own conveniences: your theme, whether the sidebar is collapsed, the list of tasks you submitted from this browser, your self-reported field and role, and your sign-in profile. It also holds the two measurement values from the section above - the durable random visitor id and the date you were last here. Session storage, which empties when the tab closes, holds your browser session id and the pairs you have already been shown. Clearing site data removes all of it.

The one script on this site loaded from another company is Google's sign-in library, from accounts.google.com, and it is there so the sign-in button works.

One other thing is fetched from a server we do not run, and only if you sign in: your Google profile photo, from Google's image host lh3.googleusercontent.com. Your browser requests it to show your avatar, and we also copy it once into your own local storage so it paints without a network request next time. That request tells Google your address and that your browser asked for the picture, the same as any image on any site; we send no referrer with it, and we never send them anything about what you did here. Signed out, it never happens.

One more external fetch can happen, and it is the one we do not pick: when a model's idea includes a runnable visual - an interactive chart, a three.js scene - it renders inside a locked-down frame, and the code in that block may load a script library from a public CDN, the way such demos are usually written. The frame is isolated from the rest of the site: it cannot read or write your cookies, your storage, or the page, and no referrer is sent. But the CDN named in the idea does see your address ask for that library, and which CDN that is was the model's choice, not ours. It happens only while an idea with such a preview is on your screen. The complete list of other people's servers your browser can be asked to contact here is: Google's sign-in library, your Google profile photo if you sign in, and whatever library a rendered idea's preview pulls in.

Your IP address is never stored. What is stored alongside a task, a vote, or one of the measurements above is the first 16 hexadecimal characters of SHA-256 over a per-deployment salt plus the address.

That is pseudonymisation, not anonymisation, and the methodology says so too: anyone holding the salt can recompute the hash for a guessed address, and the IPv4 space is small enough to enumerate. Treat those rows as linkable pseudonyms. The salt stays on the server and is not exported.

The hash exists for coarse abuse work - one address casting hundreds of votes - and for the per-address submission caps. Our hosting providers keep their own request logs, which do contain addresses, under their own retention.

Questions, corrections, and deletion requests: write to benjaminliu.eecs@gmail.com. If you find a line on this page that the code contradicts, that is a bug worth filing - the whole point is that these two agree.