Skip to content
Lightcone Lightcone
Try out in chatDeveloper dashboardLogin
Guides
Lightcone vs. DIY computer use

Lightcone vs. DIY computer use

Frontier computer use APIs give you a model. Lightcone gives you the model plus the managed environments, so you can skip the Dockerfile.

“Won’t OpenAI or Anthropic computer use just do this?” It’s the right question to ask, and the answer comes down to what each API actually ships.

The frontier labs’ computer-use APIs give you the model: send a screenshot, get back an action. Everything around the model is yours to build. Their own documentation is upfront about this. The guides start with instructions to prepare a sandboxed environment yourself, and the reference implementations (a Dockerized desktop, a Playwright loop, an Xvfb display) are labeled as demos, not production infrastructure. That’s a reasonable scope for a model API. It just means the model is only one part of a working system. The environment, scaling, persistence, and observability around it are yours to build.

Lightcone ships the rest too: the model and the managed environments, behind one API.

What “DIY” actually means

Section titled “What “DIY” actually means”

Here is the checklist you own if you build on a model-only API, next to the Lightcone equivalent:

You buildLightcone equivalent
A sandboxed environment: Docker image, Xvfb or a browser under Playwright, networking, security hardeningclient.computers.create(kind="browser"), a cloud VM ready in seconds
The screenshot loop: capture, encode, send, parse the actionResponses API returns actions; Tasks runs the whole loop for you
An action executor: translate model output into real clicks, keys, scrollsBuilt-in actions API: click, type, scroll, hotkey, navigate
Login persistence: volume mounts, cookie export, profile managementpersistent: true saves and restores session state
Scaling: an orchestrator to run N environments in parallelCreate N sessions; they’re independent cloud computers
Observability: VNC setup or frame capture to see what the agent didLive view and screencast endpoints on every session

None of the DIY items are impossible. They’re just infrastructure work that has nothing to do with your product, and the demo scaffolding you’d start from was never meant to carry production traffic.

One API instead of a Dockerfile

Section titled “One API instead of a Dockerfile”
from tzafon import Lightcone


client = Lightcone()


# describe the task and stream progress
for event in client.agent.tasks.start_stream(
    instruction=(
        "Go to https://news.ycombinator.com, find the top story, "
        "open it, and summarize the page in three bullet points."
    ),
    kind="browser",
    max_steps=15,
):
    print(event)
import Lightcone from "@tzafon/lightcone";


const client = new Lightcone();


// describe the task and stream progress
const stream = await client.agent.tasks.startStream({
  instruction:
    "Go to https://news.ycombinator.com, find the top story, " +
    "open it, and summarize the page in three bullet points.",
  kind: "browser",
  max_steps: 15,
});


for await (const event of stream) {
  console.log(event);
}

That’s the fully managed path: environment, model loop, and action execution in one call. If you want to own the loop, injecting custom logic or guardrails between steps, use the Responses API with a computer session you control. Same infrastructure, your loop.

What the managed environments give you

Section titled “What the managed environments give you”
  • Fast provisioning. Browser and desktop VMs spin up in seconds, not the minutes a cold container build takes.
  • Persistence and snapshots. persistent: true keeps logins, cookies, and installed software across sessions. Set up an environment once, reuse it forever.
  • Session reuse. Point a new task at an existing environment with environment_id instead of rebuilding state.
  • Live view and screencast. Watch the agent work in real time, or record the session. No VNC to wire up.
  • Fleets. Run dozens or hundreds of parallel sessions with a for-loop. Scaling is a number, not an orchestrator you operate.
  • Two kinds of machine. kind="browser" for web work, kind="desktop" for a full OS with native applications (Lightcone OS).

Cost per step

Section titled “Cost per step”

Computer use is screenshot-heavy: every step sends a full image to the model, so per-token pricing compounds fast. General frontier models are priced for general intelligence. Northstar CUA is purpose-trained for computer use and priced accordingly: -e.50 per million input tokens and .50 per million output tokens. For a loop that processes a screenshot every step, that’s typically much cheaper per action than running the same loop on a general-purpose frontier model, and the specialized training tends to show up as fewer wasted steps. Exact savings depend on which model you compare against and your task mix, so see pricing for the rates and run your own numbers.

When to DIY

Section titled “When to DIY”

There are legitimate reasons to build the stack yourself. If you need a specific frontier model, say your evaluation shows Claude or an OpenAI model performs better on your domain, a model-only API plus your own environments is the way to get it. The same goes for a hard on-your-own-infra requirement: if policy says the VMs must run in your VPC or on-premises, a managed environment is off the table regardless of how good it is. And if computer use is your core product rather than a feature, owning the whole stack may be worth the engineering.

For everyone else, the infrastructure is undifferentiated work between you and shipping. Skip the Dockerfile.

Next steps

Section titled “Next steps”