Labor0 is part of The AI Platform by Zephyr Cloud.

Labor0

Turn broad requests into bounded work.

Dependency-aware engineering orchestration

Labor0 determines what is ready, blocked, or waiting; then runs ready work through Codex, Claude Code, or OpenCode in managed cloud execution started from mobile web or a configured Plan Mode decision. Parallel execution follows satisfied independent dependencies.

The coordination problem

Make the work graph visible before agents start.

A request can sound simple while hiding scope decisions, prerequisites, review gates, and follow-up work. A queue cannot tell you which work may safely start.

Automation should know when to wait.

A dependency-aware example

Readiness is recomputed when the graph changes.

This one example keeps bounded tasks, prerequisites, a human decision, downstream CI work, and the final review outcome in one connected record.

After Confirm the status contract completes, Implement the status summary changes from blocked to ready. The security decision remains a human blocker; CI or review can create the connected repair task before the pull request completes.

  1. Define the release scope

    State
    Completed
    Predecessors
    None
    Meaning
    Bound the repository scope and acceptance criteria.
  2. Confirm the status contract

    State
    Completed
    Predecessors
    Define the release scope
    Meaning
    Choose the API contract before implementation starts.
  3. Implement the status summary

    State
    Ready
    Predecessors
    Confirm the status contract
    Meaning
    Selected harness: Codex in a managed cloud runner.
  4. Approve the data-handling approach

    State
    Waiting for review
    Predecessors
    Confirm the status contract
    Meaning
    A security decision is a human blocker, not agent work to bypass.
  5. Repair the CI-created follow-up

    State
    Blocked
    Predecessors
    Implement the status summary; approve the data-handling approach
    Meaning
    Created by a CI or review finding; it waits for its predecessors.
  6. Complete the pull request

    State
    Waiting for review
    Predecessors
    Repair the CI-created follow-up
    Meaning
    The completed outcome is a reviewed, merge-ready pull request.

Harness choice

Keep the agents. Add orchestration.

Labor0 keeps project and task runtime choices with the work: model selection, repository scope, harness configuration, and the decisions that determine whether a task can proceed.

Use Codex, Claude Code, or OpenCode according to the configured project and task runtime. Where a provider supports it, Labor0 preserves native provider planning and exact-conversation continuation rather than flattening every interaction into a generic transcript.

Codex access and limits depend on supported ChatGPT plans or API authentication. Claude Code access depends on supported Pro, Max, Team, Enterprise, Console, or supported third-party provider arrangements. OpenCode uses provider-specific API keys, OAuth, environment configuration, or explicitly supported subscription integrations. Availability varies by configured runner and provider.

Execution contract

Run the right harness in the right environment.

The graph selects ready work; the configured project chooses the harness and execution environment, while people stay in control of decisions.

  1. Task becomes ready
  2. Select configured harness
  3. Mobile web or managed cloud runner
  4. Execute and verify
  5. Checkpoint and request a decision when needed
  6. Resume after the response
  7. Update dependent work

Hosted execution from anywhere. Start governed work from mobile web, or choose Codex, Claude Code, or OpenCode Plan Mode for a managed cloud run. Hosted environments are disposable and use explicitly configured runtime or project credentials. A local credential is not silently copied into a hosted environment.

Decisions become checkpoints. When Plan Mode needs a person to choose, Labor0 sends the decision through Web Push, releases waiting compute, and keeps the graph state. After the person responds, the hosted run resumes from its checkpoint where the configured provider supports native continuation, then updates dependent work.

CLI-managed local execution. Set up and run an eligible local runner with the Labor0 CLI. Local credentials stay on your machine and are not silently copied into hosted environments.

Governed waiting

Automation should know when to wait.

Plan, architecture or scope, security, CI repair, pull-request review, and release decisions can each remain graph blockers when a project needs them. Not every workflow requires every checkpoint.

When CI fails or review comments arrive, Labor0 creates connected follow-up work and recomputes readiness. Independent work may proceed once its own prerequisites are satisfied; blocked work remains visibly blocked.

Product roadmap

Meet work where it starts, without skipping control.

Status labels describe what is available today and what remains changeable or future-facing.

  1. Available now

    Dependency-aware orchestration

    Keep prerequisites, blockers, readiness, and follow-up work connected so independent tasks can proceed when their dependencies are satisfied.

  2. Available now

    Managed cloud execution

    Start hosted work in disposable environments with configured credentials, checkpoint execution while waiting, and resume after a person responds.

  3. Available now

    Mobile-web execution

    Start and monitor governed hosted work from Labor0's mobile web experience when the work needs to move with you.

  4. Available now

    Web Push decisions

    When a Codex, Claude Code, or OpenCode Plan Mode decision blocks hosted work, Labor0 can deliver the decision request through Web Push and resume from its checkpoint after you respond.

  5. Available now

    CLI-managed local execution

    Local execution uses the complete Labor0 CLI bundle and is available to eligible workspaces; an active online CLI-managed runner cannot currently enable Local only because Labor0 cannot confirm readiness for the selected coding-agent runtime. Browser Auto may use hosted fallback, while Local only never falls back to hosted execution.

  6. Available now

    Automation Templates

    Discover available project automations, preview their requirements, install them with project permissions, and inspect status and recovery from the Automation page.

  7. Available now

    Schedules

    Create recurring, bounded project work with a reviewable prompt, clear timing, and failure notifications for the responsible team.

  8. Beta

    Slack @l0 and Discord /l0

    Use supported Slack @l0 and Discord /l0 conversations with linked identity, channel binding, permissions, and same-thread continuation. A channel message does not bypass Labor0 permissions.

  9. Beta roadmap

    Connected company knowledge

    Use authorized knowledge search and governed read-only queries from Workspace Chat, configured Labor0 agents, and supported Slack or Discord conversations after connecting company sources once. Arbitrary writes are not promised; a safe internal messenger query tool is future direction.

  10. Beta roadmap

    Evidence-backed QA

    Chatty QA may record clearly reproducible errors without an extra decision. Uncertain or important judgments require screenshots, recordings, traces, or logs; only confirmed results enter remediation work or issues. Support remains bounded by environment.

  11. Alpha roadmap

    Event triggers and Sentry signals

    Future signals can be classified and proposed as dependency-aware investigation or repair work for human graph review. Not every alert should start an agent.

One connected system

From signal to bounded, reviewable work.

Labor0 turns requests, supported conversations, and future signals into structured dependency-aware work—executed by trusted harnesses with the right boundaries intact.