Cloud delivery

Put delivery, hosted runtime, and access control in Cloud

Studio is where the tool gets built and validated. Cloud is where delivery happens, with hosted runtime, configuration, and access handled in one place, then used mainly through oo-cli by agents.

Delivered through oo-cliHosted runtimeSecretsAccess control
Why Cloud after Studio

Studio handles building. Cloud handles delivery.

Once the tool works locally, what slows launch is usually not the logic itself but everything around it: hosted runtime, access control, secrets, and delivery. Cloud exists to shrink that layer.

Delivery layer

Stop building another backend around the same implementation

Cloud takes over delivery, configuration, access, and runtime so you do not need a separate publishing backend wrapped around the same tool.

  • Deliver it mainly through oo-cli for agents
  • Avoid building a separate user and admin layer
Hosted layer

Let Cloud handle runtime, access, and permissions together

Users still access the tool mainly through oo-cli. When you need API, MCP, or automation endpoints, you can add them through the same Cloud setup while the implementation stays on the server.

  • Less ops and permission work to manage
  • Deliver first, then expand with real usage
01 / Cloud

Keep delivery, hosted runtime, config, and access in one backend

Once the tool is validated, Cloud takes over delivery and keeps hosted runtime, runtime settings, secrets, and access control in one place. By default, the tool is still delivered mainly through oo-cli.

Deliver it mainly through oo-cli while keeping the same implementation

Once the tool is delivered, agents still use it mainly through oo-cli instead of through a separate service layer built around it.

Manage config and secrets together

Keep runtime settings, secrets, and environment differences in one console.

Review access, status, and usage in one place

Manage permissions, runtime status, and usage data without splitting them across tools.

Cloud console preview

Cloud console preview

Keep delivery, runtime settings, secrets, and access control in one backend.

DeliveryRuntime settingsSecretsAccess control
02 / oo-cli

After delivery, agents still use it through the oo-cli path

For the user, there is no need to understand your implementation or learn a new workflow. Once delivered, they still search, inspect, and use it through oo-cli. APIs, MCP, and automation remain optional ways to use the same tool.

oo-cli invocation demo

Shows a delivered tool being searched, inspected, and called in Codex.

Included Usage

Start delivery with the included free quota

Free users get 200 Cloud Task minutes refreshed every month. Use them to deliver the tool through Cloud first, then top up or upgrade when the quota is not enough.

Free quota
Included Monthly
200 min
Included Cloud Task time

Deliver the tool and start using it

Use the monthly refreshed quota to deliver the tool, confirm it keeps running, and make sure it is searchable and callable in oo-cli.

A good fit for first delivery, lightweight jobs, and everyday trial use.

Usage-based
Time-based billing
By runtime
How Cloud Task is billed

Pay by runtime as usage grows

You do not need to buy servers or reserve fixed capacity up front. Pay for actual call time only after the included quota runs out, and expand only when demand grows.

Start with the included quota, then scale only when you need to.

Let Cloud take over validated tools

Use Cloud to handle delivery, hosted runtime, configuration, secrets, and access control, then keep the tool flowing mainly back into oo-cli.