Cloud coding agent for GitHub

Keep every side project green.

Put dependency upgrades on a schedule for one repository, see them land, then roll them out to the rest. Or send Jern any issue. Each attempt runs on a fresh machine that can install what it needs, runs your tests before it starts and after it finishes, and opens a pull request whose receipt says what changed, what ran, and what it cost. No setup file to write, nothing on your laptop, no API key to start.

Try it on a repository See a real receipt

Free for 30 days with $5 of inference on us, no card, no API key. Then $19 a month per workspace on your own Anthropic, OpenAI, Gemini, or Fireworks key. Open-source runtime, Apache-2.0.

A Jern Cloud session: the guarantees pinned for the session, the conversation with the agent, and an attempt that stopped to ask a question before writing code.

Your tests, before and afterThe suite runs on the untouched tree first, then on the result. The receipt says which failures were already there and which are new.

Nothing to set upConnect a repository and send a task. The agent may change, install, and reach what a developer would, inside a confined machine that holds no GitHub token and no model key. Your review is the gate.

Stop it and keep the workEnd an attempt at any moment. What the agent had lands on the branch as the pull request, receipt included.

Maintenance that runs itself

Write the chore once. Prove it on one repository. Roll it out.

A campaign is a schedule with terms: a budget it cannot exceed, how many pull requests it may leave waiting, which paths it may touch, and when to give up. The terms are what make it safe to turn on and forget.

1
Write it once
"Upgrade the dependencies and fix what breaks", monthly, on one repository, with the paths it may change and the checks it must pass, such as a build or a lint.
2
Prove it on a canary
That first repository carries the campaign alone until a run is accepted: tests no worse than before, every check passed, nothing changed outside its paths.
3
Roll it out
Widen it to your other repositories. A ceiling on open pull requests keeps the review pile small, the same upgrade is never proposed twice, and a string of failed runs stops the campaign until you change its terms.

Campaigns and schedules are described in the docs. Anything a campaign can do, a single message in a session can do too.

A real receipt

Every pull request arrives with one of these.

The Jern receipt is a check on the pull request, written by the control plane from what the runner measured, never from what the agent says. This one is from a session on the public jern-demo repository: one message, four files, a test suite with one failure that was already there.

Jern receipt · success, acceptance passed apart from failures already present

See the pull requests ↗

Outcome: success · pull request ready

Execution policy: respected: writes within the policy's paths, only allowed commands, the sandbox held

Acceptance checks: passed apart from 1 failing before the attempt · python3 -m unittest on the proposed commit

Files touched: src/alpha.py src/beta.py src/delta.py src/gamma.py · 4 of at most 4, 4 lines

Model: DeepSeek V4 Pro · 10 calls, each listed with the provider's request id

Tokens: 67,886 in · 3,285 out · cap 4,000,000

Estimated spend: $0.026 at list price

Credentials in agent: None · one network route, to the gateway

Policy verified by digest before the agent startedTokens metered by the gateway, not self-reportedTrace encrypted before it touched a database

How it works

Four steps. Nothing to install on your machine.

1
Sign in and pick a repository
Your own or your organization's. The GitHub App installs on just the repositories you choose, in a minute. Python, Node, .NET, and Java are detected from the repository, and so is the test command. There is no file to write first.
2
Say what you want
Type the task in a session, put the jern label on an issue, or comment /jern on one. On the trial the agent runs on our key; later, on yours, at your provider's list price.
3
Watch it work, or don't
Each message is one attempt on a fresh isolated machine: your tests first, then the change, then your tests again. Follow it live, answer if it asks, or stop it and keep what it had.
4
Review the pull request
The change lands on a branch of its own as one pull request with the receipt as a check. Your branch protection and reviewers apply. Jern never merges.

What is different

Less to check by hand. More you can trust without checking.

Every one of these is measured by the runner or the control plane and written on the receipt, not claimed by the agent.

Your tests, before and after

The baseline's test command runs on the untouched tree before the agent spends a token, and again on the proposed commit. The receipt fails only on failures that are new.

It asks instead of guessing

An ambiguous task stops the agent with a question. It publishes what it has, the session shows the question, and your answer starts the next attempt from there.

Stop and keep

End an attempt whenever you like. Within twenty seconds the agent is gone and its work is on the branch, with the receipt saying it was stopped on request.

Every model call listed

Tokens are counted by the gateway from the provider's own response, and every call is kept with the provider's request id, so you can check our count against your provider's bill.

No GitHub token or model key in the agent

Checkout, evidence upload, checkpoints, and publication each use a separate short-lived credential the runner holds out of the agent's sight, and model calls carry a token scoped to the run while the gateway holds the key. A repository secret reaches the agent only when you store one. Its network goes through a proxy that refuses private addresses, and every host it reached is on the receipt.

The same agent on your laptop

The runtime is open source, Apache-2.0. Run it locally with the same policy file, replay a cloud trace offline, and read the code that decides what counts.

The policy

Open by default. One file when you want it narrower.

A repository with no policy runs under the Open profile: the agent may change anything outside .jern/, run any command, and reach public hosts, in the same confined machine, holding no GitHub token or model key, and a change to .github/ is flagged at the top of the pull request. When a team wants tighter bounds, the policy is one file, .jern/baseline.json, reviewed like any other change and pinned by digest for the life of a session. This is the demo repository's. The runtime enforces the policy half; Jern Cloud provides the environment half; the runner refuses to publish anything outside it. More on governed work in Jern for teams.

{
  "policy": {
    "allow": ["edit_file", "write_file", "mcp__jern__start_service"],
    "edits_within": ["src/", "tests/"],
    "memory": "allow",
    "shell_allow": ["python3 -m unittest discover -s tests -t .", "python3"]
  },
  "environment": {
    "services": ["postgres:16"],
    "network_allow": ["docs.python.org"]
  }
}

edits_within names the only paths the agent may change. Nothing outside src/ and tests/ can be written, checkpointed, or published.
shell_allow lists the commands that run without asking. In a cloud session there is nobody to ask, so anything else is denied.
allow grants tools by name; here the file edits and the one MCP tool that starts the declared database on demand. A deny in any layer wins over it.
memory lets the agent keep notes about the repository between sessions, which Jern Cloud stores encrypted and shows on the repository page.
environment is what the host provides around the agent: a Postgres the agent may start, and one public host it may fetch from through the proxy, every connection counted.

Verbatim from jern-ai/jern-demo, the file that governs every session on it. Setup writes a baseline like it for you, or a workspace can set a governed default for every repository without one; the full reference is in the policy docs.

How it compares

Hosted agents ask for trust. Jern gives you something to check.

Cursor Cloud Agents, Devin, and Codex cloud run capable agents. The difference is what you can verify afterwards, what the agent can reach while it works, and what it costs to find out.

In every session	Jern Cloud	Typical hosted agent
Trying it	Sign in with GitHub; $5 of inference included, no provider account, no card	A seat or a credit purchase first
Policy	Open by default; narrowed by a repository-owned file your reviewers protect, pinned by digest for the session	Per-run settings, changeable by whoever starts the run
Credentials in the agent	No GitHub token or model key: checkout, evidence, checkpoints, and publication use short-lived credentials outside the agent, inference a token scoped to the run. Repository secrets only when you store them	A repository token and often a provider key in the agent's environment
Network	Public hosts through a proxy that refuses private addresses, every host reached listed on the receipt; a baseline can narrow it to named hosts or to the gateway alone	Usually open, sometimes an allowlist
Cost control	Your own provider key, a hard cap per attempt metered from the provider's usage, a monthly workspace allowance	Bundled credits or seat pricing, usage counted by the vendor
Evidence	The exact trace, encrypted before storage, with a receipt you can replay	A transcript in the vendor's UI
Runtime	Open source, Apache-2.0. The same agent runs on your laptop	Proprietary
Delivery	One pull request per session on an isolated branch. Never merges	A pull request or a direct push, depending on settings

Comparisons describe common designs of hosted coding agents in general, not any vendor's current terms. Check the security page for what Jern does not defend against.

An inspectable foundation

Trust starts in the open.

Policy enforcement, receipt derivation, trace formats, and replay live in the Apache-2.0 Jern repository. The control plane does not reinterpret what the runtime recorded, and the same runtime runs on your laptop.

Open-source runtimeUse, govern, edit, and test the agent locally. Security and data flowWhat runs where, what is encrypted, and what we do not defend against. Runtime security modelThe claim, the boundary, and its limits, in the code's own words.

One price, your own key

Priced like infrastructure, because that is what it is.

Sessions run on your own Anthropic, OpenAI, Gemini, or Fireworks key, so tokens bill to your account and never to a shared pool. Jern's price covers the control plane: the isolated machines, the gateway, the evidence, and the policy enforcement. Every new workspace gets 30 days free, no card needed. When the trial ends, sessions stay readable and new work pauses until you subscribe.

$19per workspace / month
after a 30-day free trial with $5 of inference included

Any number of repositories
Up to 10 team members
Isolated machine for every attempt, destroyed afterwards
Hard cap per attempt, metered from your provider's own usage
Encrypted evidence, 90-day retention you control
Email support from the people who built it

Start with GitHub The trial includes $5 of inference on two open-weight models, DeepSeek V4.1 Flash and GLM 5.3, on our own key, so you need no API key to see a first pull request. Beyond that, model usage is billed by your provider on your own account and is not included. Larger workspaces and support commitments: hello@jern.ai.

Your next pull request can arrive with a receipt

Pick a repository. Send it the upgrade you have been putting off.

Try it on a repository Read the docs Bringing it to a team?

Keep every side project green.

Write the chore once. Prove it on one repository. Roll it out.

Write it once

Prove it on a canary

Roll it out