OpenAI's first end-user device is a macro pad. The bigger hardware bet is still coming.

On 15 July, OpenAI released Codex Micro, a $230 mechanical macro pad built with Work Louder. Its keys can show the status of Codex agents, trigger common actions and adjust reasoning levels. It is designed for people who already use Codex heavily and want physical controls beside their keyboard.

It is a modest first device to sell under the OpenAI name. The larger hardware project, developed with Jony Ive and the former io Products team, is still in development.

For businesses adopting AI, the contrast between them raises a more useful question than whether either device will succeed: how much of your work survives when the company behind a tool changes direction?

The low-risk product shipped first

Codex Micro is built around an established product and a recognisable behaviour. Developers already switch between agents, review changes and monitor tasks. The device gives some of those actions a physical button.

That makes it relatively easy to understand. OpenAI does not need to persuade people to carry a new category of device or behave differently in public. It needs a small group of committed Codex users to decide that tactile controls are worth $230.

The io project carries a different level of ambition. OpenAI acquired the company in a deal valued at about $6.5 billion. The first device has been described as screen-free, pocket-sized and aware of its surroundings, although its final form has not been publicly confirmed. Court filings indicate that it will not ship before late February 2027.

Codex Micro and the io device therefore represent two very different hardware strategies. One adds controls to an existing workflow. The other asks people to make room for a new type of computer.

The larger project already carries execution risk

On 10 July, Apple filed a lawsuit against OpenAI, io Products and two former Apple employees, Tang Yew Tan and Chang Liu.

Apple alleges that confidential information about unreleased products, components and manufacturing was taken or solicited as OpenAI built its hardware operation. The complaint includes claims that candidates were encouraged to discuss confidential projects and bring physical parts to interviews. OpenAI denies wrongdoing. The allegations have not been tested in court.

The case does not prove anything about the quality of the eventual product. It does show how quickly a supplier's plans can become exposed to factors its future customers cannot control.

A product can be technically promising and still face delays, legal restrictions, changes in leadership or a shift in company priorities. Those are vendor continuity risks. Businesses need to consider them before a tool becomes essential to daily work.

AI hardware has already provided several warnings

Humane's AI Pin is the clearest example. In February 2025, HP bought most of Humane's assets for $116 million after the company had reportedly raised more than $230 million. The servers supporting the Pin were switched off and most of its connected functions stopped working. Customers were given days to export their information.

Rabbit's R1 has survived, although its first release was heavily criticised and employees later reported months of unpaid wages. Rabbit has continued developing the device and now allows users to control third-party systems including Claude Code, Hermes Agent and OpenClaw. That makes the R1 more useful, while leaving users dependent on Rabbit's hardware and connectivity layer.

Meta's glasses show that single-vendor hardware can succeed. More than seven million pairs were reportedly sold in 2025 and demand became strong enough to affect international rollout plans. The underlying category already made sense: people wanted Ray-Ban glasses before Meta added an assistant, cameras and audio.

The pattern is less tidy than "closed devices fail". Products can succeed inside closed ecosystems. The dependency remains, and its consequences become more serious as people store more history and build more routines around the device.

"Open" can mean several different things

Omi has one of the clearest openness claims in the wearable category. Its hardware designs, firmware, application and backend are publicly available under an MIT licence. Users can self-host parts of the stack and supply their own OpenAI, Anthropic, Google and transcription keys.

That offers considerably more control than choosing between models inside a closed application.

Pocket, an AI voice recorder founded by a former member of the Omi team, markets itself as model-agnostic and says it uses GPT, Claude and Gemini models. It also offers integrations and bulk exports. We could not find the same public evidence of an open hardware, application and backend stack. Model choice is useful, but it covers only one layer of the dependency.

Limitless shows what can happen when ownership changes. The company built a wearable that recorded and organised conversations, then sold to Meta in December 2025. New sales stopped. Its service was withdrawn from the UK, the EU and several other markets, with affected users told to export their information before their accounts were deleted.

For those customers, the important question was never which language model generated the summaries. It was whether the service, data and hardware would remain usable.

Model choice does not guarantee portability

There is no widely adopted standard for moving an AI assistant's accumulated context, memories and workflows between providers.

A product might let users choose between GPT, Claude and Gemini while keeping every conversation, integration and automated process inside its own proprietary system. Changing the model is then relatively easy. Leaving the product is not.

That distinction matters for creative businesses. A tool can move from experiment to infrastructure surprisingly quickly. It begins by summarising meetings or generating rough concepts. A few months later, it contains client history, approval decisions, project language and a team's working memory.

In one recent KINTAL client engagement, the most useful work happened before the chosen tool became operationally important. We documented its subprocessors, data handling terms and the position if the supplier's arrangements changed. That work was less visible than a product demonstration. It was also more likely to protect the business later.

The practical due diligence question is simple:

What are you left with when the vendor changes direction?