Jern Cloud docs

Settings.

Everything a workspace admin manages, in the groups and the order the settings navigation shows them. A member sees the same sections and can change none of them, apart from what the repository page gives anyone who can start sessions there.

Workspace

Members

Invite people by GitHub login as admins or members. An invitation is a one-time link. Membership grants visibility of the workspace; what a person can see of repositories and evidence still comes from their own GitHub access, re-checked on every read. An admin manages everything on this page; a member starts and follows sessions, and sets schedules and campaigns on repositories they can write to.

Plan

The plan the workspace is on and where it came from: the thirty-day trial every workspace starts with, a plan bought on GitHub Marketplace, or one agreed with Jern. A Marketplace purchase is billed by GitHub to the account that installed the App; the section shows the billing cycle, the next billing date, and any change GitHub has scheduled, and links to GitHub's order page to subscribe or manage it. Cancelling on GitHub ends the paid plan at the end of the billing cycle; the workspace then keeps its sessions readable and pauses new work, exactly as at the end of a trial. Model usage is never part of the plan; it bills to your own provider account.

Usage

Tokens metered by the gateway, per attempt and per month, against the workspace allowance, in the provider's own tokens; the estimated spend at list price; machine time per size, priced per hour; spend by repository with the part that schedules started; and what became of the month's sessions, from pull request to merge. See Spend.

Sessions

Policy profiles

The workspace's own policy profiles, each with its editable paths, test command, other allowed commands, services, hosts, and whether the agent may keep memory, use repository knowledge, drive the browser, or ask a question. One profile is the workspace default: it governs sessions in every repository that has no baseline of its own. Every profile is also offered in the Setup section of each repository page as the baseline a setup pull request commits. See Policy.

Controls

The limits every session runs under, whoever or whatever started it: whether attempts need an admin's approval, how many run at once, the monthly token allowance, the largest cap a session may set per attempt, spend caps in dollars per attempt and per month, and the time limit per attempt under the plan's ceiling. A spend cap bounds the estimate at list price that every receipt shows: the gateway refuses the next model call once an attempt or the month has reached it, so one response may overshoot by its own cost, and the token caps still apply underneath.

Triggers

One switch for the work nobody starts by hand: a label on an issue, a /jern comment, a failed check on a session's pull request, and the schedules and campaigns set on repository pages. The model and cap triggered sessions run with, the label, and the opt-in to fix failed checks live here. See Triggers and Schedules.

Integrations

Provider keys

One card per provider to add, rotate, or revoke the key sessions run on. See Provider keys.

API tokens

Tokens that let Claude Code, Cursor, or any MCP client open and follow sessions as the member who created the token, scoped to repositories, a cap per session, a spend limit, and an expiry that can only narrow what that member may do. A token is shown once. See MCP server.

Data

Evidence

The retention window for evidence and conversation text, 90 days by default. Retention is enforced automatically every hour, and an admin can purge now. The audit log of workspace events is exportable as newline-delimited JSON.

Funnel

On Jern-internal workspaces only: the steps the workspace has taken from installing the App to its first pull request, with counts and dates. Step names only; no content is recorded.

Notifications

The bell in the top bar lists the workspace events that need a person: a pull request ready, an attempt that failed or stopped to ask, an approval requested, a refused trigger, a merge. Each one opens the session it is about, or the section of the repository page where its schedule or campaign lives. Every event is also on the audit log.

The repository page

Beside Settings, each connected repository has a page of its own with four sections. Overview shows readiness and a card per capability with where it stands. Knowledge holds the claims people hold and the agent's memory. Automation holds the schedules and campaigns that run on the repository by themselves. Setup is where an admin assigns the execution environment and anyone with write access opens the setup pull request that gives the repository its own policy baseline.