Skip to main content
This page lists the Core routes each console page reads and writes, and how the console bounds its reads. The administrator API contract defines the routes, response shapes, pagination and audit records; API namespaces and credentials defines the terms used here.

​
Interfaces

Browser requests are same-origin and carry only the console session cookie. The browser sends the Core key once, in the sign-in request body, and never stores it; it never holds or sends an API key or an OpenAI-Beta header. The console reads through AdminClient, SandboxAdminClient and CoreMetricsClient from packages/agents-client, which validate every response: a malformed value is reported as a failure, or marked as unrecognised where noted below, and never replaced by a guessed or zero value.

​
Projects and keys

Names are checked for length (projects 1–128 characters, keys 1–80) and control characters before sending. An issued key’s plaintext stays in component memory until the administrator confirms it was saved and is never written to browser storage, URLs or logs. There is no project deletion and no plaintext recovery.

​
Project resources

Routes are relative to /core/v1/projects/{project_id} and return the same objects as the corresponding public /v1 operations, so the console applies the public client’s strict projections. Archived projects remain readable. Resource-specific rules:
  • Environment templates. env and setup commands are write-only and never returned, so the console cannot tell whether a Template has them. Inline files report only their size. A Template with a section or field the client does not recognise is marked; its recognised sections are still shown and nothing else is guessed.
  • Skills. A version upload, a default-pointer change and every other Skill write belong to the project’s keys. The console downloads the default or an exact version as a ZIP, deletes versions (the default version is blocked while others remain; deleting the only version deletes the Skill) and deletes a Skill after its name is typed.
  • Files. The list is read 100 per page, newest or oldest first. The administrator API has no File content route, so the console offers no download.
  • Vaults. Credential tokens are never returned. The console shows each Credential’s name, MCP server URL, authentication type and update time.
  • Sessions. A malformed Session fails the read of its project instead of being skipped.
  • Diagnostics. The console translates Core’s classified reason and never infers a cause from raw logs. An unavailable or mismatched diagnostic offers an explicit read retry; a retry never replays execution.

​
Executor credentials and host connection

The Executor credentials section of a Session page appears only when the Session’s environment is self_hosted, for that Session’s project_id and environment.id. The executor credential contract defines the routes, their 404 and 409 responses and the credential file. In an archived project the section hides Issue credential and Rotate behind a note and keeps the list and Revoke, which Core still allows.

​
Provenance and monitoring

local_only, or a public_url that is not an HTTPS origin, stops Add node from issuing a command and Clean up the host from giving one. Overview, Nodes and System then show a visible warning with Core’s configuration path and apply command as copyable values; when configuration is null, they state that the path and command are unavailable. Nodes disables Add node with a visible reason, and Getting started leaves its sandbox step to do. Wherever a new key is shown, and without any key on an active project’s page, the console gives shell exports of OPENAI_BASE_URL (the installation’s api_base_url) and OPENAI_API_KEY (the new key, or a placeholder for a key of the project), with curl and Python examples for GET /v1/agents and POST /v1/agents/sessions, and sends none of them. When the installation is local_only it says the API is reachable only on the Core machine, and without an api_base_url it says to set public_url. Summary figures are cumulative per Session and are not billing records. Sessions without reported usage count toward coverage but not toward token sums, and the console shows missing values as missing, never as zero.

​
Default models

The list carries each harness’s configuration, so the console does not read GET /core/v1/harnesses/{harness}/model-configuration.

​
Sandbox administration

An E2B deployment has no nodes; its API key is write-only. Overview and Sandbox metrics count its running and starting sandboxes from the deployment’s resources.allocations and resources.pending, while the hosted Runtime rows come from Runtime observations. The two sources refresh independently, so the console does not infer retention or cleanup from their difference. The Runtime release sent for Docker and microsandbox comes from the console’s own GET /node-install/manifest.json; without it the administrator enters the release under advanced settings.

​
Writes

  • Deletion uses the administrator API with the same preconditions as the public delete operation. Every deletion is confirmed. A 4xx keeps the dialog open with Core’s reason, a 404 counts as already deleted, and any other failure is reported as uncertain and followed by a fresh read.
  • The console offers Session deletion only for idle or failed Sessions without required actions and never cancels work to make a Session deletable.
  • Project, key, executor credential, deletion and sandbox writes are sent once per explicit action and never retried automatically. An uncertain result stays visible until the administrator reads the state again and decides.
  • An executor credential issuance with an unknown outcome (no answer, a 30-second timeout, a 5xx) opens an error dialog whose next step is Refresh list. If the kept key_id is then listed, it was issued and its secret lost: the console offers to rotate it (rotate: true) for a fresh secret, shown once. If it is not listed, the next Issue sends the same key_id with rotate: false; should that return 409 because the first request was issued after all, the console reads the list again and offers the same rotation only if the credential is listed as active in an active project, and otherwise reports the issuance as rejected. A kept key_id that is already listed is never sent again, and rotating or revoking it from its row forgets it: the next Issue generates a new key_id.

​
Read bounds

The console assembles several figures in the browser from bounded reads of each project. Session history is read in pages and polled; there is no management event stream. Agent metrics has these limits:
  • A request is one root Agent Turn; Subagent Turns and deleted Sessions are not counted. HTTP request counts, status codes and API latency are not available.
  • The model of a request comes from the Session’s Agent snapshot, not from the Session’s execution configuration.
  • Busy projects exceed the Session caps, so long ranges can be partial.
  • Usage by API key counts Sessions created in the range by their creating key; Sessions without a creation record count as Unknown.
  • Turn times up to 15 minutes after the end of the range are accepted, to allow for clock differences between the browser and Core.
Its help tips and coverage notes state what a request is and what is not counted, where the model comes from, which projects were cut short or Sessions skipped, and how usage by key is grouped. They do not mention HTTP request metrics or the clock allowance.

​
Not consumed

  • Any /v1/** route, including Session creation, Session events and their stream, message input, function results and cancellation.
  • Creation or update of Agents, Environment templates, Skills, Files, Vaults or Credentials, including uploads and Credential token replacement.
  • Single Turn reads, Artifacts, Session execution configuration, Environment Files and administrative Session archive.
  • The administrator audit log (GET /core/v1/audit-log). System shows the installation, each harness’s default model and the sandbox deployment instead.