AI & machine learning

SDK

Software Development Kit. A collection of code libraries, documentation, and tools that lets developers integrate a service into their applications without writing everything from scratch. SDKs are how projects become easy to build with.

Also known as: software development kit

SDKs are how developers integrate external services into their applications quickly. An SDK is usually a code library in a specific language (Python, TypeScript, Rust, Go) that wraps the underlying API in idiomatic functions, handles authentication and error retries, manages connection pooling, and provides typed responses. Without an SDK, every developer would have to write their own HTTP client code to call the service’s API, which works but is tedious and error-prone. With an SDK, the integration is usually a few imports and a few function calls.

In DeAI, SDKs are critical for adoption. A decentralised inference service that only exposes a raw HTTP API will get used by experienced developers willing to write their own integration. The same service with Python and TypeScript SDKs gets used by ten times as many developers because the integration cost drops from “an afternoon of work” to “five minutes.” Venice, Bittensor, Morpheus, io.net, and most other DeAI inference projects publish SDKs in the major languages, often as wrappers around their OpenAI-compatible endpoints so existing OpenAI integrations work with minimal changes.

The OpenAI Python SDK is the canonical example of why SDK design matters. It became the de facto standard for AI inference clients, and any DeAI inference service that wants to compete has to either provide an SDK that mimics it (so users can switch by changing one URL) or accept that they’re locking out a large fraction of potential users. This is why “OpenAI-compatible API” is now table stakes for DeAI inference projects: it’s not just about the API itself, it’s about being usable by the existing OpenAI Python and TypeScript SDKs without modification.

Beyond inference, SDKs in DeAI cover wallet libraries (NEAR API JS, ethers.js, web3.py), agent frameworks (ElizaOS, Virtuals GAME, Autonolas Open Autonomy), and on-chain action libraries. Most of the OYM build tutorials use SDKs heavily because building from scratch would make the tutorials too long. The OYM project reviews note when a project’s SDK ecosystem is unusually strong (a sign of developer adoption) or unusually thin (a sign that the project might be all marketing and no practical integration).

Related terms