Comparison
Conifer and Requesty compared
Both put one API in front of AI models from many providers, and both have a router in beta that picks a model for you. This page sets out how each one works, using each company’s own published documentation.
Summary
Requesty is a hosted AI gateway for more than 600 models, with routing policies, spending limits, governance and request logs. Its Auto Routing, in beta, picks a model for each conversation from routes you describe in plain words. Conifer is a hosted gateway for more than 230 models, each billed at its maker’s list price from a prepaid balance. Its router, also in beta, picks from a pool of models you approve and adds no fee.
Requesty details were read from requesty.ai and docs.requesty.ai on 7 November 2026. Plans and prices change; check the linked pages before you decide.
Side by side
| Topic | Conifer | Requesty |
|---|---|---|
| Where it runs | A hosted service at one Conifer address; there is nothing to deploy | A hosted service with a global address and an EU address in Frankfurt. Its playground also offers US and Asia-Pacific routers, and an admin can limit an organization to chosen regions |
| Model access | More than 230 models paid from one prepaid balance, with no provider accounts needed; your own Azure OpenAI resource can sit behind the same key | “600+ models” from “30+ providers”, paid from a prepaid balance in US dollars. You can add your own keys for OpenAI, Anthropic, Google AI Studio, Vertex AI, Mistral and xAI |
| Interfaces | OpenAI Chat Completions, OpenAI Responses and Anthropic Messages, on one key | OpenAI Chat Completions, OpenAI Responses and Anthropic Messages, plus embeddings, speech, transcription and images |
| What you pay | Each model at its maker’s published list price per token, from a prepaid balance, with no subscription. A top-up adds a small processing line that covers Stripe’s card fee. No Conifer fee on usage of your own Azure resource | The pricing page lists a “5% markup on model cost” on pay as you go. The billing docs say a 5% service fee is added to every top-up. The home page lists 0% with your own keys. A free plan covers free models at 200 requests a day |
| Automatic model choice | The router, in beta, picks a model for each turn of a conversation from a pool of up to 64 models you approve, weighing what the request needs against the cost of each model. Only models that can hold the whole request are considered | Auto Routing, in beta. You write a question and a set of routes, each a short description with a model attached. A decision model you choose reads the first user message of each new conversation, picks a route and keeps that model for the conversation |
| When the router cannot decide | The request fails and nothing is charged. The router never falls back to a model of its own choosing | If no route reaches the confidence threshold you set, or the decision model returns an error, the request goes to the fallback model you chose |
| Cost of routing | Routing adds no fee: a request sent to beta-auto costs only the model that answers it | Each decision is billed as a normal request to the decision model, once per conversation |
| A named model | Served as named, or refused. Other models are tried only if you list up to three fallbacks yourself | Called directly, or through a routing policy called by its name: a fallback chain with retries for each model, a weighted load balance, or a latency policy |
| Provider failover | When a provider fails, rate-limits or times out, the gateway serves the same model from another provider at the same price, for models with more than one provider | Set in a fallback policy, which can list the same model from another provider; a rate-limited request then moves to the next entry |
| Allowed models | An admin can limit a key to a list of models, and the router chooses only from your pool | An approved-models list for the organization, with narrower access lists for groups and keys. If none is set, every model in the catalog is allowed |
| Cost on each request | Every response carries the amount charged, itemised by token type, and a streamed response ends with the same receipt | Every chat completion response includes its cost in US dollars; a streamed response includes it when usage reporting is requested |
| Spending limits | A cost ceiling per request, a spend cap per key and a monthly limit on the account. A request that could exceed a ceiling is refused before any provider is called | Monthly limits for each key, user, team and organization, with alerts at thresholds you choose |
| Request logs | The prompt of a standard request is not stored. A response is held for ten minutes so a retry is not charged twice, and request details such as model, tokens and cost are kept for billing | Every request is logged, and the log view shows its full message history. The EU address keeps Requesty’s own processing and storage in the EU, and an organization can require models with zero data retention |
| Enterprise terms | Team accounts with owner, admin and member roles, per-key model scope and spend caps, set up on request | Enterprise lists SSO with Okta, Azure AD, Google Workspace or OIDC, full RBAC and audit logs, guardrails and PII detection, and dedicated support with custom SLAs. Requesty holds SOC 2 Type I and is in the audit period for Type II |
Which one fits
- Requesty may suit you if
- You need requests processed in the EU or in regions you choose, you want SSO, directory sync, guardrails and audit logs in the gateway, you want to write your own routing rules in plain words and keep one model for a whole conversation, or you want to use your own keys for OpenAI, Anthropic, Google, Mistral or xAI.
- Conifer may suit you if
- You want each model billed at its maker’s list price, you want automatic model choice limited to models you approve with no fee for routing, you need each response to state the model that served and the exact amount charged, or you want requests refused before they exceed a cost ceiling.
Moving from Requesty to Conifer
- Address and key
- Point an OpenAI or Anthropic client at Conifer and use a Conifer key.
OPENAI_BASE_URL=https://api.conifer.build/v1 OPENAI_API_KEY=$CONIFER_API_KEY - Model names
- Use the model names in the Conifer catalog. Names with the lab in front, the way Requesty writes them, such as
anthropic/claude-opus-5, are also accepted. A model Conifer does not carry is refused, not replaced. - Routing policies
- Conifer picks the provider for each request and tries another provider for the same model if one fails. To try other models, list up to three fallbacks in a request header. For automatic model choice, send
beta-autoas the model and set your routing pool in the console. - Spending limits
- Set a spend cap on each key and a monthly limit on the account, and send a cost ceiling with any request that needs one.
- Check first
- Your own Azure OpenAI resource can sit behind your Conifer key. AWS Bedrock and Google Vertex are not served as your own endpoints today, and the moderations endpoint is not served.
Replace your provider key has the full steps, the router reference covers automatic model choice, and Routing covers fallbacks and failover.
Read more
- Conifer Router
- Send one model name and Conifer chooses a model for each request from a pool you approve.
- What is an LLM router?
- How a router picks a model for each request, and what it should tell you afterwards.
- Conifer vs OpenRouter
- The two gateways side by side, from each company's own documentation.
- Conifer vs Not Diamond
- A gateway with a router and a routing service side by side, from each company's own documentation.
- All comparisons
- Conifer compared with eleven other LLM gateways and routers, from their own documentation.
Questions
- Is Conifer an alternative to Requesty?
- Yes. Both give one API key for models from many providers on OpenAI- and Anthropic-compatible interfaces, with fallbacks, spending limits and a router in beta. They differ in fees, in how the router decides and what happens when it cannot, and in regional and enterprise options, as the table on this page sets out.
- How is Requesty’s Auto Routing different from Conifer’s router?
- In Requesty, you write the routes: a decision model reads the first message of a conversation, picks a route and keeps that model for the conversation, using your fallback model when it is unsure. Conifer’s router picks from a pool of models you approve, weighing each request against cost, and if it cannot choose, the request fails and nothing is charged.
- Does Conifer charge for routing?
- No. A request sent to the router costs only the model that answers it, and every response names the model the router chose and what the request cost.
- Can I keep my Requesty model names?
- For models in the Conifer catalog, yes. Conifer accepts model names with the lab in front, the way Requesty writes them. A model Conifer does not carry is refused rather than replaced. Routing policies do not carry over; list up to three fallback models in a request header instead.