Ninglo / remotelab

RemoteLab 中文 | English **The AI workbench for super-individuals.** RemoteLab exists to maximize the efficiency of human-AI collaboration for people who already use AI seriously — and for the larger class of AI-native super-individuals that will emerge next. It does not care much whether the control surface is a phone, tablet, or desktop. The point is to give the human the highest-leverage way to direct AI work while strong executors like , , and compatible local tools do the heavy lifting on a real machine. > Current baseline: — owner-first session orchestration, durable on-disk history, executor adapters, App-based workflow packaging, and a no-build web UI that works across phone and desktop. > Reach the same system from desktop, phone, and integration surfaces like Feishu or email-driven flows. Quick install If the demo makes sense, do not keep reading. Open a fresh terminal on the host machine, start Codex, Claude Code, or another coding agent, and paste this: Need the longer version first? Jump to Setup details or open . --- For Humans Vision If you want the blunt version, RemoteLab is an AI IDE workbench for future super-individuals: people who can use AI so well that their personal leverage compounds far beyond that of a normal individual. The goal is simple: find the most effective interaction shape between humans and increasingly autonomous agents, then turn that interaction shape into a product that materially increases real-world productivity. Core judgments • Task scope keeps expanding: from minutes, to hours, to days, and eventually even week-scale work. • Concurrency becomes default: to fully use AI, people will run many agents in parallel. • Human memory becomes a bottleneck: when a task finishes hours later, the human needs fast context recovery, not raw logs. • Project orchestration becomes personal infrastructure: people need help managing priority, blockers, and follow-ups across many concurrent threads. • Super-individuals will want distribution: once a workflow works, they will want to package it and let other people use it too. What RemoteLab is • an AI workbench that sits above strong executors running on a real machine • a project and orchestration layer for concurrent agent work • an external memory / context-recovery system for long-running sessions • a packaging and distribution layer for agentic-native apps • an endpoint-flexible web product rather than a phone-only or desktop-only experience What RemoteLab is not • a terminal emulator • a traditional editor-first IDE • a generic multi-user chat SaaS • a closed all-in-one executor stack trying to out-execute or Two core product layers • **Orchestration above single-task executors.** RemoteLab helps the user manage the full portfolio of ongoing work above tools like or : more concurrency, clearer progress, faster context recovery, better attention allocation, and better final quality. • **Agentic-native app building and distribution.** RemoteLab gives super-individuals a low-friction way to turn their own SOPs into distributable agentic-native workflows — whether the surface is a built-in web UI, an external bot, or another frontend. Product grammar The current product model is intentionally simple: • — the durable work thread • — one execution attempt inside a session • — a reusable workflow / policy package for starting sessions • — an immutable read-only export of a session The architectural assumptions behind that model: • HTTP is the canonical state path and WebSocket only hints that something changed • the browser is a control surface, not the system of record • runtime processes are disposable; durable state lives on disk • the product is single-owner first, with visitor access scoped through • the frontend stays framework-light and endpoint-flexible Why this boundary matters RemoteLab is opinionated in a few ways: • **Do not rebuild the executor layer.** RemoteLab should not spend most of its energy optimizing single-task agent internals. • **Recover context, do not dump logs.** Durable sessions matter more than raw terminal continuity. • **Package workflows, do not just share prompts.** are reusable operating shapes, not just copy-pasted text. • **Integrate the strongest tools, keep them replaceable.** The point is a stable abstraction layer so better executors can be adopted quickly as the ecosystem evolves. What you can do • start a session from phone or desktop while the agent works on your real machine • keep durable history even if the browser disconnects • recover long-running work after control-plane restarts • let the agent auto-title and auto-group sessions in the sidebar • paste screenshots directly into the chat • let the UI follow your system light/dark appearance automatically • create immutable read-only share snapshots • create App links for visitor-scoped entry flows Provider note • RemoteLab treats ( ) as the default built-in tool and shows it first in the picker. • That is not because executor choice is the product. The opposite is true: RemoteLab should stay adapter-first and integrate the strongest executors available locally. • API-key / local-CLI style integrations are usually a cleaner fit for a self-hosted control plane than consumer-login-based remote wrappers. • still works in RemoteLab, and any other compatible local tool can fit as long as its auth and terms work for your setup. • Over time, the goal is portability across executors, not loyalty to one closed runtime. • In practice, the main risk is usually the underlying provider auth / terms, not the binary name by itself. Make your own call based on the provider and account type behind that tool. Setup details The fastest path is still to paste a setup prompt into Codex, Claude Code, or another capable coding agent on the machine that will host RemoteLab. It can handle almost everything automatically and stop only for truly manual steps such as Cloudflare login when that mode is in play. Configur…