Grok Bot has competition. Your AI, on a cloud computer. Put it to work.

Yes, through your phone’s browser. Open your work and step in when your worker needs a decision or sign-in. Native Android and iOS apps are planned; release dates and notification behavior are still being finalized.

Choose Claude Code, Codex, Cursor, Grok Build, OpenCode or Google Antigravity, and an available model from your connected account. OpenCode broadens the model catalog further. Subscription or API charges follow the provider you choose.

Wrkr installs Anthropic’s published Claude Code CLI. T3 Code uses Anthropic’s Agent SDK to run it, with Claude Code’s own login and configuration. You connect your own Claude account or choose API billing. Your account supplies the AI access; Wrkr supplies the computer and interface.

Anthropic sets the conditions for hosted Claude Code and SDK integrations, including subscription eligibility and any required permissions. Those conditions apply to Wrkr’s integration as well as to your use. Your plan’s model access, usage limits and billing rules continue to apply. Choosing Claude through OpenCode uses that provider’s separate account and billing path.

Wrkr runs OpenAI’s official Codex CLI. T3 connects to its documented app-server interface to manage conversations, approvals and results. You sign in with your own ChatGPT account through OpenAI’s sign-in flow, or choose an OpenAI API key for usage-based billing.

Subscription access follows your eligible plan, workspace permissions and usage limits. API usage is billed separately by OpenAI. Wrkr provides the computer and interface while your account remains subject to OpenAI’s applicable terms. Read OpenAI’s authentication documentation ↗ · OpenAI’s terms ↗

Your saved work is backed up automatically. Ask your worker to retrieve a file or an earlier version. Retrieved files appear as separate, dated copies so you can inspect them without overwriting current work.

Backups normally run every 30 minutes, targeting recovery within an hour. Heavy changes above your plan’s allowance switch copying to daily, retaining the latest two copies. History and earlier-file downloads have plan-dependent limits. Recovery needs a retained backup containing the file; caches are excluded. Your account page shows backup age, history and any reduced cadence.

Backups are encrypted and stored off-server. Wrkr can recover saved workers and local state on another machine after a failure. This does not promise uninterrupted service or permanent retention.

Yes. Create workers as needs arise, pause them or delete them. Other workers can continue when one is paused. The roles and worker counts shown here are examples, not fixed packages. Concurrent work depends on shared capacity and provider limits.

Your worker builds and runs a website or app on your computer, then uses wrkr expose to give that running service a stable public HTTPS address. The URL stays the same; the app must keep running to serve it. It is a way to share a running app, rather than a promise of managed scaling or unlimited hosting.

Yes. Your worker can build the storefront, backend, customer sign-in and owner dashboard. The launch offering provides Postgres through wrkr db, object storage, email, a Redis cache and public app URLs. Your worker wires those pieces into your app. Payment processing, delivery services and other external integrations still use their own accounts and terms.

Yes. Your worker can integrate an established authentication library such as Better Auth into your app, with accounts and sessions stored in your Wrkr Postgres database. Wrkr email can deliver the app’s verification and password-reset messages. This self-hosted path does not require a hosted-auth subscription. Your worker still needs to configure and maintain authentication and access controls; Wrkr does not currently provide a separate managed authentication service. Social sign-in needs provider setup, and SMS authentication needs a messaging provider. The bakery demo uses sample orders without real customer accounts.

Yes. Wrkr email can send app messages such as order confirmations, receipts and sign-in links. Your worker can help verify your custom domain using DNS records. Incoming messages can be forwarded to an existing inbox or delivered to the app through a webhook (an automated message to your app). This is app email, rather than a hosted mailbox with its own inbox interface. Sending allowances apply.

Wrkr lets you connect supported accounts and the AI tool’s own plugin catalog. Claude Code and Codex can bring services from your Claude or ChatGPT account, alongside their marketplaces. Availability, sign-in and permissions follow that AI tool and your plan.

When the job needs a website or desktop app. Let the worker navigate and fill in the routine details. Take control for a password, a verification code, a CAPTCHA or another step the website requires you to complete. Then tell the worker to continue. Files, media previews and the terminal work with the screen closed.

Yes. Your worker can work with project files, code, supported plugins and skills, and tools installed in its workspace. Each worker has its own files and browser sessions. Available compute, disk space, provider limits and software requirements still apply.

Yes. Your worker is an always-on Linux environment with tools for scheduling recurring work. Your worker can create scripts and schedule them with systemd timers for recurring checks, reports and other background work. Reminders need a supported delivery service and the right permissions. Jobs still depend on the computer running, valid sign-ins, available resources and any AI or service limits.

Not for the app essentials shown here. Run the app on your Wrkr computer, use wrkr db for Postgres, wrkr storage for uploads, wrkr email for app messages, and wrkr expose for its public URL. Your worker can schedule scripts with Linux cron or systemd timers. These are included in the intended launch offering, within Wrkr’s plan allowances. You can still choose an external platform for its additional managed features; ordinary cron is not a full durable-workflow platform. Your AI billing, custom-domain registration and payment processing remain separate.

A monthly computer plan from Wrkr, alongside your existing AI subscription or API billing. Hosting a running app, its database, storage, app email, scheduled jobs and cache do not require separate platform subscriptions for the example shown. Wrkr compute and service allowances apply. Custom-domain registration, payment processing and optional external services have their own costs and terms. Pricing and access details come with your invitation, before you commit.

All your workers share your account’s allocation. Dedicated refers to reserved CPU capacity, not a whole physical server. See the computer options ↑

Your account has a dedicated outgoing IP address, shared by your workers. This is separate from an app’s public HTTPS address. Workers have separate files and browser sign-ins; they still share your account’s computer capacity and provider allowances.