# Invited alpha client checklist For invited accounts. Capacity is limited; this is not an uptime, latency or earnings promise. Check [status](https://tenvor.io/status) and the current [catalog and limits](https://tenvor.io/models) before a test. Start with one small request, not a benchmark or parallel test matrix. ## Set up without exposing a credential Use [Tools & IDEs](https://tenvor.io/docs#integrations). The Bash setup needs curl and Python 3.10+. It finds existing user installs or offers an explicit y/N installation of OpenCode 1.18.23 in your home directory, without sudo or shell startup-file edits. Use its printed Run command; no terminal restart is needed. Paste the key only at the hidden prompt. Never put it in a command, URL, screenshot, issue, chat transcript, or source repository. The installer keeps it in a user-only file and preserves other providers and your default model. Sign-in and programmatic keys are separate: Playground uses your managed browser session. Create a programmatic key explicitly in Console only for a trusted external tool. That key can spend the account's prepaid balance. Use a new synthetic project with no private code, credentials, personal data, or customer content. Coding tools can send files, tool arguments, terminal output and conversation history to independent operators; zero retention is not promised. Keep the tenvor-agent approvals on. Do not use --auto. An approved shell command still has your own user permissions; review it before allowing it. ## Confirm routing before trusting the result While proving Tenvor routing, disable `Auto` selection and automatic cloud/model provider fallback. A fallback provider's successful answer does not validate Tenvor. Record whether fallback was disabled; restore your preferences afterward. 1. Select `tenvor-agent` and confirm the model is `tenvor/chat-35b-moe` in OpenCode. The provider base URL is `https://orchestrator.tenvor.io/v1`. Check project-local or JSONC overrides if the active settings differ. 2. Send one short synthetic request within the currently published limits. For a tool workflow, approve only an expected read of a synthetic file inside that project; inspect the resulting continuation. 3. Check the matching time window, model, usage and charge in Console Activity. For an SDK, retain its HTTP outcome and returned usage/billing privately. An answer saying “I am Tenvor” is not routing proof; neither is a configured URL alone proof of a completed paid request. If the corresponding account evidence is missing, record routing as unverified rather than assuming success. Do not publish raw request identifiers, account details or response bodies as proof. The result template below is enough for initial feedback; share any additional evidence only through an agreed private support channel. ## A safe fallback when the alpha cannot complete the task Keep your usual provider configured separately; the installer does not replace it. If setup fails, use the documented manual merge or Playground for a small managed-session check. Never overwrite an entire existing OpenCode config to work around a collision. Backups may contain unrelated secrets: keep them private. For 401, check sign-in/key state; for 402, review balance and the reservation. For a capacity or transport failure, stop the workflow and check Console Activity/status before resending. Respect Retry-After when supplied. A generic 503 is not proof that no request was admitted, and a dropped connection is not proof that no work or charge occurred. Do not enable automatic retry loops or switch a pending paid request to a new idempotency key just to clear the error. If the old request is unresolved, pause and ask support to reconcile it. Once resolved, explicitly choose the other provider for new work and review what history/files it will receive. Switching providers neither cancels an existing request nor makes its charges disappear. It also changes the data recipient. ## Rotate or revoke using the supported Console flow 1. Pause tools using the key and reconcile outstanding requests first. Open [Console](https://tenvor.io/console), sign in, and use “Rotate / replace API key”; complete any requested reverification. Rotation revokes the previous key immediately—there is no overlap or staged second-key guarantee. 2. Copy the replacement once into your trusted secret store or the installer's hidden prompt: `bash tenvor-opencode.sh --rotate-key`. This command updates the local credential only; it does not rotate the server key. Update any other tools that used the old key. Never pass the value as an argument. 3. Restart the client if it caches credentials. Confirm one small authorized request and its account evidence; do not run a paid test matrix. Clear the clipboard after storing the key. If the one-time value is lost, rotate again; the old value cannot be retrieved. For a deliberate rotation check, use a trusted client's private credential storage to call `GET /v1/models`: the previous key must return HTTP 401 and the replacement HTTP 200. Any other outcome is unverified; stop and contact support. Do not place either value in commands, screenshots, logs, or the result template. For suspected exposure, stop affected tools and use Console's “Revoke API key” immediately, then arrange a replacement securely. Review account activity and contact support about unexplained work; do not post the exposed value. Removing the local installer config is NOT server revocation. `--remove` only removes unchanged script-owned settings and its local credential, preserving other providers and backups; if protections reject a modification, stop and inspect privately rather than bypassing them. ## Sanitized result template Fill in only these fields. Do not attach prompts, generated text, tool arguments, files, terminal output, headers, URLs with query strings, secrets, account IDs, request IDs, wallet addresses, local paths, or identifiable screenshots. ```text Date/time (UTC, approximate): Client and version / OS family: Workflow: text / stream / one approved synthetic file read + continuation Public provider and model selected: Catalog available and request within its published limits: yes / no / unknown Routing: settings checked + matching Console usage / unverified Outcome: complete / rejected / interrupted / unresolved HTTP status and public error code only (if available): Tool approval behavior: expected / unexpected / not applicable Usage and charge visible: yes / no / pending (no account details) Fallback used after reconciliation: yes / no Short reproduction steps using synthetic placeholders only: Expected vs observed behavior, without content: ``` Passing one small test is client-path evidence, not a general capacity or privacy certification. Stop after the useful result or an unresolved failure. Worker hardware qualification, benchmark performance, and Windows GPU field validation/checklists are separate work; this client checklist does not replace them.