Build1 publisher3 min readPublished Updated
OpenAI is paying for onboarding completion, and the price is set by remote config
A teardown of ChatGPT desktop 26.803.81509 found an experiment-gated setup flow that offers credits for finishing. The amount comes from a server, not the build.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

What happened
- ChatGPT desktop version 26.803.81509 contains a complete, experiment-gated "conversational onboarding" system.
- The flow asks the user's role, presents role-specific starter tasks, handles permissions and app connections, executes the selected task, and records its outcome.
- A separate remote configuration supplies a credit_amount; when that amount is greater than zero for a ChatGPT-authenticated account, the interface promises "Finish set up and get [X] credits," labels the reward an "Onboarding bonus," and says the credits will be "added to your balance."
- Skipping onboarding displays language indicating the credit offer will be forfeited.
- Completing onboarding sends a request to /wham/onboarding/desktop/complete containing the selected role, whether onboarding was skipped, and whether the credit-reward warning was shown.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
RuntimeWire says it found a complete, experiment-gated "conversational onboarding" system inside ChatGPT desktop 26.803.81509 that asks new users what they do, hands them a role-specific starter task, walks them through permissions and app connections, runs the task and records the outcome [1][2]. For some eligible accounts the flow also offers a payment for finishing, and the size of that payment is supplied by remote configuration rather than compiled into the build [3].
That last detail is the interesting one. According to RuntimeWire, a remote config field named credit_amount drives the offer: when it is greater than zero for a ChatGPT-authenticated account, the interface promises "Finish set up and get [X] credits," calls the reward an "Onboarding bonus," and says the credits will be "added to your balance" [3]. Skipping shows language indicating the offer is forfeited [4]. The onboarding flow and the reward sit behind separate experiment gates, so the task-based setup can run with no bonus at all, the bonus can be restricted to a subset of users, or the number can be changed without shipping another desktop build [8].
Two things follow. First, the client teardown cannot tell you what the bonus is worth, because the client only renders a value it is handed [18]. Second, the company has built itself a dial for the acquisition cost of one activated desktop user and can turn it per cohort, in production, at will [8][3].
The measurement side is built out to match. Completing onboarding sends a request to /wham/onboarding/desktop/complete carrying the selected role, whether onboarding was skipped, and whether the credit-reward warning was shown [5]. Those three fields are enough to compare completion between users who saw a paid offer and users who did not, cut by role [19]. There is also a dedicated error message for cases where onboarding credits cannot be processed, which is the sort of string you write when money is actually expected to move [6].
The starter tasks are not a product tour. The bundled examples include scheduling focus time, sending the user a message, building a chart from a spreadsheet, leaving a note on the desktop and changing the computer's system theme [9], which pushes the newcomer straight into the permission and confirmation steps that computer control requires [10]. The theme demonstration restores the original setting afterwards [11], and the build handles failed and incomplete runs [12]. So the activation event being purchased is not a click. It is a first agent action with granted permissions.
Caveats, stated plainly. The code is behind experiment flags, so its presence does not establish that anyone is being shown it [7]. RuntimeWire's method was static analysis of an OpenAI desktop archive dated August 11, 2026, extracted without executing the bundled code, on package openai-codex-electron build 6415 with a published app.asar hash [13][15]. It reproduced the interface by activating the dormant path in a copied build and feeding a local value into the server-configured field; eligibility, live reward amounts and balance crediting were not tested [16]. RuntimeWire found no public documentation or prior coverage of the reward in OpenAI's release notes, consumer credit documentation or desktop promotion terms [14], and says the company had not responded to a request for comment by publication [17].