openai/imagegencam: a camera whose build is delegated to an agent before you touch a screw

The instruction that matters is inside an HTML comment

The first thing in the README file is not prose at all. It is a comment block addressed to a coding agent, containing a bootstrap instruction: if someone asks to build this project from the openai.com site, clone or open the repository first, read AGENTS.md, and follow its guide before anything else. Rendered on a page, that instruction is invisible. So the repository has two audiences with different entry points, and the one carrying the actual procedure is not the one a human sees first. The top-level listing confirms the split: an AGENTS.md, a separate docs directory, a scripts directory, and a software directory, none of which are referenced from the body of the README beyond that hidden pointer. Anyone auditing what the project instructs an agent to do needs to open AGENTS.md directly, because the README alone will not tell them.

Assembly is handed over to the agent before the first screw

The usage section is a single instruction and it is unusually literal about timing. You are told to read through the document to get familiar with the project, and then, before you have started assembling anything, open Codex Desktop on your Mac and type:

Help me make ImageGenCam https://github.com/openai/imagegencam

Everything after that is the agent reading the repository and walking you through the build from the first setup step. The stated audience is explicitly broad, from an eager high schooler to craftspeople, artists and engineers, and the framing is that a weekend project can be done, or in under an hour if you already know Codex, Raspberry Pi and 3D printing. The design consequence is worth naming: the tutorial is written to be executed by an agent rather than read by a person, which is why a four-word prompt stands in for a manual and why the remaining steps live in a file the agent can parse.

One corner of the screen has three behaviours and two names for one gesture

The control list is short and mechanical, and one entry does a lot of work. The top-right position is listed as the up control, is also the location that opens Wi-Fi settings when triple-tapped from live preview, and is also where a QR code for the companion app appears on a triple-click. Two problems sit in those lines. The same three-contact gesture is called a triple-tap in one line and a triple-click in another, and only the Wi-Fi entry is qualified by a state, namely that it must come from live preview, so the QR code gesture has no stated precondition. The shutter is the only control documented as stateful in full, where a short press takes a photo and a long press powers off, and powering on requires a short press and release followed by a long press and release.

The companion app is reachable only over the local network

Photos and prompts are handled by a web app that runs on your phone, and the constraint on it is explicit: the phone must be on the same Wi-Fi network as the camera. There is no pairing flow, no account linking and no remote relay described anywhere, and access begins by showing a QR code from the camera. What the app does is download photos and update prompts, with the prompt editor as the part you are steered toward. The camera itself has a prompt menu, an album, and up and down positions, and the built-in prompts are four fixed transformations: a clumsy mouse-drawn scribble, turning everyone in the photo into cheese, a scrappy fantasy character in an indie webcomic style, and a bright anime portrait. Since the prompts live on the device, changing them requires being on the same network as it.

Three specific part numbers and a Mac with a desktop app

The bill of materials is narrow to the point of being a specific build rather than a design. It asks for a Raspberry Pi Zero 2 W already fitted with headers, a Pimoroni Display HAT Mini listed as part PIM589, a spy camera for the Zero listed as Adafruit 3508 or a generic equivalent, a PiSugar 3 battery, a 16GB microSD card and a reader, plus the printed case. Alongside that you need a Mac with the Codex Desktop app installed, a dependable Wi-Fi connection, and an OpenAI account, with the note that anyone using ChatGPT already has one. The supplier name is spelled two ways in the same section, as Pimoroni in the parenthetical and Pimorini in the part line. The README does acknowledge the specificity, saying the software can be modified to work with other cameras, screens or boards.

Taking it off home Wi-Fi is handled by leaving home Wi-Fi

There is a single security note in the document, and it is about networking rather than about the device. For anyone wanting the camera to work outside the home, the recommendation is to switch it from home Wi-Fi to the phone's mobile hotspot at the end of the tutorial. That advice is proportionate to what the device is: a networked camera that sends each captured image to an image generation model and returns a transformed version, with a phone app on the same segment holding the prompt menu and the album. The note addresses travel, not exposure, so a reader deciding where to put the thing on a network is left to weigh that for themselves. The repository does carry a SECURITY.md and a NOTICE file at the top level, alongside the Apache 2.0 licence text.

The enclosure is offered in two file formats in two sections

The case is described as folding, which is the stated reason PETG is preferred over PLA, and the project reports having been built on a variety of common printers with both filaments. But the file format changes between sections of the same document. The section on remodelling tells anyone with 3D modelling experience to import the STEP file into their modelling tool, while the answer to the question about having no printer says there are services where you can upload the STL files from the repository to be printed and shipped. Both are named as the thing to act on, and neither is introduced as the primary. The enclosure is also the part you are told you can skip if you have no printer, with the warning that the electronics are quite fragile if left uncovered, which makes the shell load-bearing rather than cosmetic.

Committed git hooks, a third_party tree, and no workflow directory

The top-level listing is short enough to read in full, and it says something about how the project is operated. There is a committed `.githooks/` directory, which means the repository ships its own hook definitions rather than relying on whatever a clone inherits locally. There is also a `third_party/` directory, consistent with an Apache 2.0 project carrying a NOTICE file, since vendored code under that licence comes with attribution obligations. The build instructions themselves live in `scripts/`, the firmware or on-device code would sit in `software/`, and reference material in `docs/` and `assets/`. There is no GitHub workflow directory in the listing, so no continuous integration is configured for the on-device software or the shell files, and the repository has no tagged releases at all, so the last commit date of 2026-06-08 is the only version marker available.

Editorial conclusion

This suits someone who wants a weekend hardware project with a working camera rather than a reference design, and who is willing to let an agent drive the build. Read AGENTS.md, since that is where the real instructions live, decide how you want the device networked before taking it off home Wi-Fi, and pick one 3D file format to commit to, because the documentation names two.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openai/imagegencam on GitHub
4. README