What Fleet is
Fleet by Oracis is an independent engineering runtime for AI-assisted teams. Its workstation runtime carries bounded engineering workers, repository intelligence, research, review and repair, browser tools and missions; Oracis uses it every day. Its hosted service, which this page documents, is what an invited organization connects to: eight tools for jobs, independent validation, published checks and lessons. The capabilities page says which capability runs where.
Independent validation runs the repository's own verification policy against the exact commit, in a VM that exists only for that run. The result is a signed receipt; a separate publisher turns a receipt into a GitHub check, when a person asks it to.
GitHub remains where your code, pull requests and checks live. Fleet fetches read-only, runs checks on its own runners, and posts the result as a check through its own GitHub App. Nothing in Fleet pushes to your repository.
Fleet is a remote server for the Model Context Protocol (MCP). It is designed for any client that speaks the protocol. Today Claude Code is proven; Claude.ai, ChatGPT and Codex are designed for but not yet demonstrated (see Status).
Concepts
- Organization
- The unit of tenancy. Everything Fleet stores belongs to one organization, and one organization can never read another's jobs, validations, receipts or repositories.
- Member and role
- A person in an organization, identified by a verified email. Roles are member, admin and owner; the role decides the scopes below.
- Repository connection
- A github.com repository an organization owner has attested control of. A connection is made by the operator during the pilot and never moves between organizations.
- Verification policy (profile)
- The commands Fleet runs for a repository and the caps each lane gets. It is read from the repository's default branch, so a candidate commit cannot change its own policy: a commit that touches the policy's launcher files is refused as
policy_changed. - Job
- A bounded piece of engineering work with a spend ceiling in cents, admitted in one transaction with its reservation. It runs after you disconnect and survives a service restart.
- Validation and receipt
- A run of the policy against one exact commit. Each lane runs in its own VM. The receipt is a signed envelope that identifies the source, the policy and what the runner observed.
- Publication
- The publisher verifies a receipt against its pinned validator keys and posts a check-run on the commit. The check carries counts and ids only.
Connecting
The endpoint is a Streamable HTTP MCP server. A call without a bearer token is answered 401.
https://fleet-api-fleet-api.up.railway.app/mcp
The current endpoint. A fleet.oracis.ai endpoint follows a separate, tested cutover; connections made to this address keep working for at least 14 days after it.
Sign-in uses OAuth 2.0 authorization code with PKCE (S256). Fleet's identity provider is Supabase Auth's OAuth 2.1 server; the consent page is Fleet's own. It shows the client asking, the host it will return you to, your identity, your organization and the exact scopes, and you approve or deny.
- Add Fleet in your client.
Paste the endpoint as a remote MCP server or custom connector. Client-specific steps: Claude, ChatGPT and Codex.
- The browser opens the consent page.
Sign in with your email and password, or ask for an emailed sign-in link and return to the same tab.
- Read what is being asked.
The client's name, the redirect host (a loopback address means a program on your own machine), your email, your organization and the scopes.
- Approve or deny.
Approve returns you to the client with an access token bound to that client. Deny returns an error and nothing is issued.
- Call a tool.
Your client lists the tools below. Read tools change nothing; write tools create, cancel or publish something and your client may ask you to confirm each one.
Where discovery stands. Today the 401 does not point at OAuth metadata and the server publishes no protected-resource document, so a hosted client cannot find the issuer from the endpoint alone. Claude Code's loopback flow is proven; the hosted Claude.ai, ChatGPT and Codex flows are unproven until the readiness work lands (see Status).
Tools
The hosted server exposes exactly 8 tools. None generates images, video or audio. The kind column is the truth from the code; the server does not yet publish readOnlyHint and destructiveHint annotations, and when it does they will say the same thing.
| Tool | Kind | Scope | What it does | Status |
|---|---|---|---|---|
job_submitSubmit a job |
write | jobs:write | Admits a bounded engineering job for a connected repository with a spend ceiling in cents. Returns a durable job id at once; the job runs after you disconnect. | Implemented |
job_statusRead a job |
read | jobs:read | The state and event log of one job in your organization. A job in another organization answers not found. | Implemented |
job_cancelCancel a job |
write | jobs:write | Cancels a queued or running job. A running worker is fenced out at its next lease renewal. | Implemented |
validate_submitValidate a commit |
write | repositories:write | Runs the repository's verification policy against one exact commit on an independent runner, each lane in its own VM. Returns a validation id. | Implemented |
validate_statusRead a validation |
read | repositories:read | The lanes, their outcomes and the signed receipt of one validation your organization submitted. | Implemented |
publish_requestPublish a receipt |
write | repositories:write | Asks the publisher to verify a receipt against its pinned validator keys and post it as a GitHub check-run on the commit. The check carries counts and ids only. | Implemented |
lessons_forLessons for this work |
read | jobs:read | At most three lessons Fleet has recorded for work like yours in this repository. The task text you send is matched, not stored; the retrieval is recorded. | Implemented |
lesson_confirmConfirm a lesson |
write | jobs:write | Records whether a lesson you were shown held or did not, so the next retrieval is better ranked. | Implemented |
Permissions and scopes
Fleet defines six scopes. A member holds the first four; an admin or owner holds all six. The consent page lists the scopes a client asks for. Enforcement per tool is coarse today: a token that passes the identity checks can call any tool its role allows.
| Scope | Meaning | Roles |
|---|---|---|
jobs:read | Read jobs, their events and lessons in your organization. | member, admin, owner |
jobs:write | Submit and cancel jobs; confirm lessons. | member, admin, owner |
repositories:read | Read validations and receipts for connected repositories. | member, admin, owner |
repositories:write | Submit validations and request publication. | member, admin, owner |
artifacts:read | Fetch job artifacts through short-lived download links. | member, admin, owner |
members:write | Invite, revoke and manage members. | admin, owner |
A token is accepted only if its signature, issuer, audience, expiry and not-before check out, its client is on Fleet's allow-list and its email is verified. A Fleet session lasts 8 hours; artifact download links last 15 minutes by default and at most 1 hour.
Data handling, in short
- Your account: email, user id, role and organization. Fleet-issued tokens are stored only as hashes; your identity provider's access tokens are verified, never stored.
- Your source: fetched read-only into a mirror on the validator, copied as an archive of the exact commit into a single-use VM, and the VM is destroyed. The mirror persists; a retention period is not yet defined.
- Model requests: the API itself calls no model. A job's model calls go through OpenRouter with data collection set to deny on every request.
- Logs: no per-request log and no IP address in the application; unexpected errors carry a reference id you can quote to support.
- Retention: no automated deletion exists yet. Deletion is on request through support until the schedule ships.
The full inventory is the privacy policy; the third parties are on Subprocessors; the controls are on Security.
Limits
- Job budget: 1 to 2,000 cents per job; at most 10,000 cents in flight per organization by default. The hosted cap starts at zero until the operator sets it, so a submission before that answers
over_cap. - Requests: a 1 MiB body, 30 seconds for headers, 60 seconds in all.
- Validator: 2 validations at once and a queue of 20 by default; beyond that a submission is refused, not silently queued.
- Receipts: valid for at most 168 hours from issue.
- Rate limiting: none yet beyond the bounds above.
Troubleshooting
- 401 on every call
- No bearer token reached the server, or it expired (8 hours). Reconnect from your client so the consent page runs again. A token issued to a different client id is refused on purpose.
- The consent page says to open it from the client
- It was opened without an
authorization_id. Start the connection from your client; it opens the page with the right parameters. - The emailed sign-in link opened in another browser
- The link returns to the same page it was requested from. Open it in the browser where the consent tab is waiting, or start again from the client.
validator_unavailable: … (ref abc12345)orpublisher_unavailable- The private service did not answer. Nothing was run. Quote the
refto support; it names the exact log line. over_cap- Your organization's spend ceiling, or the fleet-wide cap, would be exceeded. Lower the budget or ask an owner.
policy_changed- The candidate commit changes the verification policy's launcher files, so it cannot be judged by its own policy. Land the policy change first, from the default branch.
- A lane is
incompletewithvm_destroy_unconfirmed - Fleet could not confirm the VM was destroyed and refuses to call the lane passed while the VM may exist. Resubmit; if it repeats, contact support.
- Not found, for something you know exists
- It belongs to another organization. Fleet answers not found rather than confirming existence across tenants.
Status
Each hosted capability and journey, with its status. The source is the Fleet readiness audit and live checks of 27 September 2026.
| Capability | Status | Note |
|---|---|---|
| Hosted MCP endpoint (Streamable HTTP, stateless) | Proven live | 401 on every call without a bearer token. |
| Sign-in through the consent page from Claude Code (loopback callback) | Proven live | A real Claude Code session signed in on 27 September 2026. |
| OAuth discovery from the endpoint (401 with resource_metadata; protected-resource metadata) | Planned | Today a connector cannot find the authorization server from the endpoint alone. |
| Sign-in from Claude.ai and Claude Desktop (hosted callback) | Unproven | Depends on discovery and on registering the hosted redirect URI. |
| ChatGPT connector | Unproven | Not yet demonstrated. |
| Codex (bearer from the sign-in helper) | Unproven | Configuration documented; not yet demonstrated end to end. |
| Tool annotations (title, readOnlyHint, destructiveHint) | Planned | Not yet published by the server; this page states each tool's class from the code. |
| Per-tool scope enforcement | Planned | Scopes exist and roles map to them; enforcement per tool is coarse today. |
| Member profile (whoami) tool | Planned | A view of your organizations, roles and repositories. |
| Hosted jobs (submit, read, cancel) | Implemented | On the live tool list; not yet demonstrated end to end for a customer. |
| Independent validation of a customer commit | Implemented | On the live tool list; not yet demonstrated end to end for a customer repository. |
| Publishing a receipt as a GitHub check | Implemented | On the live tool list; not yet demonstrated for a customer repository. |
| Lessons for similar work | Implemented | Deployed; the first real call, 27 September 2026, answered with a defect Fleet is fixing. |
| Self-serve invitations | Planned | Today the operator provisions accounts. |
| Reviewer account with sample data | Planned | Follows the profile and invitation tools. |
| Retention and deletion schedule | Planned | Design milestone F4; deletion on request through support meanwhile. |