Cloud work in a session

In a session WeHarness can run your project’s code: install it, run its tests and commands, check a change before it is pushed and start your app so you can try it. All of it happens in sandboxes: disposable, isolated machines at E2B, never inside WeHarness’s own services.

The working sandbox

When a message needs a command, WeHarness opens a sandbox for that message and ends it when the reply is done (or when you press Stop).

• It starts from WeHarness’s base environment: Node.js 22 LTS with pnpm and yarn, and uv for Python, with 2 CPUs and 2 GB of memory.
• The code goes in as WeHarness read it (the exact commit, or the files you uploaded), with the session’s draft on top.
• Every command and its output appears in the Terminal tab. A command may run for 5 minutes, or up to 10 when WeHarness asks for longer.
• Files a command changed reach the draft only when WeHarness keeps them, so installs and build output do not leak into a push.
• One sandbox works for you at a time; a preview has its own. During the pilot a workspace runs at most two sandboxes for people’s work at once; checks and evaluations of work already accepted have their own room. Work that finds no free sandbox waits for one.
• To run the project’s tests, type /test or ask in your own words.

The environment and the clean check

WeHarness proposes how your repository is set up and checked: the setup commands (for example installing dependencies) and the check commands (for example the tests). It appears in the chat; nothing runs as a check until an owner, admin or member selects Approve environment in the web app. Once approved, WeHarness prepares the environment once, so later sandboxes start faster. Type /env to see or propose it, and /verify to run a clean check yourself.

A clean check runs the approved commands on the exact draft in a fresh sandbox. Its result is bound to that draft: a change afterwards makes it stale. Missing evidence counts as inconclusive, never as passed. The Checks tab shows each result.

When a check fails

• A problem with the environment (setup failing, a timeout, a broken sandbox) is reported to you with what to change.
• Otherwise the decision engine looks at the failure. If the test itself looks wrong, or the fix would go beyond the task, WeHarness asks you. If not, it fixes the cause in the draft, runs the failing check and starts a new clean check.
• WeHarness repairs at most two rounds after your last message, and never on its own when the decision engine is unavailable.

Previews of your app

Ask WeHarness to run your app (“run it so I can see it”, in any language). It starts the app’s server in its own sandbox with the draft applied, waits until it answers, and shows Open preview.

• The preview opens on preview.weharness.io, never on the app’s own address, through a one-time link. Only you, signed in to the web app, can open it.
• Your app sees requests for localhost:<port>, as on your own machine. Live reload works; service workers are not available.
• One preview per person runs at a time, for 30 minutes at most. It shows the draft as it was when it started.

Model calls from your code

When your code calls a model (for example the agent you are building), it does not get WeHarness’s keys. Each sandbox gets its own token for models.weharness.io, passed in the variables the providers’ SDKs already read, so the official SDKs work unchanged.

• A token allows a limited number of calls and tokens (30 calls and 200,000 tokens for work and checks; 60 calls and 300,000 tokens for a preview), and at most four calls at once.
• Only the models WeHarness offers are accepted. Requests and answers pass through and are not stored.
• The token ends with its sandbox. What the calls used is counted in the session’s credits.

What a sandbox never gets

No WeHarness key reaches a sandbox: not for models, not for GitHub, not for the database. WeHarness reads your repository from outside with a token limited to that repository, and talks to the sandbox from outside.

Where a sandbox may connect is enforced outside it, by the sandbox provider’s network policy. It reaches the package registries installs use (npm, Yarn, PyPI, crates.io, Go, RubyGems, Maven and Gradle, Packagist, NuGet, Debian and Ubuntu packages), the GitHub hosts dependencies are fetched from, the hosts a few well-known packages download binaries from while they install (Prisma engines, Playwright browsers), and models.weharness.io. Every other destination is refused, private networks and cloud metadata addresses included, so an app in a preview cannot call other services on the internet. See Security.

Credits

Cloud work reserves the most it can use before it starts and is debited only what it used. See Credits and usage.

• Preparing an approved environment uses 1 credit for each new build. Reusing a prepared environment, or a build that fails, uses none.
• If your code’s model calls used most of a sandbox’s model allowance, the next sandboxes of that task or session reserve more for them, up to four times the usual, and the session says so. When a task’s approved work cannot cover its next round, WeHarness asks for an extension; an owner or admin approves it in the web app. WeHarness never moves your work to a weaker model to fit a budget.
• Without enough available credits, new cloud work does not start (402 OUT_OF_CREDITS); work already running finishes.