Account and access

Connect the intended account and distinguish authentication from product access. These checks help explain an access refusal without changing permissions or submitting the same work again.

Browser access

1. Open the Ouros dashboard and follow its sign-in flow when requested.
2. Confirm the intended account and workspace before looking for saved work.
3. Check the availability of the particular service in that product. A browser session proves sign-in, not access to every paid feature.

A saved model-provider key serves a different purpose from your Ouros account. Provider credentials do not establish a product subscription. Ouros X is free to use; that does not make every hosted Ouros service free.

Dashboard assistant profiles

Open Workspace assistant, then choose Assistant, Research or Builder under Assistant profile. Availability follows your account access; choosing a profile does not enable a paid service.

These profiles work with the text you send. They do not browse the web, read or edit files, run commands, deploy changes or continue background work. The profile name does not grant those permissions. Check Profile capabilities before sending a request.

Each profile keeps its own conversation. While a request is pending, the selected profile stays fixed. If the response is interrupted, use Check existing response rather than sending the same task again. Stop waiting only stops your browser from waiting; use Cancel request when available and check its confirmation.

Paid Zilch access

Zilch extraction requires active paid Zilch entitlement on the requesting account. A free account, another product subscription, an API key or available quota does not grant extraction access. Usage limits apply in addition to entitlement.

The following is reference text for Zilch errors and operation states, not commands or a captured API response:

401 authentication_required: authentication is missing.
402 subscription_required: required paid Zilch access is missing.
reserved: inspect the existing operation.
completed: inspect the result, warnings and truncation.
failed: inspect the saved error before retrying.
cancelled: no completed result is available.

For 401, restore the intended sign-in. For 402, check the account's Zilch subscription instead of repeating extraction or trying a different endpoint. Continue with the Zilch quickstart only when the access requirement is met.

Native device approval

1. Start account connection in the native app and use the browser flow it opens.
2. Match the verification code shown by the app before approving the request. Do not approve an unexpected request.
3. Return to the app and confirm its connected state.

Signing in to an unrelated browser tab alone does not approve a native device. Keep approval codes private; never move cookies between browser and native sessions to repair the connection.

Recover access without repeating work

Preserve unsent text, the original inputs and any existing request or run identity before signing in again.

After restoring access, inspect the existing work in the intended account. A missing account context can look like missing work. Confirm the original operation's state before deciding whether another submission is needed.

Check the result

For browser access, confirm the intended account and requested feature. For native connection, confirm the connected state in the originating app. For Zilch, check paid access separately; authentication success alone is insufficient.

If access remains blocked, use the support report template to retain the exact non-secret error and the work already preserved. Review privacy and permissions before sharing it.