Overview

What is Aimable

Aimable is a governance and orchestration layer that sits between your application and the underlying AI models. Instead of calling model providers (OpenAI, Anthropic, open-source) directly, you send your requests to Aimable. Aimable routes each request to the right model, applies your governance policies (PII handling, content guards, cost controls), runs retrieval and tools where you have configured them, and records full observability for every call.

You keep a single integration. Aimable handles model routing, multi-tenancy, governance, and usage metering behind it — so you can add, swap, or restrict models without changing your application code.

How it fits together

• Tenant — your organisation on Aimable. The tenant is you.
• Space — an isolated workspace inside your tenant, with its own model policy, knowledge, tools, and governance settings. How you map spaces is your choice — by customer, environment, application, or team — and each is fully isolated in model access, data, and usage.
• API key — a service credential (ak.…) used for machine-to-machine calls from your backend.
• Model policy — per-space configuration of which models are allowed, which is the default, and how reasoning is handled.

Every inference request runs in the context of a space, and you choose the space per request. That is what lets one integration serve many isolated workspaces from a single backend.

Key capabilities

• Drop-in inference — an OpenAI-compatible POST /v1/chat/completions endpoint. Point your existing client at Aimable's base URL and keep your code. Streaming is supported via Server-Sent Events.

• Governed responses — POST /v1/spaces/{space_id}/responses adds structured output, PII/OII pseudonymization, input/output guards, knowledge search, tools, and per-call cost caps on top of the model call.

• Multi-model routing — one interface across OpenAI, Anthropic, and open-source models. Choose the model per request, or let the space's policy decide.

• Multi-tenancy — spaces isolate model access, knowledge, and usage, each with their own policies. Map them to whatever your product needs.

• Governance — PII and organisational-identifier pseudonymization, content guards, model allowlists, and cost controls, enforced per space.

• Knowledge & tools — attach collections (RAG), tools, and skills to a space and use them from the same request.

• Observability — token usage, cost, and latency per space, traceable down to the individual request.

Who it's for

• Software and SaaS builders embedding AI who want one governed integration instead of wiring up each model provider separately.

• Agencies and platforms that need to isolate many workloads — by client, environment, or product — with per-space model policy and usage visibility out of the box.

• Technical evaluators assessing whether to put a governance and routing layer between their application and the models.

Next steps

• Getting Started — make your first call in minutes.
• Integration — authentication, spaces, streaming, and error handling.
• Concepts — the data model behind tenants, spaces, model policy, and governance.
• API Reference — every endpoint, with a built-in "Try it" console.