ApowerB now integrates Eden AI as a first-class model provider. In practical terms, an agent built with ApowerB can use a single Eden AI API key to access multiple providers and models through one unified interface, while retaining the option to route compatible workloads through Eden AI’s dedicated European endpoint when EU data residency is required.

The integration addresses a simple architectural concern: an agentic system should not be unnecessarily locked to a single model provider. Models evolve quickly, pricing changes, performance varies by workload, and availability is never perfectly uniform. Production agents need the freedom to switch models, apply routing rules, introduce fallbacks, and operate under security, cost, availability, and regional constraints without rebuilding the agent itself.

Technically, the integration lives in ApowerB, the open-source agent runtime developed by thaink². Eden AI now appears as a dedicated provider in the model layer. The endpoint is preconfigured, so users only need to provide their Eden AI API key and select a compatible model.

Why integrate Eden AI into ApowerB?

A production AI agent should not depend on a model in the same way a conventional application depends on a local function. Model providers change rapidly, pricing structures move, capabilities improve at different speeds, and the best model for one workload may be a poor choice for another.

This is where the distinction between an agent runtime and an AI gateway becomes important.

• ApowerB runs agents, tools, sessions, state, workflows, and production execution logic.

• Eden AI provides a unified access layer across many model providers, with routing, fallback, cost controls, and regional constraints.

The two layers are complementary. The runtime decides what the agent should do; the gateway helps determine which model or provider should handle the model call.

A model layer designed to reduce provider lock-in

Eden AI positions itself as a European AI gateway and LLM router that unifies access to a broad catalog of language and specialist AI models behind a single API. Its current product pages describe roughly 1,000 models available through one gateway, with controls for provider selection, routing, fallback, budgets, and region restrictions.

For ApowerB, the practical benefit is straightforward: an agent can use Eden AI without embedding provider-specific integration logic into the agent itself.

Models are referenced through an edenai/ prefix while preserving the provider and model identifier selected through Eden AI.

{
  "agent_model": "edenai/anthropic/claude-haiku-5-5",
  "agent_model_params": {
    "model_api_key": "<eden-ai-api-key>"
  }
}

{
  "agent_model": "edenai/anthropic/claude-haiku-5-5",
  "agent_model_params": {
    "model_api_key": "<eden-ai-api-key>"
  }
}

ApowerB uses Eden AI’s standard endpoint by default. A custom model_api_base can also be configured when a deployment needs a specific regional endpoint.

The model catalog is intentionally not hard-coded into ApowerB. It is discovered from Eden AI’s API, which avoids maintaining a static list that becomes outdated as providers add, rename, or remove models.

The real value is model routing

The integration is not valuable simply because it adds more models to a selector.

A gateway becomes useful when model access is governed by production rules:

• prefer one provider when cost is the primary constraint;

• favor another when latency matters more;

• restrict the models or providers available to a specific organization or environment;

• define fallbacks when a provider becomes unavailable;

• keep a conversation on the same provider when consistency matters;

• enforce a processing region when compliance requires it.

Eden AI currently documents routing strategies based on cost, speed, latency, provider allowlists, fallbacks, sticky routing, and regional constraints. In that role, the gateway becomes a control layer between the agent runtime and the models it consumes.

Why the European and sovereignty angle matters

The collaboration between Eden AI and thaink² is particularly relevant in the European market.

Eden AI is a French company based in Lyon. thaink² was founded in Metz and develops ApowerB as an open-source agent runtime. That geographic proximity does not, by itself, make an architecture sovereign. Sovereignty depends on the full technical chain: infrastructure, actual model provider, processing location, data handling, and the organization’s ability to control and replace dependencies.

Eden AI does, however, provide a concrete mechanism that can support European deployment requirements: a dedicated EU endpoint.

The endpoint https://api.eu.edenai.run/v3 is designed to keep compatible AI inference within the European Union. Eden AI states that requests sent through this endpoint are routed only to EU-compatible model infrastructure, with non-EU models refused rather than silently routed elsewhere. Its current privacy and product documentation also states that synchronous request and response content is not stored by default and that customer data is not used to train models.

An ApowerB deployment that needs this route can point the model layer to the EU endpoint:

{
  "agent_model": "edenai/mistral/mistral-small-latest",
  "agent_model_params": {
    "model_api_key": "<eden-ai-api-key>",
    "model_api_base": "https://api.eu.edenai.run/v3"
  }
}

{
  "agent_model": "edenai/mistral/mistral-small-latest",
  "agent_model_params": {
    "model_api_key": "<eden-ai-api-key>",
    "model_api_base": "https://api.eu.edenai.run/v3"
  }
}

The accurate conclusion is not that “every model accessed through Eden AI is sovereign.” It is more specific: the integration makes it possible to combine a self-hostable open-source agent runtime with a European gateway that can enforce provider and regional constraints.

One Eden AI key, multiple models behind the agent

From the ApowerB user’s perspective, the goal is to remove unnecessary integration friction.

Eden AI now appears as a first-class provider in the model selector. The user provides an Eden AI API key and then chooses a model from the catalog exposed by the gateway.

This is especially useful in three situations.

1. Testing several models without rebuilding the agent

A RAG agent can be evaluated with several model families. An analytics agent can be tested against another. A generation workflow can evolve without changing the logic used for tools, sessions, or state.

2. Preparing provider fallbacks

A production architecture should not assume that a single provider will always be available. A gateway makes it possible to move fallback logic out of each individual agent and into a shared model-access layer.

3. Centralizing model governance

An organization may want to restrict approved models, monitor spend, or require specific teams to remain within a given region. Eden AI centralizes those model-access controls, while ApowerB retains the controls tied to agents, users, tools, sessions, and workflows.

ApowerB remains open source and self-hostable

Adding Eden AI does not turn ApowerB into a dependency on Eden AI.

ApowerB already supports multiple model providers through its model layer and can continue to work with direct provider connections, compatible self-hosted endpoints, or other supported backends.

Eden AI adds another option: a multi-provider gateway. Teams can therefore choose between:

• a direct provider API key;

• a self-hosted inference endpoint;

• an AI gateway such as Eden AI;

• different strategies for different agents or environments.

That property matters to us: the agent runtime should remain independent from the model-provider choice.

ApowerB’s source code is available on GitHub, and its technical documentation is available at docs.apowerb.com.

Eden AI and thaink²: two layers, one goal of greater control

thaink² is building a platform where specialized agents can search, analyze, forecast, and act on enterprise data. ApowerB provides the open-source runtime layer that executes those agents and orchestrates their tools.

The Eden AI integration strengthens another part of that architecture: the ability to choose and change models without hard-wiring the agent system to a single provider.

The combination is particularly relevant for organizations that want to bring together:

• self-hostable agents and workflows;

• multi-model access;

• provider routing;

• regional controls;

• fallback strategies;

• cost and usage controls;

• the ability to replace a backend later.

An integration built with Eden AI

This integration is also the result of direct collaboration between the Eden AI and thaink² teams.

We would like to thank the Eden AI team for the discussions around the integration, and Dave on the thaink² side for implementing and validating the full integration path in ApowerB.

The collaboration goes beyond adding a name to a model catalog. Eden AI will also document ApowerB in its integration resources, giving developers a clear path to connect the two layers from either side.

Build an agent without locking in its model provider

Explore ApowerB, thaink²’s open-source agent runtime, and configure Eden AI as a multi-model gateway with a single API key.

How to connect Eden AI to ApowerB

For developers, the connection path is deliberately short:

1. create an Eden AI API key from Eden AI;

2. open the model configuration in ApowerB;

3. select Eden AI as the provider;

4. enter the API key;

5. select the required model identifier;

6. when needed, set https://api.eu.edenai.run/v3 as the base URL for the European route.

ApowerB’s integration details and configuration examples are available in the ApowerB repository. Eden AI is also preparing its own integration resource so developers can connect the two environments from the gateway side.

What this integration changes in practice

For developers, it reduces provider-specific integration code. For platform teams, it adds another control point over which models are available. For European organizations, it provides a practical way to introduce regional routing requirements without replacing the agent runtime.

The architectural principle is the most important part: do not confuse the model, the gateway, and the agent runtime.

The model generates. Eden AI routes and governs access to model providers. ApowerB executes agents and their workflows. thaink² builds enterprise products and services on top of that infrastructure.

Keeping these responsibilities separate makes it much easier to evolve one layer without rebuilding the others.