The X2's SDK line is identical on both tiers. Its programmability is not.

A robot's SDK line reads like the whole answer to whether it is a programmable platform: name a language, a toolkit, and the machine looks built for custom work. On the AGIBOT X2, that line is not the whole answer, and treating it as one gets the buying decision backwards.

Every spec table for the X2 line, ours included, lists the identical string on both tiers: AimDK_X2, in Python and C++. Read that line alone and the X2 Basic and X2 Ultra look equally open to custom development, just sized differently. AGIBOT's own official comparison table for the series says otherwise. It carries a separate row, the one our own product pages label customer-side development, and marks it not supported on the Basic and supported on the Ultra. Same SDK name on both rows. Different answer to the actual question.

The SDK name and the customer-side development row answer different questions.

AimDK_X2 is a toolkit and a licence: the language bindings, the documentation, and the terms under which code written against it can be shipped. Those terms read the same on both tiers, and what they actually permit is worth checking closely on its own, separately from this. Customer-side development is a hardware-tier fact, published in its own row on AGIBOT's spec table: whether the specific unit a customer buys is built to run code they wrote, at all. A shared SDK licence does not make that fact the same on both units, and the X2 listing is exactly where a reseller's spec table lets the two questions read as one.

What separates the two tiers, and what AGIBOT does not say about it.

The Basic and the Ultra also diverge on the sensing and compute this catalogue already lists by tier: the Ultra carries the LiDAR, the depth camera and the dedicated compute board the Basic goes without. AGIBOT does not publish why the customer-side development row follows that same split rather than the SDK name. What its own table does show, in the same rows, is that the hardware a custom perception or navigation routine would actually need is precisely the hardware the Basic ships without. A pattern in AGIBOT's own numbers, not an explanation the manufacturer has stated.

The same split appears elsewhere in the catalogue, and it never tracks the SDK name.

It is not only the X2. The G2 lists no SDK field anywhere in its own spec table, no named toolkit at all, yet AGIBOT still marks customer-side development supported on it. The D1 Pro and D1 Edu quadrupeds are the same machine on every mechanical and power row AGIBOT publishes; the only two rows that separate them are customer-side development, not supported on the Pro and supported on the Edu, and the expansion ports the Edu carries and the Pro does not. Neither dog names an SDK on its sheet either. So whether a unit names an SDK, and whether it is cleared to run a customer's own code, are independent facts across the whole catalogue, not just the X2, and both need checking for the specific SKU rather than assumed from each other.

What "not supported" costs on the tier that carries it.

On the X2 Basic, OTA updates and AGIBOT's own mobile app both stay supported: the unit updates itself and runs from the companion app. What its table does not offer is a route for a customer's own code, which is the one thing a research programme, a custom pick sequence, or an integration with another system actually needs. A Basic bought to run its preset routines and demo behaviour is bought for exactly what it does well. A Basic bought expecting to build against it, because the SDK name on the page promised as much, is a unit specified against the wrong row.

Before a purchase order names a tier, check the customer-side development row for that exact SKU, not the SDK line on the same page: it is the one entry on any of these tables that actually says whether the machine is one you can build on, and it costs nothing to ask before committing to either tier.