Quickstart
The hosted console supports browser-scoped guest sessions as well as signed-in accounts. You can be ready to start a problem in a few minutes.
1. Open the console
Choose Use as guest to try the console without creating an account. For durable account history, create an account when registration is offered or use Sign in with your existing email and password.
A guest’s run history is tied to a 24-hour session cookie in that browser. Clearing cookies or site data, or moving to another browser or device, loses access to that guest history. Guest work is not transferred when you later sign in, so sign in before starting work you need to retain with an account. Ending the guest session deletes its saved provider key.
If you forget your password, choose Forgot password? on the sign-in page. Use only the newest reset email; a reset link is single-use.
2. Choose how runs are billed
Guest mode defaults to Kimi K3 with the Kimi proof harness: draft an argument, critique it, then refine the result. If hosted Kimi access is available, you can start immediately. Otherwise, open Settings and add your own Kimi API key. The tool-free Plain baseline is also available when enabled by the deployment.
The default guest allowance is 10 total run starts in the browser session, with up to six starts per hour. Deleting a run does not restore a start. Sign in after the tenth start to continue; a deployment may offer a lower allowance. Each Kimi stage has a default 4,096-token response limit. Key verification allows six attempts per guest per hour by default.
Claude Code and Codex require sign-in, even when guest starts remain. Their cards stay visible in the dashboard so you can see the available options.
Signed-in accounts can use the provider routes enabled by the deployment:
- Add your own provider API key.
- Connect a supported subscription account when that option is available.
Provider keys saved through the console are encrypted at rest in the associated user record. In a guest session, those settings remain tied to the same browser cookie and can become inaccessible if that cookie is lost. Use a signed-in account for durable provider settings. The console selects the credential route associated with the model you choose and limits the normal child-process environment to that route. Signed-in local proving engines share the host's operating-system trust boundary; they are not a sandbox for untrusted code.
3. Start a problem
- Enter a mathematical statement or select an available problem.
- Pick an available engine and model. Guests start with Kimi proof harness · Kimi K3 selected.
- Signed-in users can set the iteration budget and optional delegation choices.
- Select Start.
The run opens in the live monitor. You can switch between the pipeline and graph views while the agents work.
4. Review and continue
Open the workspace artifacts when the run finishes. The Kimi harness saves its draft, critique, and refined proof. Review the argument together with any verification output and recorded gaps. Signed-in users can add focused feedback and continue the same run; guest runs finish after the selected workflow.
Keep your account safe
- Do not paste API keys into problem statements or chat messages.
- Do not share password-reset links; the token grants temporary access to reset your password.
- Sign out on shared computers.
- Rotate a provider key immediately if you believe it has been exposed.
For a deeper tour of engines, trace views, and the reusable library, continue to the Overview.