Operator X02 brings AI coding, engineering memory, hardware deployment and safety-aware development into one open-source IDE — built on 20+ years of real embedded systems work.
Not from a product roadmap. Every feature in Operator X02 traces back to a problem we hit on a bench, with a board plugged in.
Serial debugging in a separate windowTerminal here, editor there, sensor noise scrolling past faster than you can read it.
Deploying to hardware was its own projectFlash, SSH, ADB, CUDA — five tools, five terminals, one broken step away from starting over.
AI edits that silently destroyed working codeA confident suggestion, a whole file replaced, and no way back to what compiled an hour ago.
Project context forgotten every morningExplain the architecture. Paste the board file. Re-explain why the clock is initialised before the DMA.
Tool fragmentationEditor, terminal, VCS client, serial monitor, deploy script, AI chat. Six contexts, one head.
Generic AI, safety-critical codeMISRA C and IEC 61508 are not suggestions. Most coding assistants have never heard of them.
Every one of these is a feature now. That is the whole story.
When we started this project, we wanted a name that captured its very soul. We landed on Operator. In code, an operator is the most fundamental, indispensable symbol — it doesn't create data, but all complex logic and data flow are driven by it. We wanted our IDE to play the same role: not to overshadow the developer, but to elegantly drive and amplify their every creative act.
The X stands for "experiment" and "infinite possibilities." From our first prototype X0, to our first usable version X1, and now to the open-source X02 — each number marks a milestone in our journey.
The 02 is both a tribute to all open-source pioneers and a symbol of our endless iteration — from one idea to the next, forever exploring. This isn't just software. Coding is Art.
The name is the romantic part. The reason is not: this project came from serial debugging, hardware deployment, unsafe AI edits, forgotten project context and tool fragmentation — problems we lived with for years before deciding to build our way out of them.
Three principles that guide every decision in Operator X02 — from architecture to UI to AI behavior.
Every AI edit goes through an 8-stage validation pipeline. Backups are created automatically. Destructive changes are blocked before they happen. You stay in control — always.
Anyone can generate code that looks right on screen. Operator X02 generates code that actually runs — on an Arduino pin, a Jetson GPU, a Pi serial port. AI-assisted workflows designed around voltage, timing, memory constraints and safety standards. Not web dev pretending to be embedded.
Boundless local memory means the AI knows your architecture, your patterns, your decisions — across every session. No context window. No starting from scratch. No cloud.
AI forgets.Operator X02 remembers.
Code can be regenerated. Engineering knowledge cannot. The reason a GPIO is held high through boot, the review that killed SPI eight months ago, the commit that fixed a boot race — none of it lives in your source code.
So X02 keeps it. Architecture, hardware targets, build history, design decisions, VCS state and every past conversation — captured locally, indexed, and injected into the prompt before the model ever answers. No embeddings. No cloud. No account.
Explore the Memory EngineOperator X02 is built by an independent engineering team with deep roots in embedded systems, safety-critical software, and Automotive Embedded & E/E Engineering. The features aren't guesswork — they come from real experience on real hardware.
Over 20 years across embedded E/E architecture, safety-critical software, edge AI systems, and Automotive Embedded & E/E Engineering. Every feature in Operator X02 — from MISRA C awareness to Jetson deploy — was built to solve a problem we hit on a real working day.
MISRA C, IEC 61508, functional safety, serial protocols, real-time systems — this isn't a general-purpose IDE team that added hardware support. It's an embedded team that built an IDE.
Almost every AI coding tool is an editor with AI added to it. Operator X02 is not. It is being built the other way round: a Rust runtime at the centre, with the editor as one client of it. That comes straight from automotive software, where nothing important is ever built around the tool you type in. Today it holds fully for the hardware layer and is still being worked inward for the rest — the honest status is at the end of this section.
Every capability hangs off the editor. It is the centre, so everything routes through it — and it only exists while a window is open.
The editor becomes one client among several. The runtime owns lifecycle, services and permissions — nothing depends on what is on screen.
| Editor first | Runtime first | |
|---|---|---|
| Where do capabilities live? | In extensions attached to the editor | In the runtime, as services |
| What happens when the editor closes? | ✗Everything stops with it | ✓Services keep running |
| Who owns lifecycle and scheduling? | Nobody — each extension decides | The runtime, centrally |
| Who talks to the hardware? | The extension, directly | The runtime, behind a service API |
| What stops the AI flashing firmware? | ✗Whatever the extension allows | ✓Policy, permission, confirmation, audit |
| Adding a CLI or web client? | Rebuild the integration | Another client on the same runtime |
An architecture is a direction as much as a state. This is the current split, measured from the source rather than described from the design.
So the accurate sentence is narrower than the ambition: the hardware layer is runtime-first, and the rest of the IDE is still editor-first. Moving the remaining capabilities inward is the main line of work on this project — and the reason the architecture was written down before it was finished.
Open a serial session, a terminal or a remote connection and it stays alive in the runtime, holding its own state, pushing events back to whatever client is listening. The design question isn't how to execute one prompt — it's how to start safely, recover from failure, and shut down cleanly. Vehicle software runs for years; the same thinking applies here.
The agent asks the runtime to read a serial port. It never learns whether the underlying driver is Vector, PEAK or SocketCAN — that abstraction belongs to the runtime, exactly as an AUTOSAR application never controls hardware itself. Safer, and far easier to maintain.
The model every high-risk path is being moved onto: policy, permission control, explicit confirmation and an audit trail before anything executes. It is enforced today where the AI proposes a code change — nothing is written without an explicit accept — and is being extended to firmware and hardware operations. AI should be constrained by an engineering process, not put in charge of one. That habit comes from ISO 26262.
Every technology choice was deliberate — optimized for performance, safety, and the needs of embedded developers.
Memory-safe, zero-cost abstractions, blazing fast. Ideal for embedded tooling — and we know Rust from real hardware work.
CORENative app feel, ~95MB footprint. Not Electron. Tauri uses the OS webview — keeping memory usage tiny and startup fast.
RUNTIMEType-safe UI, fast rendering, and Monaco Editor integration. The whole frontend is strictly typed — same discipline as embedded C.
UIThe same engine as VS Code. 50+ languages, IntelliSense, inline decorators for AI diff highlights — familiar, powerful, extensible.
EDITORBecause engineering tools should be inspectable, modifiable and trusted. If you cannot read what your IDE does to your code, you are trusting a promise instead of a repository.
Read the edit pipeline. Read what leaves the machine. Safety-critical teams should not have to take a vendor's word for either — and with MIT source, they don't.
Every team has one board, one toolchain, one compliance rule nobody else has. Fork it, patch it, ship it internally. No plugin API to beg for.
No account, no telemetry, no cloud tier that can be priced up or switched off. Your memory stays on your disk. The tool cannot be taken away from you.
A tool that touches safety-critical code should be readable by the engineer who is accountable for it.
Behind the scenes of building an AI IDE — our philosophy, updates, and lessons learned.
What if your IDE understood your whole project, protected your code, and never forgot a conversation? We built Operator X02 as the answer to that question.
Read on MediumArchitecture, hardware targets, build history, design decisions and every past conversation — 172+ recall triggers, ~15ms local search, no cloud. The memory engine behind Operator X02.
Explore Memory EngineEvery day, developers blindly accept AI edits that silently destroy working code. We built an 8-stage Rust pipeline that makes every edit accountable — backup first, validate, block destructive changes, recover in 36ms.
Preview the ArchitectureOther tools blindly replace whole files. Operator X02 reads your code first, then applies surgical line-level patches — three editing modes, zero destroyed code, every edit recoverable.
Explore Auto ModeA full breakdown of cross-platform support in Operator X02 — NVIDIA Jetson GPU monitoring, Arduino IoT, 28 ADB commands, Flet/Python cross-platform, Web Fullstack. How one IDE handles them all.
Explore PlatformsHow Operator X02 integrates all Android development into one session — 28 essential ADB commands, one-click APK deploy, and real-time screen mirroring.
Explore Android DevHow Operator X02 reads raw serial data from Arduino and ESP32, turns sensor noise into insights, and generates code that meets MISRA C:2012 and IEC 61508 standards.
Preview Embedded DevHow we built Phase 1&2 of Jetson support — CUDA GPU inference, a real-time tegrastats panel with sparkline graphs, and the deploy pipeline that makes an entire fleet manageable from one IDE.
Watch Dev LogEngineering scores, findings with ISO 26262 and MISRA references, root-cause analysis, JSON export and an explicit release recommendation — plus an AI that reads your board schematic and writes firmware against the real pins. Nothing is applied to your source without your confirmation.
Explore Engineering Reports為什麼我們把 AUTOSAR 的 Runtime 模型帶進 AI IDE，而不是再做一個把 AI 裝上去的編輯器。真正有價值的從來都不是程式碼本身，而是那些從來不存在程式碼裡的工程知識。
閱讀全文從 AUTOSAR Runtime 到 AI Engineering Runtime。Editor First 與 Runtime First 的差別、Service 抽象、Lifecycle、Functional Safety 對權限的約束，以及為什麼最後選擇 Rust。
閱讀全文为什么 X02 不把整个项目塞进上下文，而是像工程师一样「记住决策、按需回忆」。触发门 + 混合搜索 + 记忆衰减：172+ 触发器、~15ms 本地召回、无云端索引——一套更接近人类工程记忆的设计。
阅读全文我不希望 Operator X02 只是一个「永远不敢提出新想法的 AI」。工程创新本身就需要：探索 · 假设 · 质疑 · 组合 · 想象。
真正需要的，不是让 AI 停止想象，而是让 AI 知道自己正在想象。
阅读全文Operator X02 was not designed on a whiteboard and then built. Each layer arrived because the one before it turned out to be insufficient.
An AI chat interface for embedded work. Useful, but it knew nothing about the project it was sitting next to — every question started from zero.
Monaco, multi-provider AI, Git and SVN, and the Surgical Edit Engine — because an AI that rewrites whole files is not usable on code anyone depends on.
Arduino, Android over ADB, Raspberry Pi over SSH, camera and vision. The point where this stopped being a code editor and started being an engineering tool.
Released under MIT. Safety-critical work cannot depend on a black box, and an architecture worth arguing about has to be readable by the people arguing.
The answer to the prototype's original flaw. Decisions, architecture and history recalled locally — because the valuable part of engineering was never the code.
One prompt to a working installer, with validators and a compile gate in between. Generation is easy; a binary that actually runs is the hard part.
The serial monitor as a real service — stateful, event-pushing, with AI root-cause analysis over live device output, and a reader for schematics and datasheets.
Moving the remaining capabilities inward, so memory, search, reporting and the AI path become runtime services rather than editor features. The hardware layer is already there; the rest is the work.
So why put the effort into a runtime, rather than into a smarter editor? Because the work we care about does not happen inside a text file.
The device keeps sending. The runtime keeps listening. Nothing in that loop depends on a window being open.
Eight steps, and only the last one was planned in advance. Every other layer exists because the previous version could not do something a real project needed.
Operator X02 is actively developed. Here's what's shipped and what's coming.
Free forever. MIT license. No account, no telemetry, no cloud lock-in.