Skip to main content
Projects keep the context that workers need across runs.

​
When to use a project

Use a project when work depends on:
  • a GitHub repo or repo set
  • uploaded files or starting data
  • datasets, traces, papers, or benchmark material
  • workspace credentials and provider bindings
  • project notes or durable knowledge
  • recurring budgets and run policy
Use a one-off run when the goal is self-contained and the default project is enough.

​
Typical setup

project = client.projects.create(name="Improve eval reliability")
project.repositories.attach(github_repo="owner/repo")
project.context.set_project_knowledge(
    "Prioritize deterministic evals, clear logs, and small reviewable patches."
)
Then preflight before launching: 
preflight = project.runs.preflight(
    host_kind="daytona",
    work_mode="directed_effort",
    providers=[{"provider": "openrouter"}],
    runbook="lite",
)

​
Context quality

Good project context gives workers:
  • the target repo and paths
  • the command that proves success
  • known failure modes
  • budget and time constraints
  • review criteria
  • which files or APIs are off limits
Keep credentials out of prose. Attach them through supported credential and provider mechanisms.

​
Onboarding blockers

Some projects cannot launch until setup is complete. Preflight can report blockers for repo access, missing credentials, missing runtime capacity, provider availability, budget caps, or incomplete project setup.