PokeBot opens RoboAPI preview with non-commercial limits
PokeBot has opened a public technical preview of RoboAPI, a service for predicting robot actions from observations and instructions. Its announcement dated October 30 advertises free preview access, but an important footnote limits that offer: it is currently non-commercial and does not provide products or services to for-profit third parties.
What the API does, and what stays on your robot
The getting-started guide describes two integration routes. A local runtime on the hardware-connected Linux computer gathers observations, requests actions and executes them. Alternatively, an application can call the inference service and translate its responses into commands for its own controller.
That distinction matters when evaluating the launch. Access to a hosted model is not the same deliverable as a complete, validated robot installation. The developer console manages cloud access, while the control computer handles the physical device. The documented OpenAI Python SDK compatibility is a client interface, not an indication that OpenAI supplies the model.
The hardware requirements are specific
The reference hardware guide describes a UR arm setup rather than promising compatibility with every robot. Its core requirements are:
| Component | Documented reference setup |
|---|---|
| Robot arm | UR5 (CB3), UR5e or UR7e, including its controller |
| Gripper | Robotiq 2F-85 with a parallel locking kit |
| Control computer | Linux x86-64, USB and wired Ethernet |
| Wrist camera | Insta360 Ace Pro 2 with Ultra Wide Lens and Utility Frame, or DJI Osmo Action 6 with FOV Boost Lens |
Camera geometry is part of the integration, not just image quality. PokeBot says a non-standard camera must closely reproduce the reference wrist view and fisheye projection. Increasing an ordinary camera’s field of view does not reproduce that projection. Mounting, calibration and controller integration therefore remain substantive work.
A successful request is not a completed task
The official first-call example deliberately prints the returned action sequence without commanding a device. It requires an image and corresponding robot state. The guide explicitly distinguishes a successful inference request from successful physical execution.
For developers, this creates a useful separation between checking the service response and validating a real installation. The documentation requires integration checks before executing model actions. It also warns against replaying stale actions after a stop or communication failure. ByteForward has not run this software or tested a robot.
Access, evidence and safety limits
The account documentation directs users to their console for model access, available balance and applicable credit or billing information. It does not publish a universal numeric free allowance. Preview language should not be read as a permanent pricing commitment, and account access should be checked before planning a project around it.
The launch page includes selected demonstrations and PokeBot’s own benchmark results, not independent validation. Those results do not establish reliability on an unfamiliar installation. The company says a fuller Poke-Aurora technical report is still to come.
One particularly important limitation appears in the troubleshooting documentation: the motion range constrains the commanded flange-center position, not the whole arm or its rotation, and supplies no obstacle avoidance. A software boundary should not be mistaken for a complete physical safety system.
The useful development here is a documented route to evaluating robot-action inference beyond a promotional video. The practical question for a lab is whether it meets the access conditions and can validate the complete hardware and control setup.
Featured image: editorial illustration using PokeBot’s official wordmark. It is not a product photograph.
