Ithacaby New OdysseyEarly access

Cloud computers for AI agents

A computer for
every agent.
Control for you.

Isolated Linux environments, with approval before the actions that matter. Built for teams connecting agents to real systems.

Request early access Explore the runtime

In development. UK hosting is planned, subject to provider validation.

ITHACA / BY NEW ODYSSEYRUN → APPROVE → REVIEW

01 / The runtime

Give agents a place
to do real work.

A workspace for the run.
A boundary around its actions.

Ithaca is being built to bring agent compute and action approvals into one developer experience. Launch a machine, run your tools, and decide which actions need a person.

Read the developer brief
Proposed execution modelOne run, from workspace to outcome
01 / YOUR CODE

Your agent

Code, tools & dependencies

02 / ITHACA

Linux workspace

Isolated compute for the run

03 / CONTROL

Approval boundary

Allow, hold or deny the action

04 / YOUR SYSTEMS

Protected tools

Repository, API or service

Run identityRequested actionReviewer decisionExecution outcomeA connected record

02 / Human control

Let the agent work.
Choose when it must ask.

Isolation gives the agent an environment. Approval checks govern its access to the systems outside it.

Example action policy Illustrative
Run tests in the workspaceAllow
Push to the production branchApproval
Issue a customer refundApproval
Use an unapproved credentialDeny

Planned controls apply at protected tool boundaries. In-VM root access must not provide a route around them.

Keep the authority outside the agent.

The intended design keeps privileged tool credentials with a trusted executor. The agent proposes an action; policy and approval determine whether it runs.

Make the decision inspectable.

Connect the run, requested action, reviewer and outcome. Define what is captured and retained before a workload goes live.

Explore the Remus permissions layer

03 / Developer workflow

From machine to outcome.

One proposed workflow, designed around an API, SDK and CLI.

  1. 01

    Launch

    Create an isolated Linux environment for the run.

  2. 02

    Run

    Bring your coding agent, tools and dependencies.

  3. 03

    Approve

    Hold protected actions until the right person says yes.

  4. 04

    Review

    Connect the action, approval and outcome in one record.

LAUNCH SCOPE

Create, run, stop and snapshot Linux environments. SDK and CLI contracts, SSH access and provider support are still being validated.

See the scope

04 / Use cases

For agents with work to do.

Start with one workload and a clear approval boundary.

01

Coding agents

Let it write the code. Keep control of the release.

Give an agent room to inspect a private repository, make changes and run tests. Put approval at the merge or deployment boundary.

01Repository
02Agent workspace
03Review
04Deploy
02

Operational agents

Put a human decision before a production change.

Let an agent prepare a database update, refund or customer message. Require sign-off before the protected system executes it.

01Request
02Prepare action
03Approval
04Execute
03

Platform teams

Make the execution path clear to everyone.

Define the environment, tool access and review requirements together. Give engineering and security a shared record to inspect.

01Identity
02Policy
03Environment
04Run record

Deployment direction

A UK region.
A clear data boundary.

We’re planning a UK launch for teams that need to know where their agent compute and run records live.

Region, providers, log storage and retention will be confirmed before pilot deployment. UK residency is a launch objective, not an available guarantee.

Review the deployment scope
UNITED KINGDOMPlanned launch region
ITH / REGION 01

Pricing

Usage-based.
Defined before you commit.

A monthly minimum, with compute metered while your environment runs.

That’s the proposed billing model. Rates, VM sizes, storage charges and trial terms will be confirmed before access opens. No card or payment is collected today.

View the pricing plan

Also by New Odyssey

One direction. Distinct layers.

Ithaca is the proposed compute layer. Explore the projects being developed alongside it.

RemusPermissions & approvalsLocal developer previewRomulusWorkflow recoveryLocal developer previewDaidonModel evaluation & fine-tuningIn development

An integrated stack is the direction. A shared SDK, trace and billing experience are not available yet.

Good to know

Before you build on it.

Can I create a machine today?

Not yet. Ithaca is in development. Early-access enquiries help define the first workloads and pilot requirements; they do not provision compute or guarantee a launch date.

Which environments are planned?

The initial scope is Linux CPU environments. GPUs, Windows, macOS and desktop streaming are outside the initial plan. VM sizes and the isolation runtime are still being selected.

Are approvals built into every command?

The proposed design checks protected actions at trusted tool boundaries. It does not claim to intercept every shell command or make arbitrary root-access code safe. Credential and network boundaries must be validated for each integration.

Are there security certifications or performance benchmarks?

No Ithaca certifications or measured performance claims are published. Isolation, logging coverage, recovery behaviour and data-location commitments must be tested and documented before pilots.

Build with us

Bring the agent.
Define the boundaries.

Tell us what you want to run, what it can access, and where a person needs to approve.

Discuss early access