io.net Expands AI Tool Support Through IO Intelligence
io.net expands IO Intelligence with support for four open-source AI projects, enabling developers to run more tools on decentralized GPU infrastructure.

io.net is broadening the range of open-source AI tools that can use its inference infrastructure, adding compatibility with projects including Gajae Code, Claude-Mem, Vellum Assistant and Wakil. The update extends the company’s effort to build an AI services layer on top of its distributed GPU network rather than limiting the platform to raw compute rentals. According to io.net’s official overview of its AI infrastructure, IO Intelligence provides a model-access layer through which external applications can route inference workloads without operating their own GPU clusters.
The integrations are best understood as provider compatibility rather than full application deployment. Gajae Code now includes an ionet provider preset that connects to IO Intelligence and dynamically discovers available models, while Claude-Mem documents io.net as an OpenAI-compatible backend for its observation and memory-processing workloads. Wakil’s configuration similarly identifies IO Intelligence as a supported OpenAI-compatible endpoint. These applications can direct model requests toward io.net while their own agent logic, memory and user interfaces continue running independently.
OpenAI-Compatible APIs Lower Integration Friction
IO Intelligence exposes familiar API patterns for applications that already support configurable inference providers. Its model catalog includes systems from developers such as Meta, DeepSeek, Mistral, Google, Microsoft and Nvidia, with examples including DeepSeek-R1 and Llama 3.3 70B. The practical advantage is that developers can change the infrastructure serving model calls without rewriting the surrounding application around a proprietary interface.
That model fits Gajae Code particularly directly. Its documentation says IO Intelligence model IDs are discovered from the provider’s live /models endpoint instead of being hardcoded, allowing future catalog changes to flow into the coding agent without requiring a new integration for every model. Claude-Mem takes a similar route by sending requests to io.net through a configurable OpenAI-compatible base URL. The new support therefore expands provider choice more than it introduces entirely new AI applications to the network.
The development follows io.net’s recent dynamic GPU provisioning rollout for autonomous AI agents, which allows compatible agents to provision and terminate compute as workload demand changes. That infrastructure is aimed at bursty workloads that may require substantial GPU capacity for only short periods. Combining programmatic provisioning with standardized inference endpoints moves io.net closer to functioning as an interchangeable compute backend for agent software rather than simply a marketplace for rented GPUs.
Solana Coordinates Economics, Not AI Execution
io.net’s blockchain component remains distinct from the workloads themselves. The project uses Solana for network coordination and settlement functions, including supplier payments and token incentives, while AI training and inference occur on the distributed hardware connected to io.net. Running a model through IO Intelligence should therefore not be described as executing AI computation on Solana.
That distinction mirrors the architecture emerging across decentralized AI infrastructure. Gensyn, for example, similarly separates blockchain coordination from compute performed outside conventional smart-contract execution, while its mainnet infrastructure focuses on coordinating AI work and verification. Blockchains can coordinate identity, payments and incentives around GPU workloads without becoming the machines performing those workloads.
The integrations increase the number of software projects capable of consuming IO Intelligence, but they do not establish how much inference those applications are actually routing through io.net. Public documentation confirms compatibility and available models, while recurring request volume, GPU utilization and developer retention remain separate adoption metrics. The measurable development is broader software interoperability; the stronger commercial signal will be sustained workloads generated by those integrations once developers begin using them at scale.
This article is for information only and is not investment advice. We report under our Editorial Policy; to flag an error, see our Corrections Policy.


