The working Oneira prototype uses two ESP32-S3 processors because its expressive face and its owner-triggered camera have different jobs. One processor runs the display-side behavior and local neural mood engine. The other handles the real camera and vision path. This is a prototype architecture report, not a promise that every production component or camera-module specification is final.
Start with the behavior that must remain local
Oneira's core character should not disappear when a network is unavailable or a connected service is not configured. In the working prototype, eight motion features feed a small neural network on the display-side ESP32-S3. Five outputs blend animated moods on the device. That bounded local system is responsible for the immediate relationship between movement and expression.
Keeping the face and mood engine on the display-side processor gives that loop a clear boundary. Motion input, neural output, and animation blending can continue without turning every reaction into a cloud request. It also makes the product easier to explain: local expression is one layer; optional connected work is another.
Give the camera path its own processor
The second ESP32-S3 serves the working prototype's real camera and vision path. Camera capture, image handling, and the display's continuous animation do not have identical timing or memory needs. Separating them prevents camera work from becoming the only thing the device can do and keeps the face-side system focused on responsive character.
The processors exchange bounded vision packets and image strips over the prototype's local link. That detail matters because it describes a real interface instead of a vague claim that two chips somehow make the product more powerful. The architecture assigns ownership: the camera side handles its path, while the display side owns expression and presentation.
Design failure boundaries before feature lists
A useful hardware boundary answers what happens when one subsystem is unavailable. In this prototype, camera failure does not remove the core face. That is a more meaningful design goal than maximizing a specification list, because Oneira's basic physical character can remain understandable even when the camera path or a connected provider cannot complete a request.
The same principle shapes owner-triggered Sight. A capture begins with a deliberate action; it is not described as background recording. Connected replies and configured services have their own availability, permission, and provider boundaries. Two processors do not erase those boundaries. They make the local responsibilities easier to isolate.
What the architecture does not prove
A working dual-processor prototype does not prove final dimensions, weight, battery runtime, charge speed, thermal behavior, or the final production camera module. Those details require production design and validation evidence. The final camera-module specification and other non-material production details may change before fulfillment.
It also does not mean every AI task runs on the two microcontrollers. The neural mood engine runs locally. Broader model, agent, image, and MCP work can involve owner-configured connections, compatibility requirements, and third-party terms. The accurate claim is specific: Oneira has a real local expression system and a real second-processor camera path in the working prototype.
Why this matters to a Founding Unit buyer
The current $80 Founding Unit inclusion is explicit: one Oneira device with its local neural mood engine, real camera, and second ESP32-S3 vision processor, plus the selected color and included eye set. Shipping and applicable tax are separate. The final camera module and non-material production specifications may change, but the camera and second processor are not merely concept-art accessories.
That distinction is the practical reason to publish this build log. Buyers should be able to separate demonstrated architecture, included hardware, connected-beta behavior, and future work. Makers should be able to see the constraint that led to the split without being asked to accept unsupported benchmark or performance claims.
The short version
- The display-side ESP32-S3 owns local motion-driven expression and mood blending.
- The second ESP32-S3 owns the working prototype's real camera and vision path.
- The split creates a failure boundary: camera failure does not remove the core face.
- Prototype evidence does not lock final camera-module specifications or unsupported performance metrics.
Official buyer resources
Read the promise before you pay.
See what is local, prototype, connected beta, and still in development.
See the campaign story and the claim boundaries around its visualizations.
Check live availability, included hardware, and the current order summary.
Read how an owner-triggered frame is handled.
Continue the buyer path
turn the answer into a decision.
questions, answered.
Does Oneira need the internet to react to movement?
No. The working prototype's motion features, small neural mood engine, and animated mood blending run on the display-side ESP32-S3. Optional connected services have separate requirements.
Does dual ESP32-S3 mean all Oneira AI runs locally?
No. The neural mood engine runs locally. Broader model, image, agent, and MCP work can use owner-configured connections and third-party providers; not every AI task runs on the device.
Are the camera and second processor included in the Founding Unit?
Yes. The $80 Founding Unit includes the real camera and second ESP32-S3 vision processor. The final camera module and non-material production specifications may change before fulfillment.
Is this the final production board design?
This article documents the working prototype architecture. It does not claim that the final board layout, camera module, dimensions, battery behavior, or other unfinished production specifications are locked.