--- title: Compare stdapi.ai - LiteLLM, Bedrock Access Gateway and Bedrock Mantle description: How stdapi.ai compares with LiteLLM, Bedrock Access Gateway and Amazon Bedrock Mantle in front of Amazon Bedrock, with sources and verification dates, and the test evidence behind the compatibility claims. keywords: stdapi.ai comparison, AI gateway comparison, AWS Bedrock gateway comparison, LiteLLM alternative, Bedrock Access Gateway alternative, Bedrock Mantle alternative, OpenAI compatible gateway AWS, Anthropic compatible gateway AWS, AI gateway quality assurance, Bedrock gateway benchmark --- # :material-scale-balance: Compare stdapi.ai Two questions follow the [feature list](features.md): how does stdapi.ai compare with the other ways to put an OpenAI-compatible API in front of Amazon Bedrock, and how do you know its compatibility claims hold. This page answers both — the feature-by-feature comparison with its sources and verification dates, then the test evidence behind every claim on that page. --- ## :material-scale-balance: How stdapi.ai Compares All four solutions below expose an OpenAI-compatible API in front of Amazon Bedrock. The comparison focuses on the AWS deployment context — LiteLLM is evaluated with AWS services as the backend provider (Bedrock, Polly, Transcribe), not as a multi-cloud proxy. Bedrock Access Gateway is the official AWS-maintained open-source sample. Bedrock Mantle is AWS's own managed OpenAI-compatible endpoint, requiring no self-hosting — and stdapi.ai can also front it as an additional backend, serving Mantle-only models through the gateway (see [Bedrock Mantle Models](features.md#bedrock-mantle-models)). Competitor capabilities were verified against official sources on 5 August 2026; the batch inference, vector store, file search and per-end-user billing rows were verified on 21 August 2026; the image, audio and video rows were re-verified on 24 August 2026; the Ollama, Marketplace endpoint, SageMaker AI, tenant key and Administration API rows were verified on 27 August 2026. stdapi.ai is AWS-only: if you need multi-cloud routing or spend limits enforced at request time, LiteLLM is the better fit. !!! note "Cost attribution is not a spend limit" Bedrock's native attribution — IAM principal, application inference profiles, projects and workspaces — reports [aggregated billed cost to Cost Explorer and CUR 2.0 at per-usage-type-per-day granularity](https://docs.aws.amazon.com/bedrock/latest/userguide/cost-management.html), not as a per-request row. That is reporting, not enforcement: it cannot block a request that would exceed a budget. stdapi.ai's per-request cost figures are likewise an estimate for visibility. Enforcing a hard limit requires a gateway layer in front of inference — the approach AWS itself takes in its [Generative AI Gateway Solution](https://aws.amazon.com/solutions/), which uses LiteLLM. | Capability | stdapi.ai | LiteLLM (on AWS) | Bedrock Access Gateway | Bedrock Mantle | |---------------------------------------------|:-----------------------------------:|:---------------------------------------:|:---------------------------------------:|:---------------------------------------:| | **OpenAI Chat completions** | | | | [^2] | | **OpenAI Completions** | | | | | | **OpenAI Embeddings** | | | | | | **Anthropic Messages API** | | | | [^14] | | **OpenAI Responses API** | | [^18] | | [^2] | | **OpenAI Image generation** | | | | | | **OpenAI Image editing** | | [^28] | | | | **OpenAI Image variations** | | | | | | **OpenAI Videos API** | | | | | | **OpenAI Moderations API** | | | | | | **OpenAI TTS (speech)** | | [^12] | | | | **OpenAI STT (transcription)** | | | | | | **OpenAI Files & Uploads API** | | | | | | **Asynchronous batch inference** | | [^21] | | [^22] | | **Managed vector stores** (create, attach, index, search) | | [^23] | | | | **Model-run file search, with citations** | | [^24] | | | | **Server-side stored conversations** | | [^17] | | | | **OpenAI Realtime API** | | | | | | **Cohere Rerank API** | | | | | | **Cohere Embed API** | | | | | | **Ollama API** | | [^29] | | | | **Own AI & media APIs as MCP tools** | | [^20] | | | | **Bedrock Full model catalog** | | [^1] | [^10] | [^2] | | **Unified Bedrock + Mantle catalog** | | [^15] | | | | **Bedrock Marketplace model endpoints** | | [^30] | [^31] | [^32] | | **Your own SageMaker AI endpoints** | | [^33] | [^31] | [^32] | | **Every model on every text API** | | [^16] | | | | **Multimodal inputs** | text · image · audio · video · docs | text · image · docs | text · image | text · image | | **Multi-region capacity combining** | | [^8] | | | | **Bedrock Cross-region inference profiles** | | [^13] | [^13] | | | **Bedrock system tools** | | | | | | **Bedrock Guardrails** | | | | | | **Bedrock Service tiers** | | | | | | **Bedrock Application inference profiles** | | | | [^19] | | **Bedrock prompt routers** | | | | | | **Bedrock Prompt caching & reasoning** | | [^6] | | [^9] | | **Runs in your AWS account** | | | | | | **Model auto-discovery** | | [^1] | [^7] | | | **Deprecated model failover** | | | | | | **Per-tenant API keys scoped to models** | | | [^34] | [^35] | | **Cost & usage tracking** | | | | | | **OpenAI Administration usage & costs** | | [^36] | | | | **Per-end-user cost on the AWS bill** | | [^25] | [^26] | [^27] | | **Ready-to-use deployment** | | | [^3] | | | **Commercial support** | | | | [^4] | | **Self-hosted** | | | | | | **AWS-native focus** | | [^5] | | | | **Multi-provider support** | | [^11] | | | | **Source license** | AGPL-3.0 (community) · commercial | MIT | MIT-0 | AWS service | | **Distribution & supply chain** | AWS Marketplace · GHCR | pip/PyPI | GitHub (MIT-0) | AWS-managed |

full partial / manual setup not available

!!! info "About the alternatives" - **LiteLLM** — widely adopted multi-cloud proxy with a large open-source community. Ideal when you need a single entry point across OpenAI, Azure, AWS, and others. AWS deployment and security features (WAF, VPC endpoints) require manual setup. Also offers a commercial Enterprise tier. - **Bedrock Access Gateway** — official open-source AWS sample (MIT-0). Covers chat completions and embeddings only. No WAF, auto-scaling, monitoring, or commercial support included. - **Bedrock Mantle** — AWS's own native OpenAI-compatible endpoint backed by AWS's full compliance and SLA. No self-hosting required. Supports the Chat Completions, Responses, and Anthropic Messages APIs — but each model is restricted to specific APIs (frontier GPT = Responses only, Claude = Messages only, open-weight = Chat Completions), and it covers only a subset of Bedrock models (see the [^2] markers in the comparison table above for exact coverage). Guardrails, prompt routers, and cross-region inference profiles are not available on Mantle. Routes through an AWS-managed endpoint, not your private VPC. See [model availability](https://docs.aws.amazon.com/bedrock/latest/userguide/models-endpoint-availability.html). Rather than an either/or choice, stdapi.ai can serve the Mantle catalog itself: enable [Bedrock Mantle Models](features.md#bedrock-mantle-models) to access OpenAI GPT, xAI Grok, and other Mantle-only models through the gateway, with all four text APIs available for every model. --- ## :material-clipboard-check: Quality Assurance "OpenAI-compatible" is easy to claim and hard to keep. The gateway sits between your application and a set of backends that change underneath it — new model generations, new parameters, silently altered behaviour — so its test suite is built to catch that drift before you do.

- :material-test-tube: __8,000+ automated tests__
Run against real AWS services rather than mocks. - :material-shield-check: __95%+ branch coverage__
Measured with every test tier enabled — the full suite, not the offline CI gate that runs on every push. - :material-account-check: __Validated against the vendors__
The same tests run against the real OpenAI, Anthropic, Cohere and Ollama APIs. - :material-robot-happy: __Driven by real client software__
Twenty-two third-party clients — Claude Code, n8n, Open WebUI, Home Assistant and more — driven end to end against a live gateway.

### Compatibility is proven against the real APIs, not against our own docs A gateway tested only against itself proves only that it is self-consistent. The suite runs **the same test bodies against the genuine OpenAI, Anthropic, Cohere and Ollama endpoints**, changing nothing but the URL, and a test that passes here and fails there is a compatibility bug in this product rather than an acceptable difference. The expected behaviour is captured from the vendor's own API before the feature exists, so the implementation is written against a contract that was verified, not assumed. ### Real applications, not just API calls Passing an HTTP test says nothing about whether a real coding agent, chatbot or automation platform actually works. So the suite runs them: **complete third-party client software, unmodified, against a live gateway** — coding agents (Claude Code, Codex, pi, OpenClaw, Hermes, Qwen Code), the n8n workflow runner, a Haystack RAG pipeline, the Open WebUI chat interface, Home Assistant's voice bridge, the LiteLLM proxy, Docling Serve's vision pipeline, LiveKit Agents and Pipecat on the [documented WebRTC and telephony configurations](api_openai_realtime.md#transports), and the LangChain, LlamaIndex, Pydantic AI, Agno, inspect-ai and OpenAI Agents SDK libraries — driving multi-turn tool-calling sessions, document retrieval and reranking, server-side conversations, vector-store retrieval loops and speech pipelines across dozens of models and all four API dialects. A regression that only appears in a real client is caught here, not by you. ### Every model is measured, not assumed Model documentation describes what a model is supposed to accept. What it actually accepts is something else, and it changes between generations of the same model family. Each supported model is **probed empirically** for the parameters and features it genuinely honours — including the parameters it accepts and then quietly ignores, which are the ones that silently produce a wrong answer. The results are recorded and the behaviour is pinned by tests. [See what each model reports](models.md). ### Beyond automated tests - **Every release is validated twice** — the complete suite locally, then again against a real deployment of the exact build being released - **Static analysis and strict typing** on every line of source and test code - **Documented behaviour is tested behaviour** — the compatibility tables on these pages are derived from what the tests assert, so a change in behaviour that the docs do not reflect fails the build - **Continuous review** — periodic audits of the codebase and of the test suite itself, because a passing test that asserts nothing is worse than no test - **Security scanning** of dependencies and container images, with the commercial image validated against AWS Security Hub's Foundational Security Best Practices !!! tip "Found something anyway?" No suite catches everything. If you hit a compatibility difference between stdapi.ai and the API it mirrors, open an issue on [GitHub](https://github.com/stdapi-ai/stdapi.ai/issues) — or [email us](contact.md) if you would rather not report it publicly. That class of bug is treated as a defect, not as expected behaviour. [^1]: Full Bedrock catalog supported; each model must be declared in config (applies to auto-discovery) [^2]: Subset of Bedrock models — mostly newer open-weight models (DeepSeek, Gemma, Qwen, GLM, MiniMax, Kimi, newer Mistral) plus OpenAI GPT/gpt-oss and xAI Grok; newer Anthropic Claude generations are available via the Messages API only. Amazon Nova, Meta Llama, AI21, Cohere, and Stability AI (images) are not available — see [AWS endpoint availability](https://docs.aws.amazon.com/bedrock/latest/userguide/models-endpoint-availability.html) [^3]: CloudFormation reference sample (API Gateway + Lambda, or ALB + Fargate) — no WAF, auto-scaling, monitoring, or commercial support [^4]: Covered through your existing AWS Support plan [^5]: Generalist multi-cloud proxy covering 100+ providers; AWS-specific Bedrock features and security integrations may lag behind dedicated solutions [^6]: Prompt caching and reasoning supported on standard routes; coverage varies by model — not all Bedrock models support prompt caching or extended thinking [^7]: Auto-discovery limited to the single deployed region — some models are only available in specific AWS regions [^8]: Achievable via the LiteLLM router, but requires manually declaring each model per region with explicit TPM/RPM limits — no automatic quota distribution [^9]: Prompt caching on Mantle is supported but model-dependent (per each model card); reasoning is served via frontier models (GPT-5.x, gpt-oss) and select open-weight models (Qwen3 thinking, etc.) [^10]: Single-region deployment — some models are only available in specific AWS regions; no cross-region catalog aggregation [^11]: 100+ providers: OpenAI, Azure OpenAI, GCP Vertex, Anthropic direct, and more — ideal when you need a single gateway across multiple clouds [^12]: Requires connecting Amazon Polly as the TTS backend — not included by default in a LiteLLM on AWS deployment [^13]: Supported by specifying the cross-region inference profile ARN as the model ID — no automatic profile selection [^14]: Anthropic Messages API supported on Mantle for newer Claude generations only — Claude 3.x and some 4.x are not available; structured outputs (`output_config.format`) are rejected with a 400 on Mantle — see [AWS endpoint availability](https://docs.aws.amazon.com/bedrock/latest/userguide/models-endpoint-availability.html) [^15]: LiteLLM ships a [first-class `bedrock_mantle/` provider](https://docs.litellm.ai/docs/providers/bedrock_mantle) covering all Mantle models, so reaching Mantle needs no custom endpoint. Bedrock and Mantle remain two separate providers, each model declared in `model_list`, rather than one auto-discovered catalog [^16]: LiteLLM translates between API formats per provider adapter; coverage is not a guaranteed all-text-APIs-on-every-model surface [^17]: Conversation state kept in LiteLLM's own datastore rather than native provider server-side storage [^18]: Served via LiteLLM's `/responses` endpoint, auto-bridged to `/chat/completions`; no native Bedrock Responses passthrough [^19]: Mantle uses Projects/Workspaces (tag-based cost allocation via Cost Explorer) for workload isolation instead of application inference profiles — see [Amazon Bedrock Projects](https://docs.aws.amazon.com/bedrock/latest/userguide/projects.html) [^20]: LiteLLM provides an [MCP gateway](https://docs.litellm.ai/docs/mcp/) that proxies configured third-party MCP servers and converts OpenAPI specs to tools — a related capability, but it does not expose LiteLLM's own AI and media endpoints as tools [^21]: Amazon Bedrock is a [first-class batch provider](https://docs.litellm.ai/docs/providers/bedrock_batches) for LiteLLM's Batches API — on the proxy only, not the SDK, and backed by [Managed Files](https://docs.litellm.ai/docs/proxy/managed_batches) with a Postgres database plus an operator-configured S3 bucket and Bedrock batch role. LiteLLM's own cost tracking for batches is an Enterprise feature [^22]: The Bedrock Mantle endpoint [serves](https://docs.aws.amazon.com/bedrock/latest/userguide/endpoints.html) the Responses, Chat Completions and Anthropic Messages APIs only. Amazon Bedrock does offer an [OpenAI-compatible Batch API](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-openai-batch.html) on its `bedrock-runtime` endpoint — for OpenAI models only, reading its input from an S3 URI you upload yourself rather than through a Files API [^23]: With Amazon Bedrock it is a [bridge to a knowledge base you registered yourself](https://docs.litellm.ai/docs/providers/bedrock_vector_store): search, retrieve, list, update and delete are forwarded, while OpenAI-shaped store creation and [file attachment](https://docs.litellm.ai/docs/vector_store_files) accept the `openai` provider only. LiteLLM's own [`/v1/rag/ingest`](https://docs.litellm.ai/docs/rag_ingest) route does chunk, embed and index into a Bedrock knowledge base, but it is not part of the OpenAI API surface an unmodified client speaks [^24]: [Emulated](https://docs.litellm.ai/docs/tutorials/file_search_responses_api): the store is presented to the model as a function tool and the search is executed by the proxy rather than by the model's own server. LiteLLM documents that `file_citation` annotations can come back empty when the vector backend does not return the file metadata they need [^25]: Spend is attributed per key and per user in [LiteLLM's own database](https://docs.litellm.ai/docs/proxy/cost_tracking), not in AWS's billing data. Bedrock `requestMetadata` can be forwarded, which AWS surfaces in [invocation logs rather than Cost Explorer or CUR 2.0](https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-request-metadata.html) [^26]: Application inference profiles put billed dollars in [Cost Explorer and CUR 2.0](https://docs.aws.amazon.com/bedrock/latest/userguide/cost-management.html), but per application rather than per end user — the gateway does not map a caller to a profile [^27]: [IAM principal attribution, Projects and Workspaces](https://docs.aws.amazon.com/bedrock/latest/userguide/cost-management.html) put billed dollars in Cost Explorer and CUR 2.0 — per identity or per project rather than per end user, and behind a shared gateway every caller arrives as the same identity [^28]: [`/images/edits` lists AWS Bedrock (Stability) among its providers](https://docs.litellm.ai/docs/image_edits), so Stability's editing operations are reachable on Bedrock. It does not extend to the other Bedrock image models: the [Bedrock provider page](https://docs.litellm.ai/docs/providers/bedrock) lists `/images/generations` but not `/images/edits` among its supported OpenAI endpoints, and Amazon Nova Canvas and Titan are documented for [generation](https://docs.litellm.ai/docs/providers/bedrock_image_gen) only [^29]: LiteLLM integrates [Ollama as one of the backends it calls](https://docs.litellm.ai/docs/providers/ollama). Its proxy does not serve Ollama's own `/api/*` routes, so an Ollama-native client cannot point at it [^30]: Reachable by declaring the endpoint's ARN as a model entry (`bedrock//`) in the [Bedrock provider configuration](https://docs.litellm.ai/docs/providers/bedrock): one entry per endpoint, and no discovery of what is deployed [^31]: The model list is discovered from Bedrock's foundation models and inference profiles only. The [project's README](https://github.com/aws-samples/bedrock-access-gateway) documents Marketplace, custom-model and provisioned-throughput ARNs as unsupported, and states there is no plan to support SageMaker models [^32]: A model deployed to a Marketplace or SageMaker AI endpoint is invoked through Bedrock's own Converse and InvokeModel APIs, and is absent from [Mantle's API compatibility matrix](https://docs.aws.amazon.com/bedrock/latest/userguide/models-api-compatibility.html) [^33]: Each endpoint is declared in `model_list` through the [`sagemaker_chat` provider](https://docs.litellm.ai/docs/providers/aws_sagemaker). Endpoints are not discovered, and nothing is documented for an endpoint scaled to zero [^34]: A single API key is read from AWS Secrets Manager, Parameter Store or the environment at start-up, so there is no per-caller key to scope [^35]: [Bedrock API keys](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html) are restricted by an IAM policy on the identity behind the key rather than by a model or endpoint scope carried on the key itself [^36]: The same data is served by [LiteLLM's own `/spend/*` routes](https://docs.litellm.ai/docs/proxy/cost_tracking), reported per key, user and team in a different wire format, so a dashboard written against OpenAI's Administration API does not read it