Give your agent
a decision engine.

Use Jev in the cloud

1. Open your free workspace and verify your email with the eight-digit code.
2. Choose your agent and add https://cloud.systemoneengine.com/mcp.
3. Review the agent name, return address and requested services in your browser. Approve the connection, then ask your agent to try a bounded Code Mode plan over supplied evidence.

Remote MCP is the quickest way to connect an agent. For an application, create a scoped API key in your workspace and use the SDK or HTTP API below. The signed-in playground lets you try the same checks in your browser. MCP, API and playground evaluations draw from one account allowance.

You do not need a local server, provider key, payment card or waitlist. Each authenticated account has free Jev access with daily usage limits. Other limits include 10,000 model attempts and 1 GiB of decision input per account per day. Daily access renews at 00:00 UTC. Failed attempts may retain a full-context reservation.

The hosted connection offers sysone_code plus direct sysone_check, sysone_find, sysone_select, sysone_decide and sysone_run tools for an account with decision access. Read sysone://recipes only when you need a saved recipe. The agent should use code for exact rules and skip a Jev call when it already has the answer.

If Jev is unavailable because the provider is not configured or has reached its spending limit, your account and connection remain available. The workspace shows the service status and the evaluation returns a plain error. See setup commands for each agent.

Compose Jev calls with Code Mode

The hosted MCP exposes sysone_code for a bounded decision procedure. Your agent passes an async JavaScript arrow function as the code argument. Inside it, jev.find, jev.check, jev.select and other granted jev.* methods return typed results under value. jev.evaluate batches up to eight independent questions over the same state in one Jev request. Use a later call only when an earlier answer changes the next question.

async () => {
  const found = await jev.find({
    question: "Which excerpt explains the login failure?",
    sources: [{ id: "callback", text: "OAuth callback returned 504 after 12s." }]
  });
  if ((found.value.answerExists ?? 0) < 0.7)
    return { next: "inspect more evidence" };
  const check = await jev.check({
    claim: "The OAuth callback timed out.",
    evidence: [{ id: "callback", text: "OAuth callback returned 504 after 12s." }]
  });
  return { support: check.value.supported };
}

Each run allows up to eight System One calls and ten seconds. The hosted service has a separate daily Code Mode execution limit. Inner calls still use the connection's scopes and Jev allowance. Code cannot reach the network or take application actions. The local npx sysone bridge currently offers direct tools only. See the Code Mode workflow and performance limits.

With a separate temporary-document grant, upload file bytes through the one-use HTTP URL from sysone_documents_prepare_upload. Pass only the returned document ID into jev.searchDocuments inside Code Mode; it returns short excerpts for further checks. Only the uploading connection can access the document, and it expires after 12 hours. The hosted pilot allows up to 100 uploads and 1 GB of raw file bytes per account per UTC day; PDF and HTML conversion input is limited to 100 MB per day. Document tools also use the connection’s request allowance.

Read sysone://patterns for built-in procedures that can search a file, check a shortlist or batch ticket questions. Pass a pattern ID and validated input to sysone_code. Each run returns an ID; your connection can read its metadata-only trace at sysone://runs/{runId}, and your hosted workspace shows its account’s run history.

Launch System One

npx sysone app --target local

The command downloads a verified application runtime, starts its local engine and opens Studio. No source checkout or separate server setup is needed. Requires Node 22.18+ and internet access for the first download.

1. Open Settings and add your Vercel AI Gateway key.
2. Open Library, choose Check a claim and edit its example evidence. The claim-checking guide explains the input and result.
3. Run it and inspect the result in the decision control center.
4. Use Connections to create a scoped key for your agent.

Keep the terminal running. Ctrl+C stops the engine. A second launch opens a matching running instance. For a server-only session use npx sysone app --no-open; an isolated instance can use --port 4320 --home /private/path.

The launcher, SDK, MCP bridge and skill are open source. The compiled application runtime has a separate preview license and its source stays private. The runtime is cached under ~/.cache/systemoneengine; private settings stay under ~/.config/systemoneengine.

Use a scoped connection

In the Connections section of Studio, create a consumer credential with the services, expiration and daily request/model-call limits your agent needs. Save the connection JSON in a private file.

Keep the consumer token in a server environment or a private connection file. A provider key or administrator token is never needed by the client.

// /private/path/agent.json
{
  "url": "http://127.0.0.1:4319",
  "token": "YOUR_SCOPED_CONSUMER_TOKEN"
}

Local engines use loopback HTTP. Hosted engines use HTTPS. Check the connection without making a model call:

npx sysone status --connection /private/path/agent.json

Alternatively, set SYSONE_URL and SYSONE_TOKEN in the client process environment. Do not paste credentials into a chat or source repository.

Use the SDK or HTTP API

For cloud access, verify your email in your workspace, open Settings → Connections, and create an API key for the services your application needs. The key is shown once and expires after 30 days. Set SYSONE_URL to https://cloud.systemoneengine.com and keep SYSONE_TOKEN in your server environment. Revoke the key in your workspace when you no longer need it. API calls use the same daily allowance as MCP and the playground.

import { createClient } from 'sysone/client';

const engine = createClient({
  url: process.env.SYSONE_URL,
  token: process.env.SYSONE_TOKEN,
});

const result = await engine.runPattern({
  pattern: 'palette-match',
  state: 'A calm dark workspace with one restrained accent.',
  candidates: {
    slate: 'Dark slate, pale text, restrained blue accent',
    festival: 'Bright yellow, magenta and saturated orange',
  },
});

engine.capabilities() returns the connection's scopes and limits without inference. engine.patterns() returns the recipes available to the connection. Install the SDK with npm install sysone. The four services are decide, logs, tree and dialogue.

Call POST /v1/patterns/run with the same recipe input. Selection recipes require your own candidate IDs and descriptions. The engine adds a review option when none fits. Custom questions can use engine.run('decide', input). You can also call POST /v1/:service directly using a consumer bearer token. The public package exports request schemas; Studio lets you inspect and try each contract.

Connect a local agent

The separate public sysone client's current stdio bridge still uses the earlier tool names. Start it with npx and a private connection file:

["-y", "sysone", "mcp", "--connection", "/private/path/agent.json"]

For the fastest setup, use the hosted MCP URL above. The local bridge needs a running engine and its own provider key. Its tool names can differ from the hosted MCP until the public client release catches up. Read the tool list returned by your connection before asking for a call.

The engine also exposes Streamable HTTP MCP at /mcp, with a consumer bearer token or explicit OAuth approval. A hosted web client needs a reachable HTTPS engine. Choose your agent and copy its current setup command.

Choose your agent

Each connection gives an agent access to the same decision services. The instructions below distinguish a verified bridge from a client we still need to test. The hosted MCP needs no status call before a useful check.

Codex

We verified the local plugin installation and the stdio bridge's initialization, tool discovery and tool call. Register the bridge with a private connection file:

codex mcp add sysone -- npx -y sysone mcp --connection /private/path/agent.json

Add the sysone skill to your supported skill directory. Native OAuth login is a separate path that we have not verified. Official MCP setup.

Claude Code

Claude Code supports a local stdio server. Our configuration and skill are available; we have not yet exercised this setup in Claude Code.

claude mcp add --transport stdio sysone -- npx -y sysone mcp --connection /private/path/agent.json

Keep System One running in its terminal. Official Claude Code setup.

Cursor

Add the following entry to your personal ~/.cursor/mcp.json. Merge it with existing servers. Our configuration is available; native Cursor verification is pending.

{
  "mcpServers": {
    "sysone": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "sysone", "mcp", "--connection", "/private/path/agent.json"]
    }
  }
}

The connection file stays private. Official Cursor setup.

ChatGPT

For a desktop client with local MCP support, use the stdio command and arguments above. OpenAI documents local server configuration in its MCP guide. We have not verified this connection in ChatGPT.

ChatGPT on the web needs a reachable HTTPS MCP endpoint or OpenAI's Secure MCP Tunnel. Developer-mode access depends on your account and workspace. Follow OpenAI's connection guide after configuring that transport. The local System One launcher does not create a tunnel or hosted endpoint. The marketing website is not an engine endpoint. Cloud users can use https://cloud.systemoneengine.com/mcp; a native ChatGPT cloud review is still pending.

Other agents and applications

A client with stdio or Streamable HTTP MCP support can use the corresponding bridge or endpoint. Your application can call the HTTP API directly. Use a separate scoped connection for each agent so Studio can attribute its usage and enforce its limits. Verify tool discovery and a representative task in your client before relying on it.

Measure what offloading changes

Offloading adds a request. It helps when the saved reasoning work outweighs that extra cost and latency. Test representative tasks before making it your default.

• Compare task quality and final outcomes with and without System One.
• Measure end-to-end latency, including escalations and timeouts.
• Count attempts and tokens across both the fast model and reasoning model.
• Separate cache hits from fresh model evaluations.
• Use actual provider pricing. Usage receipts are not a billing invoice.

Use the workflow measurement guide to record the full comparison. Failed model attempts remain counted. The engine never automatically calls a more expensive model.