# Choose your AI API platform.

Decision pages comparing an Apertis workspace with other model-access platforms on control boundary, evidence trail, and the migration path to take. Each page states fit, not a ranking claim.

Canonical: https://apertis.ai/compare

## Side by side

| Question | Apertis | OpenRouter | Together AI | LiteLLM |
| --- | --- | --- | --- | --- |
| Control boundary | **Virtual keys, model policy, quota, and Activity records share one workspace context.** | Budgets, routing controls, and management keys are documented platform features. | Capacity and deployment choices follow Together AI's current product tiers. | Virtual keys, budgets, fallback, and logging are published proxy capabilities. |
| Upstream keys | **Apertis holds the upstream provider credentials; your team issues bounded workspace tokens, each with its own quota.** | One OpenRouter key authenticates the request and OpenRouter reaches the providers; their pricing page also lists bring-your-own-key allowances. | One Together API key authenticates against Together's own fleet. | You configure each upstream provider key in the proxy you run, and front them with virtual keys. |
| Routing decision | **Channel selection follows declared policy — user group, model availability, and channel priority.** | Their quickstart states fallbacks are handled automatically and the most cost-effective option is picked per request. | Serverless, provisioned throughput, and dedicated inference share one API; the model parameter selects the mode. | Routing is whatever your own proxy configuration declares. |
| Verify before migration | **Run one workload and match the response to its Activity record.** | Review the current pricing, routing, and provider documentation for the chosen model. | Confirm model availability, endpoint type, and current price on Together AI. | Test deployment, database, secrets, upgrades, and observability in your own environment. |
| Spend and limits | Quota is enforced per token, and every call lands in the workspace Activity record. | **Their pricing page lists budgets and spend controls, activity logs with export, and rate limits that differ by plan.** | Pricing is per token, per minute, or per GPU-hour by mode; the pricing page does not state spend or rate limits. | Budgets and rate limits per virtual key or user, with spend tracking and an admin UI. |
| Primary job | Operate model access, keys, policy, and usage in one governed workspace. | Reach and route across a broad provider marketplace through one API. | **Run models through serverless, dedicated, or other published inference products.** | Run or deploy a compatible proxy across supported providers. |

Bold marks the strongest fit for that question. It is not always Apertis.

Competitor cells read from each comparison's own sources on 2026-09-07. They are other companies' current pages and they move -- verify the side you are moving away from before you choose.

## Comparisons

- [Apertis vs OpenRouter](https://apertis.ai/compare/openrouter) ([markdown](https://apertis.ai/compare/openrouter.md)): You want one compatible API across many models and need to decide whether marketplace-style routing or a governed workspace better matches the workload.
- [Apertis vs Together AI](https://apertis.ai/compare/together-ai) ([markdown](https://apertis.ai/compare/together-ai.md)): You need production inference and must decide whether the workload calls for a governed multi-provider gateway or Together AI's inference and deployment platform.
- [Apertis vs LiteLLM](https://apertis.ai/compare/litellm) ([markdown](https://apertis.ai/compare/litellm.md)): You want a compatible multi-provider layer and need to decide whether your team should operate the proxy or consume a managed gateway workspace.