Documentation › User Guides › Device Owners › Stage 2 › Your first qualifying job

Device Owner mode launches Q3 2026. The screens and flows described below are based on the implementation under active development. We'll update these chapters with final screenshots and verified click-paths at launch. If you're a Device Owner early-access tester, expect minor UI differences and please report anything that doesn't match.

Your first qualifying job

Your device is paired and online. Now you wait for the marketplace scheduler to send you work. This chapter explains how that happens, what a "qualifying" job looks like, and what to do (or not do) when one lands.

What "qualifying" means

A job is qualifying for your device when all three are true:

  1. Online and idle. Your device's status is online or active.
  2. Capability score meets the job's minimum. Jobs declare a minimum requirement (e.g., "≥ 500 score, 8 GB RAM, GPU optional"). Your score must clear it.
  3. Inside your availability window. Once you set a schedule (chapter 5), only jobs that fit your available windows will reach you. Default: available whenever the machine is online.

How the scheduler picks devices

When a customer organization submits a job, Zyra's placement scorer ranks all qualifying devices by:

  • Capability score relative to job requirement (closer match wins)
  • Network latency to the nearest region
  • Recent reliability (your reputation_score, built up over completed jobs)
  • Price (in marketplace mode — [VERIFY: marketplace pricing-rank weighting at launch])

The top match gets dispatched the task; the rest stay in the pool. You don't need to bid, accept, or claim — it's automatic.

What happens when a job lands

  1. Tray icon flips to "Working". Subtle notification (configurable).
  2. Sandbox launches. A fresh, isolated container starts inside the agent's working directory. Your filesystem, browser, and personal apps are completely walled off.
  3. Task runs. Could be Docker, WebAssembly, batch compute. The container has no network access to your LAN — only outbound to the coordinator.
  4. Results upload. Outputs go to a designated folder, the agent uploads them, then destroys the sandbox. Nothing persists between jobs.
  5. Tray icon returns to "Idle" and the dashboard logs a completed task.
[SCREENSHOT: agent tray menu showing "Working" state]

Sandbox isolation — your data is safe

Every task runs inside a Docker container with these enforced limits:

  • read_only root filesystem — the task can't modify the host
  • network_mode: none — no LAN access; only the agent talks to the outside world
  • cap_drop: ALL — no kernel privileges
  • no-new-privileges: true — can't escalate
  • user: nobody:nogroup — no root inside the container
  • Hard CPU and RAM caps (set by you in chapter 6)

Translation: a malicious customer's code physically cannot read your files, sniff your network, or persist anything.

How long until my first job?

  • Best case: within an hour of pairing
  • Typical: a few hours to a couple of days
  • Quiet period: up to a week if launch traffic is still ramping

You don't have to babysit. Leave the agent running. To test the pipeline immediately, use Run a self-test job under Devices → [your device] → Diagnostics. [VERIFY: self-test feature available at GA]

What you'll see on the dashboard

After your first real task completes, the Tasks tab on your device detail page lists task ID, customer (anonymized), start/end times, duration, compute resources used, and earnings credit.

What's next

4. Your first earnings credit →

Last reviewed: 2026-05-21