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.
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.
Cloud takes over delivery, configuration, access, and runtime so you do not need a separate publishing backend wrapped around the same tool.
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.
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.
Once the tool is delivered, agents still use it mainly through oo-cli instead of through a separate service layer built around it.
Keep runtime settings, secrets, and environment differences in one console.
Manage permissions, runtime status, and usage data without splitting them across tools.
Keep delivery, runtime settings, secrets, and access control in one backend.
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.
Shows a delivered tool being searched, inspected, and called in Codex.
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.
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.
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.
Use Cloud to handle delivery, hosted runtime, configuration, secrets, and access control, then keep the tool flowing mainly back into oo-cli.