Skip to main content

One inference control plane, replaceable specialist systems

OpenRouter is a quickstart example, not a product boundary. InferCrane can connect an authenticated OpenAI-compatible model API, adopt an existing LiteLLM or inference endpoint, or deploy qualified self-hosted runtimes. Other systems keep the responsibilities they are better suited to own.

Start with a model API

OpenRouter needs no special application contract. It supplies a convenient default URL; any other OpenAI-compatible provider uses the same path with an explicit adapter and URL.
Both commands create reusable configuration only. Neither sends a request nor authorizes spend. Traffic requires a separate endpoint binding with explicit data-transmission consent and hard request, total-cost, and per-request cost limits.

Keep an existing LiteLLM gateway

The initial ownership mode is observe-only. InferCrane never imports LiteLLM credentials or silently moves application traffic. See LiteLLM gateway.

Agent frameworks and vector databases

Agent and RAG applications use the stable endpoint exactly as they use another OpenAI-compatible surface:
LangGraph, LlamaIndex, or another framework may wrap this client. Qdrant, Milvus, pgvector, or another vector store stays in the application data path. InferCrane does not copy documents, embeddings, prompts, tool arguments, or retrieved context by default.
InferCrane does not yet inspect vector-database availability or attribute retrieval latency. A future dependency adapter must add grounded health and timing evidence without taking ownership of the index or data lifecycle.

Workflow engines

Argo, Temporal, Airflow, or an internal orchestrator can call the control API or CLI as one durable inference step:
InferCrane owns the inference job, cancellation, execution deadline, encrypted result retention, and bounded signed-webhook delivery. The external workflow engine owns the larger DAG.

Kubernetes and GPU schedulers

InferCrane can own a bounded namespaced Deployment/Service set or one KServe InferenceService. A cluster may use its own scheduler and policies underneath that boundary. Kueue and Volcano are not currently direct InferCrane adapters. Do not interpret Kubernetes support as evidence that their CRD status, queue admission, preemption, or placement decisions are visible to InferCrane. A future adapter should remain read-mostly: compile explicit workload intent, observe standard status, and preserve scheduler ownership.

Why the boundaries matter

An end-to-end inference product does not need to reimplement every layer. InferCrane owns the stable application identity, desired state, durable operations, release policy, evidence, and economic decision. Specialist systems remain replaceable behind versioned, qualified contracts.