Every model you need. On hardware you own.

Anima is one sovereign interface to every model you run: self-hosted on your accelerators, served at remote sites, or proxied to approved external providers, always under your policy.

Talk to our team What it does

Sovereign inference, without the compromises #

An inference plane has to answer three questions well. Can this model run on the hardware I actually have? Where should this request go right now? And is this tenant allowed to send this data to that destination? Anima answers all three automatically, and keeps serving when the link to the core is gone.

Running your own models is usually presented as a trade: sovereignty in exchange for capability, cost or convenience. Anima removes that trade. A mixed fleet of accelerator generations becomes a scheduling problem rather than a migration, and per-tenant policy decides which models may serve a request and whether any data is permitted to leave the cluster at all.

Each model is served in the numeric format its hardware actually accelerates. That is where the efficiency comes from.

What Anima does #

Four ideas carry the product. Everything else is detail.

One interface in front of everything #

Every request is authorised, policy-checked and routed behind one stable contract, whether it lands on a local accelerator, a remote site or an approved external provider.

Routing by capability, locality, load and policy
Per-tenant model and destination policy
Drop-in OpenAI-compatible endpoint

Runs on the hardware you have #

Accelerators are discovered and classified automatically, and each model is served in the engine and numeric format its hardware accelerates best.

Mixed accelerator generations and vendors
Quantisation-aware serving
Text, embeddings, speech and vision

Multi-tenant in earnest #

Accelerators are pooled and shared for utilisation, or hard-partitioned and locked to one tenant when isolation or guaranteed capacity matters.

Pooled sharing with enforced budgets
Exclusive, conflict-checked allocation
Usage rollups for capacity and chargeback

Keeps serving where the link does not #

A remote site hosts its own workers, mirrors the weights it needs and enforces the same tenant policy as the core, then reconciles when the link returns.

Self-contained edge runtime
Local weight mirror
Generations survive transient network loss

What changes in your code #

Two lines. The base URL becomes your instance and the key becomes a token you minted, and the model name comes from your own catalogue rather than a vendor's.

openai python

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://agentycs.example.com/v1",
    api_key=os.environ["AGENTYCS_API_TOKEN"],
)

stream = client.chat.completions.create(
    model="chat-large",
    messages=[{"role": "user", "content": "Which sites are behind on inspections?"}],
    stream=True,
)

for chunk in stream:
    print(chunk.choices[0].delta.content or "", end="")

Anything that already speaks to an OpenAI-compatible endpoint speaks to your platform, including agent frameworks and editors your teams have standardised on.

your catalogue

curl https://agentycs.example.com/v1/models \
  -H "Authorization: Bearer $AGENTYCS_API_TOKEN"

{"object": "list", "data": [
  {"id": "chat-large", "object": "model", "created": 1753660800,
   "owned_by": "anima", "task": "text_generation", "context_window": 262144},
  {"id": "embed-text", "object": "model", "created": 1753660800,
   "owned_by": "anima", "task": "embeddings"}
]}

The catalogue lists what this tenant is permitted to call, self-hosted and approved-external alike, with the context window each model is genuinely being served with rather than a published maximum.

In more detail #

The full capability surface, grouped by the job it does.

Inference gateway

The single entry point. Every request is authorised, policy-checked and routed behind one stable interface.

Request routing: Each request goes to the right model in the right place, local, edge or external, chosen by capability, locality, load and tenant policy.
Tenant policy: Per tenant, decide which models and providers may serve a request and whether data may leave the cluster, enforced before any work is dispatched.
Throughput and streaming: Continuous batching, token streaming and cache management for high throughput at low latency, without sacrificing isolation between tenants.
OpenAI-compatible API: A drop-in compatible endpoint with self-issued API tokens, so existing clients and agent frameworks work unchanged.

Vendor-neutral execution

Models run on whatever hardware you have, through the runtime and numeric format best suited to each one.

Model workers: Worker processes host loaded models and return structured, streaming output. They are the unit the fleet schedules and scales, with load, warm, health-check and unload managed per process so accelerator memory is reclaimed cleanly.
Pluggable engines: A choice of inference engine per model class, so each model is served by the runtime that runs it best rather than one forced backend.
Quantisation-aware serving: Models are served in the numeric format their hardware accelerates, low-bit floating point on the newest accelerators and a graceful fallback elsewhere, for maximum throughput per watt.
Multi-modal serving: Text generation, embeddings, speech-to-text and vision are all first-class under one serving plane.

Fleet-wide orchestration

The control plane that runs many models at once and keeps the live fleet matched to what you declared.

Deployment management: Create, update, scale and retire model deployments, tenant-scoped or platform-wide, draining replicas cleanly on removal.
Architecture-aware scheduling: Placement respects each accelerator's architecture, numeric format support and memory budget, so a model never lands on a chip that cannot run it.
Multi-model packing: Many models are packed across the fleet with compatibility and spread gating, maximising utilisation while preserving headroom and fault isolation.
Live inventory: Every accelerator in the fleet, with type, memory and real-time utilisation, across local and remote nodes, classified automatically so scheduling follows without manual mapping.

Accelerator allocation

Your accelerator estate as a managed, multi-tenant resource: shared for efficiency, partitioned for isolation.

Dedicated allocation: Exclusive, conflict-checked assignment of accelerators to a tenant when isolation or guaranteed capacity is required, with safe release.
Safe sharing: Pooled accelerators are shared with per-tenant budgets and enforced isolation, so utilisation stays high without leaking data or capacity.
Usage analytics: Per-tenant, per-model usage rollups over the lakehouse: top models, tenant and provider breakdowns, for capacity planning and chargeback.

Your own model supply

A private registry and weight store. Import once, serve forever, with no runtime dependency on an external model host.

Model catalogue: Each tenant's resolved set of available models, self-hosted and external, with capability flags, ready to deploy or call.
Governed import: Browse and import open-weight models into your private registry as a one-time, audited operation, with memory requirement, numeric format and supported architectures inferred so placement just works.
Sovereign artefact store: A content-addressed store of weights and artefacts owned entirely by your platform. It is the source of truth the fleet loads from.
Distribution and pinning: Artefacts are seeded, mirrored and pinned out to workers and remote sites, so weights are local before a model is needed.

Edge, external providers and tools

Serving close to the data, optional access to approved external models, and what a generation can reach beyond text.

Self-contained edge runtime: A remote site hosts its own workers, serves requests locally over a signed HTTP/3 link, mirrors weights so models load without the core, and keeps serving what it has when the core is unreachable.
Policy-gated external routing: Requests reach an external provider only when tenant policy permits it, with external and self-hosted models behind one unified contract.
Credentials never exposed: Provider credentials are vault-referenced, never returned, never logged and redacted everywhere. They are used at dispatch time and never embedded in a catalogue or in telemetry.
Governed tool use: Models can invoke platform and external tools mid-generation, including a self-hosted, privacy-preserving web search, each call subject to a capability check.

What teams do with it #

Three jobs Anima is built to take on.

Replace a model API

Point existing OpenAI-compatible clients at your own endpoint and keep the same code, while prompts and completions stop leaving your boundary.

Consolidate a mixed GPU estate

Bring several accelerator generations under one scheduler that knows what each can run, instead of pinning models to machines by hand.

Serve where the data is

Run inference at a factory, a hospital, a vessel or a forward site, governed centrally but able to operate alone.

How you connect #

One stable, model-neutral contract in front of everything, whether it runs on your own accelerators or somewhere you approved.

OpenAI-compatible API
Platform model access
Model tools over MCP
AI console

What each interface gives you

OpenAI-compatible API: Chat, completion and embedding endpoints with self-issued tokens, for existing SDKs, agent frameworks and developer tools.
Platform model access: Typed access to models and agents from inside your applications, tenant-scoped and under the same policy as any other caller.
Model tools over MCP: Governed tool calling, so a generation can reach platform and external tools with each call capability-checked.
AI console: A first-party console for the model catalogue, imports, deployments, external providers, accelerator inventory, tenant allocation, API tokens and usage.

Bring us your inference workload

Tell us which models you need, what hardware you have or want, and where the data is allowed to be. We will show you how Anima would serve it.

Talk to our team