JernCloudStart with GitHubJern Cloud docs
Sessions.
A session is one governed conversation about one repository. Everything that could change what the agent may do is fixed when the session opens and shown in its header.
What a session pins
| Header line | Meaning |
|---|---|
| Repository | The repository and the exact commit every attempt starts from: the default branch's head at session creation. |
| Policy | Where the policy came from, its digest, and what it allows: the paths that may change and the shell commands that run without asking. Verified by the runner before the agent starts; it cannot change mid-session. |
| Environment | The execution environment and its revision: the image and any setup command. A change to the environment is a new revision, never a surprise. |
| Model | The model every attempt uses and the token cap per attempt, metered by the gateway from the provider's own usage report. |
| Machine | The machine every attempt runs on: shared 2 vCPU with 2 GB by default, or a dedicated 4 vCPU 8 GB or 8 vCPU 16 GB machine. Machine time is metered per size and priced per hour on top of the workspace fee; the usage page shows the hours. |
| Credentials in agent | None of yours. Checkout, evidence upload, checkpoints, and publication each use a separate short-lived credential held by the runner, outside the agent process. The agent holds only a token scoped to its run that reaches the Jern gateway and nothing else; the gateway holds your provider key. |
| Delivery | The session's branch and, once a change exists, its pull request. |
Attempts
Every message you send becomes one attempt. An attempt runs on a machine created for it and destroyed afterwards, and ends in one of three ways: a pull request created or updated, no change, or a labelled failure with its reason. A failed attempt is retried on a new machine up to three times before the task is marked exhausted.
Follow-up messages run as new attempts on top of the session branch, so the pull request grows with the conversation rather than multiplying.
An attempt has a time limit, a workspace control under your plan's ceiling (45 minutes on trial, 4 hours on paid plans). While it runs, the runner pushes checkpoints to the session's branch every few minutes, so a machine that dies leaves its work on GitHub. When the limit is reached, the runner publishes whatever the agent has, opens or updates the pull request, stores the snapshot, and marks the attempt timed out; the next message continues from there.
Live activity and evidence
While an attempt runs, the session shows assistant text and tool calls as the gateway relays them. They are a live projection and are never stored. The evidence is the exact trace the runtime wrote, encrypted before it reaches the database, and can be opened from any assistant turn. Every receipt states the tokens spent, the policy decisions, the files touched, and which sandbox confined the run.
Interrupting and closing
Interrupt stops the running attempt: the machine is destroyed, work since the last checkpoint is lost, and evidence captured so far is kept. Closing a session stops new messages; it stays readable and its pull request stays open for you to finish.
Approval gate
A workspace can require a human approval before any attempt runs. Approvals appear inline in the session and as a badge on the session list, and every decision is recorded in the workspace audit log.