A Studio + CLI workflow for developers

Write Function. Deliver Service.

Write functions in Studio, validate them locally, then publish them to OOMOL Cloud. After that, sign in with the OOMOL CLI so Codex or Claude Code can call those cloud functions directly, while the same capability remains available as an API, MCP tool, or automation task.

Apple Silicon Mac only

CLI QUICKSTART

Install oo-cli, sign in once, then start calling published functions.

Install the CLI, then get the first search and run working.

Install oo-cli

Set up the CLI entry point.

Sign in to your account

Run oo login.

Search and run a published function

Search, then run.

Open CLI Quickstart See How Cloud Delivery Works

INSTALL ONCE

Two commands to install and sign in

30 sec

Install once, then use it directly.

$ bun install -g @oomol-lab/oo-cli$ oo login

FIRST RUN DEMO

Compress the first run into search, inspect, and run

Usage Flow

Show the first successful path directly.

Search in natural language

$ oo search "generate a QR code"

Inspect

Check package info

$ oo package info foo/bar@latest

Run

Run and fetch result

$ oo cloud-task run foo/[email protected] --block-id main --data '{"text":"OOMOL"}'$ oo cloud-task result <task-id>

A Studio Built for Real Developer Work

A real coding environment where AI helps generate functions, validate them locally, and deliver them as APIs, MCP tools, or automation tasks.

What we want is not another tool that asks developers to adapt to the platform, but a working environment where you can actually write functions, orchestrate nodes, debug dependencies, and validate results.

"Why do I have to learn a proprietary JSON syntax just to write an if/else statement?"

"Why can't I just import a library? Why do I have to wait for the platform to support it?"

"Why am I coding in a textarea with no autocomplete?"

For developers, the real problem is rarely whether something can be dragged visually. The moment delivery becomes real, you still end up dealing with code, dependencies, debugging, and environment control.

So Studio has a clear role: not to replace engineering workflow, but to bring function generation, local validation, and delivery back inside it.

1. Nodes Are Functions. Flows Are Composition.

Studio does not introduce a new definition language. It organizes standard code into runnable capabilities.

In OOMOL, a node is still backed by a function. Inputs are arguments, outputs are return values.

You are not configuring a black-box platform. You are writing code that stays maintainable and ready for delivery.

2. Do Not Downgrade Your Developer Experience

Visual tooling should not come at the cost of a worse developer experience.

That is why each function unit keeps the editing, completion, typing, and debugging capabilities developers already rely on.

AI, code, and the toolchain need to work together instead of forcing you to switch contexts.

3. Match Local and Cloud Environments Early

The hard part of function delivery is often not writing the code, but controlling dependencies, environment, and runtime behavior.

Studio uses standard containers to keep those concerns in one place.

Install what you need, run the result locally, then carry the same capability forward as an API, MCP tool, or automation task.

Why Delivery Breaks

The real cost starts after the function works.

Once you want a capability to be called reliably by AI, APIs, and automations, the work that grows is usually wrapping interfaces, aligning environments, shipping to production, and keeping the whole path stable.

Function Done. Backend Work Begins.

The implementation already exists, but publishing it as an API or task still means rebuilding interfaces, deployment steps, and runtime wrappers.

Local Runs Do Not Guarantee Delivery

Development, dependency, and deployment environments drift apart. The problem is often not the code itself, but whether it still holds once it leaves your machine.

One Capability Gets Wrapped Repeatedly

Teams often wrap the same implementation separately for APIs, MCP tools, and automation tasks, multiplying delivery cost without adding capability.

Cloud keeps the function running reliably online

If Studio is where you write the function, then OOMOL Cloud is the shared runtime and delivery layer. After sign-in, the CLI calls the cloud functions deployed there from Codex or Claude Code.

Launch faster, manage less

Cloud

Turn a validated function into a shared online capability for CLI, APIs, and automation without rebuilding interfaces, runtimes, and scaling layers.

For developers and small teams that want to provide functions reliably to AI tools, applications, or automation tasks.

Explore OOMOL Cloud

Reuse the implementation you already validated in Studio while OOMOL Cloud handles runtime, auth, and external delivery. The CLI signs in and calls the cloud functions from this layer.

Delivery Targets

The same validated function can keep shipping as an API, MCP tool, or automation task, acting as one stable capability layer for both AI tools and applications.

API Services

Expose the function directly as a callable API without building a separate service framework or runtime layer.

MCP Tools

Let the same implementation enter the call chain of agents and AI apps directly instead of maintaining a second tool service.

Automation Tasks

Turn the same implementation into scheduled jobs or automation flows so online runs and later iteration keep reusing one capability.

Delivery Overhead

Less service rebuilding

Cloud takes over the online runtime and delivery layer so you do not need to rebuild another interface stack around the same function.

Runtime Overhead

More stable online usage

Stay focused on the function itself instead of spending more time on environments, scheduling, scaling, and production maintenance.

Real Use Cases

This Studio -> Cloud -> CLI path already runs in real products

pdf.oomol.com shows that OOMOL is not only about making a function work locally. The same capabilities are published to Cloud first, then carried into web tools, desktop apps, CLI usage, and online services that already serve real users.

Live Project

pdf.oomol.com

This is not an internal demo. It is a live product that actively delivers PDF and publishing tools to end users.

Multiple Scenarios

Convert / Translate / Generate

The same project already ships PDF conversion, EPUB translation, and manga translation with colorization, not just a single isolated page.

Underlying System

OOMOL Functions / Cloud / CLI

These capabilities are not rebuilt as separate backends. They are delivered as real services through the same Studio, Cloud, and CLI path, and the CLI calls the cloud functions after sign-in.

Live Scenario 01

Live PDF Conversion Tool

This is a live web tool, not a showcase page. Users can upload PDFs and get EPUB or Markdown output through the same OOMOL delivery system.

View Web Tool

Live Scenario 02

Desktop Shelf and Library

The same project does not stop at browser conversion. It continues into a desktop app for managing a library and carrying those outputs into real usage.

View Desktop App

Live Scenario 03

Desktop Reading Interface

Delivery does not end at file output. The result keeps moving into a real reading interface where it can be opened, browsed, and managed.

View Reading Experience

A function you wrote once should keep paying off

A function should not stay trapped in one project. After publishing, it can come back into local work, plug into AI workflows, or become the base capability behind future services.

Reuse What You Already Built

Bring published functions back into your own environment so you do not have to start from scratch the next time.

Build Your Own Function Library

Each release leaves behind reusable capabilities that gradually become your own function library.

Compose New Services from Existing Ones

Keep extending published functions and recombining them into new products and services.

Developer Benefits

Get the path working before you optimize cost

Keep the pricing discussion later. First remove the blockers around model access and lightweight task validation so the Studio-to-CLI-to-production loop is easier to complete.

Studio Benefit

Recommended

GLM-5

Use your own model

Use Your Own Model and Start at Lower Cost

OOMOL Studio lets you configure your own AI model. If you already have model quota elsewhere, you do not need another paid model service just to get local development running. We currently recommend GLM-5.

If you already have model quota, the setup guide is usually enough to get Studio running and finish local validation.

View Setup Guide

Cloud Benefit

Monthly Included

200 Minutes

Free Cloud Task time

200 Free Cloud Task Minutes Each Month for Lightweight Jobs

We give developers 200 minutes of Cloud Task usage every month. For scheduled jobs, lightweight automation, and validation flows, that is often enough to get real online tasks running.

For a lightweight app or workflow, the free quota is often enough to get tasks running before you pay anything.

Explore OOMOL Cloud

Start with your next function and let AI use it

Download OOMOL Studio, write and validate your function locally, publish it to OOMOL Cloud, then sign in with the OOMOL CLI to use it from Codex or Claude Code, or keep delivering it as an API, MCP tool, or automation task.

Apple Silicon Mac only