18社・88モデルを1つのAPIキーで利用できる「AICraft」が公開——ルーティングが自動で最適モデルを選択AICraft is a newly released service that unifies 88 models from 18 providers…

AICraft, a newly released service highlighted in a recent Qiita blog post, aims to simplify how developers work with large language models by unifying 88 models from 18 different providers behind a single API key. As organizations increasingly mix and match models from multiple vendors, the appeal is straightforward: fewer credentials to manage, one integration surface to maintain, and an automatic routing layer that selects an appropriate model for each incoming request.

The problem AICraft targets is fragmentation. A typical production setup might use one provider's flagship model for complex reasoning, a cheaper model for routine classification, and yet another vendor for long-context summarization. Each of those relationships usually means a separate API key, a separate billing account, different rate limits, and provider-specific quirks in request and response formats. Managing this by hand adds operational overhead and couples application code tightly to individual vendors. By consolidating access, AICraft positions itself as an aggregator that abstracts away those differences so that a single call can reach any of the supported models.

The feature the announcement emphasizes most is routing. Rather than forcing developers to hardcode which model handles which task, AICraft is described as analyzing the content of each request and dispatching it to the model it judges most suitable. In practice, routing systems of this kind typically weigh factors such as prompt complexity, expected output length, latency requirements, and cost, then map the request to a model that balances those constraints. The stated benefit is that applications can consistently use a fitting model without engineers having to rebuild selection logic every time a new model is released or an existing one is deprecated. The exact criteria AICraft uses for its routing decisions are not fully detailed in the summary, so the precise trade-offs it makes between quality, speed, and price are not yet clear from the available information.

AICraft is not the first product to pursue this pattern, and understanding its neighbors helps place it in context. OpenRouter offers a comparable single-endpoint gateway to many hosted models, with unified billing and fallback options. LiteLLM provides an open-source proxy that normalizes calls across dozens of providers into an OpenAI-compatible interface, and Portkey markets an AI gateway with routing, caching, and observability features aimed at production teams. Cloud platforms and frameworks such as the Vercel AI SDK and various LangChain integrations also let developers swap models with relatively little code change. Against that backdrop, AICraft's differentiator appears to be the breadth of its catalog combined with automatic model selection, though independent benchmarks would be needed to judge how its routing performs relative to these alternatives.

A few technical concepts underpin why services like this exist. The de facto standardization around OpenAI's chat completion API has made it far easier for aggregators to present many backends through one familiar schema, which lowers migration cost for developers already using that format. Gateways in this category commonly add capabilities beyond routing, including request retries and failover when a provider is unavailable, response caching to cut costs, and centralized logging for monitoring usage and spend. It is worth noting that the blog post is filed under a local-LLM category, yet the described architecture is a cloud aggregation layer over hosted providers; whether AICraft also supports self-hosted or on-device models is not specified in the summary.

Prospective users will want to consider the usual caveats that accompany any intermediary layer. Sending traffic through a third party introduces an additional point of latency and a dependency whose availability and data-handling practices matter, particularly for sensitive workloads. Automatic routing can reduce engineering effort, but it can also make behavior harder to predict if the chosen model changes between requests, which is a consideration for applications that require consistent tone or reproducible outputs. Pricing structure, data retention policies, and the degree of manual override available are all details worth confirming before adoption, and none of these are spelled out in the current announcement.

For teams already juggling several model vendors, AICraft is likely to be worth evaluating as a way to reduce integration complexity. As the number of available models continues to grow across the industry, tools that consolidate access and automate selection reflect a broader shift toward treating models as interchangeable, routable resources rather than fixed dependencies. Whether AICraft's specific routing quality justifies routing production traffic through it will depend on hands-on testing against the workloads that matter to each user.