Why AI gateway cost control starts with keys, not invoices
When several teams call hosted LLM APIs through shared keys, the provider invoice arrives as one number that no cost center can claim, and nothing stops spend until the bill has already landed. The control point is a gateway that issues virtual keys per team and application, enforces budgets and rate limits on each key, and writes every call's cost to a database your organization runs. Once spend is tied to a key, and a key is tied to a cost center, finance can charge usage back and engineering can see which application caused a spike.
This is different from general gateway work in three ways. Finance, not the platform team, owns the spend data, so the schema, retention and reconciliation to invoices need sign-off from the controller's office. Chargeback rules (who pays for shared models, how failed or retried calls are counted, what happens when a team exceeds its allocation) are policy decisions, not configuration defaults. Budget breach handling also needs an owner: a hard stop, a temporary increase through an approval step, or an alert that a named person must act on. Confirm these choices before the gateway goes live, because the keys and budgets are only as useful as the rules behind them.
For a first deployment, LiteLLM is the gateway: its virtual keys need a PostgreSQL database, and PostgreSQL holds the spend records. Redis becomes necessary once more than one proxy instance runs, because shared rate limits and router state depend on it. Apache APISIX or Kong is worth considering only where your organization already operates it for other APIs, so AI traffic follows an existing policy and operations model. Ask your implementation partner to confirm how the chosen gateway's cost tracking maps to your cost centers, and which features your license tier covers before you commit to a design.
Requirements finance and platform teams must agree before the build
This table lists the gateway controls that cost reporting depends on, the LiteLLM source behind each one, and what the build has to do about it. Read each row as a decision to settle between finance and platform engineering before configuration starts. The main takeaway is that chargeback is only as accurate as the key-to-team mapping, the spend store and the retention rules agreed up front.
| Requirement | Source | What it means for the build |
|---|---|---|
| Virtual key per team and application | LiteLLM virtual keys docs | Issue keys per team and per application so every call maps to an owner. Agree the naming scheme with finance before any key is issued. |
| Per-key, per-user and per-team budgets | LiteLLM virtual keys docs | Set budgets at the level that matches the cost center. Decide who approves a temporary budget increase and how long it lasts. |
| TPM and RPM limits | LiteLLM virtual keys docs | Cap tokens and requests per minute per key to contain runaway jobs. Test the limits against real batch workloads before rollout. |
| Restricting keys to approved models | LiteLLM virtual keys docs | Limit each key to the models its team is allowed to pay for. Confirm the approved model list with the business owner and the security team. |
| Spend records in PostgreSQL | LiteLLM virtual keys docs and production guide | Virtual keys need a PostgreSQL database, which becomes the source of spend data. Plan backups and access controls for it as a finance record. |
| Shared rate limits across instances | LiteLLM production guide | Running more than one proxy instance requires Redis 7.0 or newer for shared rate limits and router state. Budget for this component and its operations. |
| Admin UI SSO and five-user limit | LiteLLM admin UI SSO docs and Enterprise docs | SSO is free for up to 5 users from v1.76.0. Larger finance and platform teams need an Enterprise license, so confirm the user count before design. |
| Audit logs and team RBAC | LiteLLM Enterprise docs | Audit logs and organization or team RBAC are Enterprise features. Decide whether chargeback approvals need an audit trail before choosing the license tier. |
| Retention of spend and prompt logs | EU AI Act Article 19 (where high-risk use applies) | Set separate retention periods for spend records and prompt logs. Where high-risk use applies, logs must be kept for at least six months unless other law provides otherwise. |
Which open-source platforms fit cost control and chargeback
Cost control depends on three layers: a gateway that issues keys and enforces budgets, a store that records spend per team, and a serving layer that decides which model answers each request. The options below cover the gateway, the trace and cost analysis layer, and the cheaper self-hosted model route. Your existing API standard and team skills should decide which gateway you run.
LiteLLM for keys and budgets
LiteLLM sits between applications and more than 100 LLM providers, exposed in the OpenAI request format. Virtual keys can carry per-key, per-user and per-team budgets, TPM and RPM limits, and model restrictions, and spend is tracked in PostgreSQL. The core code is MIT licensed outside the enterprise/ directory. Check which controls you need, since SSO beyond the free user limit, SCIM, audit logs and team RBAC sit in the enterprise license. Confirm the PostgreSQL and Redis sizing for your request volume before you commit to a design.
Langfuse for per-trace cost analysis
Langfuse records traces, prompts and token usage so you can see cost by feature, application or trace rather than only by key. Its core features and APIs are MIT licensed with no feature limits in the open source version. Project-level RBAC, data retention policies, audit logs and server-side masking need an Enterprise license key. A self-hosted deployment runs Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, so budget for that operations load alongside the gateway.
Apache APISIX as the API standard
Apache APISIX is a cloud-native API gateway with AI gateway capabilities, licensed under Apache-2.0. It fits best where your organization already runs APISIX for API traffic, because keys, rate limits and logging stay under one set of policies and one operations team. Confirm that the AI plugins cover the per-team budget and cost attribution you need, since token accounting may need a separate store or custom plugin. Test the gateway behavior against the model providers you actually use.
Kong Gateway as the API standard
Kong Gateway is an Apache-2.0 licensed API gateway that can also front LLM traffic. If your API estate already runs on Kong, extending it to model calls keeps authentication, rate limiting and observability in one platform and avoids a second gateway to operate. Confirm which AI plugins and budget controls are in the open source edition and which need Kong's commercial offerings, and verify how per-team spend is reported before relying on it for chargeback.
vLLM as the self-hosted route
vLLM is an Apache-2.0 inference engine that serves open-weight models behind OpenAI-compatible endpoints, so the gateway can route low-sensitivity or high-volume requests to it. It has no paid edition, so the cost comes from accelerator capacity, the surrounding infrastructure and the people who operate it. Idle GPUs still cost money, so model the utilization you expect before counting savings. Keep the vLLM endpoint off the public network, because its --api-key option does not cover every endpoint.
How a virtual key turns a model call into a cost center line
Every model call through the gateway should be traceable to one cost center before it leaves the platform. The application sends its request with a virtual key issued to a team or application, not with a provider API key. The gateway checks that key against its budget, its TPM and RPM limits and the list of models it is allowed to use. If all checks pass, the router sends the request to a hosted provider or a self-hosted model, then writes the cost to PostgreSQL along with the key, the team and the model name. Because LiteLLM stores virtual keys in PostgreSQL and supports per-key, per-user and per-team budgets, the team record is where finance's cost center mapping should live.
Decide in advance what happens when a budget is breached. A hard stop protects finance but can take a production workflow offline, while an alert-only setting leaves the overrun unbounded. Confirm with the implementation partner how the chosen LiteLLM version handles a breached budget for each key type, and document who may approve a temporary budget increase, for how long and against which cost center. Spend updates are batched to the database every 60 seconds at scale, so a small lag between a call and its ledger line is expected. Ask finance whether that tolerance fits month-end close and whether any cost center needs real-time enforcement.
The mapping from key to cost center must stay stable. Renaming a team or reissuing its key mid-quarter splits history across two records and makes chargeback reports hard to reconcile. Keys should be rotated on a schedule that operations can execute without breaking production, and the LITELLM_MASTER_KEY, which must start with sk-, should sit in a secret manager rather than a configuration file. Confirm which secret manager integrations your license tier includes, and agree with finance who owns the key register, how revoked keys are retired and whether ledger rows keep the cost center code as a field, not as a derived name.
Routing cheap requests to self-hosted models without degrading quality
LiteLLM's router decides which deployment serves each request when several models or providers share one model name. Its documented strategies are simple-shuffle, usage-based, latency-based, least-busy and cost-based. Simple-shuffle is the recommended default and is the right starting point for most teams. Cost-based routing sends requests to the cheapest eligible deployment, which suits workloads where quality is already proven across models. Latency-based and usage-based routing spread load according to response times or token consumption, which helps when one provider is slow or rate limited.
- Simple-shuffle first: Start with the recommended default and measure before changing the strategy.
- Cost-based routing: Route only to deployments you have tested for the task, otherwise cheaper models may quietly lower answer quality.
- Latency and usage-based routing: Use these when response time or per-deployment token limits are the main constraint.
- Retries and cooldowns: The router retries failed calls and pauses a deployment after repeated failures, so a bad endpoint stops receiving traffic.
- Priority ordering and session affinity: Set failover order for deployments, and use session affinity so multi-turn conversations stay on the same backend.
Confirm with your platform team which strategy each model group uses, and check the routing documentation for the version you run.
Low-sensitivity, high-volume tasks such as classification, summarization of non-confidential text or batch enrichment are often the best candidates for self-hosted models. vLLM serves open-weight models through vllm serve and exposes OpenAI-compatible endpoints, including /v1/chat/completions and /v1/embeddings. The gateway can register the vLLM server as one more deployment, so applications keep calling the same interface. Prometheus-format metrics at /metrics report request counts, token throughput, latency and KV cache use, which gives you the data to compare cost and performance.
- OpenAI-compatible endpoints: Applications can point at vLLM through the gateway without code changes to the request format.
- Cost moves to capacity: API token charges become GPU or accelerator capacity, power, hosting and the staff who operate the service.
- Security settings: vLLM's
--api-keyoption does not cover every endpoint, so place a reverse proxy in front that allows only the endpoints users need. - Multi-node isolation: Vendor documentation states inter-node traffic is insecure by default, so keep nodes on an isolated network.
- Metrics for chargeback: Feed
/metricsinto your monitoring stack to track utilization per model, which supports cost allocation.
Before moving a workload, run a side-by-side evaluation on your own labeled examples, compare accuracy and failure rates with the hosted model, and confirm GPU sizing with the vLLM documentation and your hardware vendor.
Routing cheaper is only a saving if the answers still meet the business need. Set acceptance criteria for each task before any traffic moves, including accuracy on a representative test set, format compliance, refusal rates and latency targets agreed with the application owner. Keep the hosted model as the reference and run both in parallel on the same inputs. Route a small share of production traffic only after the offline results hold, and keep the fallback path ready so you can return a workload quickly if quality drops.
- Representative test sets: Build samples from real requests with sensitive data removed, and label expected outputs with domain experts.
- Shadow runs: Send copies of requests to the candidate model and compare results without showing them to users.
- Gradual shift: Move a limited percentage of traffic, watch error and quality metrics, then widen the change.
- Per-task thresholds: Record separate acceptance criteria for each application, since a summary task and a customer-facing answer tolerate different error rates.
- Change control: Log the model version and routing rule in effect for each request, so results can be traced later.
Ask your implementation partner how they will run and retain these evaluations, and confirm which tool in your stack will hold the test results.
How a chargeback rollout runs in phases
The sequence moves from knowing what model calls exist to billing cost centers from gateway data, with each phase producing an artifact that the next one depends on. Finance and platform teams agree the rules before any charge is issued, so the numbers in a bill can be explained and challenged.
Inventory current model calls and keys
The platform team, with application owners, lists every application, script and vendor integration that calls a model provider today, including the API keys in use, who holds them and which providers they reach. The output is a register of callers mapped to teams and applications, with shared or orphaned keys flagged for replacement. The step is done when every known caller has an owner and no provider key is undocumented.
Agree the cost center model with finance
Finance and the platform lead decide how usage maps to cost centers, for example one virtual key per team, per application or per cost center, and how shared platform overhead is treated. They also agree the unit of charge, the reporting period and who approves budget changes. The output is a written allocation rule set that names each cost center, its owner and its key scope. The step closes when finance signs off the mapping and the rules are stored with the gateway configuration.
Deploy the gateway with PostgreSQL and Redis
The platform team deploys the gateway in the organization's own infrastructure with PostgreSQL as the database that backs virtual keys and spend records, and Redis once more than one proxy instance runs, for shared rate limits and router state. The master key is kept in a secret manager, and the admin interface is placed behind the organization's identity controls. The output is a tested deployment where a test call produces a spend record under a known key. The step closes when that record is verified in the database.
Pilot with one team under budgets and limits
One team with a clear model use case moves its traffic through the gateway using virtual keys with a budget, request and token limits, and an allowlist of approved models. The team lead and finance review daily or weekly spend against the agreed plan, and the platform team checks that blocked requests produce understandable errors. The output is a pilot report covering spend accuracy, limit behavior and any gaps in the key mapping. The step closes when finance accepts the pilot numbers as matching the team's own expectations.
Export reporting to cost centers
The platform team builds a recurring export of spend by key, team, model and period from the gateway database and sends it to finance for journal entries or internal invoices. Finance checks a sample of lines against provider invoices and the gateway records, and the team leads confirm that the attribution matches their applications. The output is a repeatable reporting package with a documented reconciliation procedure. The step closes when one full period is reported and reconciled without manual corrections to the key mapping.
Expand and govern budgets over time
Additional teams are onboarded using the same key, budget and reporting template, and budget changes follow a documented request and approval path, including temporary increases. The platform team reviews keys that are unused, over budget or shared, and reviews routing rules that move cheap requests to self-hosted models where data rules allow. The output is a governance calendar, a change log for budgets and keys, and a list of onboarded cost centers. The step is ongoing and is checked each period against the reporting package.
What drives the cost of building and running the gateway
Is the LiteLLM gateway itself free to run?
The core gateway is free to use, but the cost is not zero. LiteLLM's code outside its enterprise directory is MIT licensed, so the software has no license fee for the core proxy. Enterprise terms apply to the enterprise directory, and from v1.76.0 SSO is free for up to 5 users, with an Enterprise license needed beyond that. Audit logs, SCIM and organization and team RBAC are also Enterprise features, so ask the partner which of your requirements need a paid license before you finalize scope.
Which gateway features need an enterprise license?
Plan for the enterprise line items early, because they are the main licensing decision. According to LiteLLM's enterprise documentation, the Enterprise license adds:
- SSO and SCIM beyond the free 5-user limit
- JWT authentication with identity provider tokens
- Audit logs and organization and team RBAC
- IP allowlisting and secret manager integrations
- Team-level guardrails and logging
Request the current price from LiteLLM directly, since DeployOpen does not set or publish license pricing.
What do PostgreSQL and Redis add to the monthly bill?
PostgreSQL is required for virtual keys, budgets and spend tracking, and Redis becomes required once more than one proxy instance runs. LiteLLM's production guide names PostgreSQL as the primary supported database and requires Redis 7.0 or newer for shared rate limits, router state and cache. The recurring cost is the hosting: managed or self-operated database and cache instances in your own cloud account or data center, plus backups, high availability and monitoring. For sizing, the guide suggests 1 vCPU and 4 GiB memory per worker. Ask for the instance classes, backup retention and failover design in any quote.
Does adding Langfuse for observability change the cost?
Yes, it adds a second stack with its own storage and compute. Langfuse's core features are MIT licensed, but a self-hosted deployment runs Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Langfuse's scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Storage grows with prompt and trace volume, so ask for a retention and sizing estimate based on your expected request volume.
What does implementation and finance integration cost?
Implementation is usually the largest one-time cost. Work includes designing the key and team hierarchy, mapping cost centers to virtual keys, connecting SSO, building spend exports for finance, and testing budget enforcement. Integration with your ERP, general ledger or internal billing tool depends on how many systems receive the data and whether a chargeback report needs approval workflows. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so the quote follows from that written scope.
What are the ongoing operations and upgrade costs?
Operations is the recurring cost that most budgets miss. Someone must patch the gateway, rotate the master key kept in a secret manager, monitor spend and back up the database. LiteLLM maintains support for the four most recent stable minor versions for both open source and Enterprise deployments, so you need a rolling upgrade cadence within that window. Ask a partner whether support, upgrades and continuous testing are covered by a retainer, and what the retainer scope and response expectations are.
How much do GPUs for self-hosted models add?
GPU capacity is usually the largest recurring cost when you route traffic to self-hosted models. vLLM has no paid edition, so the cost comes from accelerator capacity, the surrounding infrastructure, implementation and the people who operate it. Costs rise with model size, concurrency, latency targets and redundancy, and fall when you keep the cheapest models on shared capacity and send only suitable requests to them. Ask for hardware specifications, utilization assumptions and a capacity plan that shows what runs on GPUs and what stays on hosted APIs.
What should we request in a quote for the gateway?
Ask for a quote that separates one-time and recurring costs. A useful quote includes:
- Implementation scope, deliverables and timeline in writing
- Software licenses, with enterprise features listed separately
- Database, cache and object storage hosting, with sizing assumptions
- Finance integration and reporting work
- Observability stack, if included, with retention settings
- Upgrade, support and testing terms, including any retainer
- GPU or inference capacity, if self-hosted models are in scope
Request each line with its assumptions so you can compare options.
Evidence finance and auditors ask for, and which component produces it
This table maps each piece of evidence that finance teams and auditors typically request for LLM spend to the component that produces it and the team that should own it. Read it as a checklist for the gateway design: if a row has no producing component you have configured, the chargeback or audit question will be hard to answer. Confirm retention and licensing details with your own environment and vendors before relying on any row.
| Evidence | Producing component | Owner |
|---|---|---|
| Budget definitions per key and team | LiteLLM config and virtual key records in PostgreSQL, including per-key, per-user and per-team budgets | Platform engineering, with finance approving budget values |
| Spend by key, team and model | PostgreSQL spend tables populated by the LiteLLM proxy, batched to the database at scale | Platform engineering for data, finance for cost center mapping |
| Access control and admin changes | Enterprise audit logs, available only if the enterprise license covers them; confirm the feature list with the vendor | Security or IT governance |
| Model routing decisions | Gateway request logs showing which provider or self-hosted model served each call and any fallback | Platform engineering, reviewed by security |
| Retention of request logs | Log storage and retention settings in the gateway and any observability store; confirm whether EU AI Act Article 19 applies to your system | Compliance and legal, with platform engineering |
| Trace-level cost records | Langfuse traces with usage and cost fields, if Langfuse is deployed and receives gateway traces | Application teams, with platform engineering |
| Chargeback allocation rules | Documented mapping from virtual keys and teams to cost centers, kept outside the gateway as a versioned file | Finance operations |
What to ask an implementation partner before signing
Start with the key model, because every cost report depends on it. Ask the partner how virtual keys map to teams, applications and cost centers, who owns each key, and where that mapping is stored. Ask whether the chargeback tags travel with each request into the spend records in PostgreSQL, and how a key is retired when a team is reorganized. Then ask which budget and limit features they will build on the open-source edition and which need an enterprise license. LiteLLM's virtual keys support per-key, per-user and per-team budgets, TPM and RPM limits and model restrictions, but its SSO beyond the free user limit, SCIM and team-level audit logs sit in the enterprise scope, so the license decision belongs in the design, not after go-live.
Next, ask how the platform will hold up under load. Request the partner's plan for PostgreSQL sizing, the spend update batching interval and the Redis deployment that shares rate limits and router state across proxy instances. LiteLLM's production guide names PostgreSQL as the primary database and requires Redis 7.0 or newer once more than one proxy instance runs, and it suggests batching spend writes every 60 seconds at scale. Ask how a budget breach reaches a named owner: which alert channel, which threshold, and what happens to the key while the owner decides. Also ask who may approve a temporary budget increase, how that approval is recorded, and whether it expires automatically.
Finally, ask how routing to self-hosted models is tested before it carries real spend. A credible plan includes failover drills, a check that cheap requests reach the self-hosted endpoint and that the cost-based or priority routing settings behave as written, and a test that restricted keys cannot reach models outside their list. Ask what finance receives at handover: a dated spend export by key and cost center, the reconciliation method against provider invoices, the runbook for corrections and the access model for finance users. Confirm these items in writing, with named deliverables, before signing a fixed-scope agreement.
Questions buyers ask before hiring help with LLM cost control
How much effort does an LLM cost control gateway build take?
The effort depends on how many providers, teams and applications the gateway must cover, and on how much of the reporting must match your finance structure. The main work items are deploying the gateway with a PostgreSQL database, setting up virtual keys and budgets per team and application, connecting identity, wiring each application to the gateway endpoint, and building the spend reports finance will use. Multi-instance deployments add Redis for shared rate limits and router state, which LiteLLM's production guide calls for once more than one proxy instance runs. Ask any partner to split the quote into those work items so you can see what is one-time and what recurs.
How long does a gateway rollout take?
The rollout length depends on scope, so it should be agreed in writing before work starts. A pilot with one team and two model providers moves much faster than a rollout that moves every application behind the gateway and ties spend to cost centers. The schedule usually depends on how many applications need code changes to point at the gateway, how quickly your identity team can connect SSO, and how long finance takes to approve the cost center mapping. Ask for phases with clear exit criteria so you can see what is live at each stage.
What does the work need from finance and platform teams?
Finance needs to supply the cost center structure, the owner of each team or application, and the rules for allocating shared model usage, such as platform tooling or evaluation runs. Platform engineering needs to provide the hosting environment, database and secret manager, network paths to model providers, and a decision on who administers the gateway. Both groups should agree on the monthly reporting format and who signs off on budget changes before the first spend report is produced. Missing these decisions is the most common reason chargeback reports are disputed after launch.
Can an internal team run this without outside help?
Yes, a capable internal platform team can deploy LiteLLM, PostgreSQL and Redis in its own infrastructure, since the project is open source under the MIT license outside its enterprise directory. The harder parts are usually the operating model: keeping virtual keys and budgets aligned with cost centers, rotating master keys held in a secret manager, handling provider changes, and upgrading the gateway while several teams depend on it. Many organizations decide that an outside partner should cover the first build and handover while internal staff take over operations. Ask any partner what the handover covers and what the ongoing support options are.
Do we need an enterprise license for LiteLLM cost tracking?
Core virtual keys, per-key and per-team budgets, rate limits and spend tracking are part of the open source gateway, so cost control does not depend on an enterprise license. Features beyond that boundary need to be checked one by one. LiteLLM's documentation states that SSO for the admin UI is free for up to 5 users from v1.76.0, and that an Enterprise license is needed beyond that. Enterprise also covers SCIM, audit logs, organization and team RBAC and some secret manager integrations. Confirm each feature you need against the current LiteLLM enterprise documentation and your license terms before committing to a design.
How are budgets reset and reported to finance?
LiteLLM lets you set budgets per key, per user and per team, and it supports temporary budget increases for approved one-off work. How budgets reset, such as monthly or on a fixed date, and how spend is exported into your general ledger or chargeback tool are configuration and reporting decisions that should be written down early. Confirm with the partner which reset intervals the gateway supports in your version, how spend records are stored in PostgreSQL, and how long they are retained. Spend updates are batched to the database at scale, so ask how close to real time the figures shown to teams will be.
What happens when a model provider changes its prices?
Price changes affect the cost figures the gateway records, so the gateway needs an up-to-date price table for each model it routes to. When a provider changes prices, the reported spend for affected teams can shift even though usage is unchanged, which is why finance should expect explanations for month-over-month differences. Cost-based routing can move traffic to cheaper models, but it should only do so under rules that the owning team has approved. Ask the partner how price data is updated, who approves routing changes, and how budget alerts are triggered when spend moves faster than expected.
Will routing cheap requests to self-hosted models break applications?
Routing can change model behavior, output quality and latency, so it should be tested before traffic is moved. The gateway exposes one OpenAI-compatible interface, so applications often keep the same calls, but the answers from a self-hosted model may differ from a hosted one. Start with low-risk workloads, compare outputs on a fixed test set, and define which request types may fall back to a different model. vLLM exposes OpenAI-compatible endpoints, which makes it a common target for this routing, but its own security guidance says the endpoints must be placed behind a reverse proxy that allowlists only intended paths. Confirm that design with your security team before exposing it.
How DeployOpen scopes and supports a self-hosted gateway for cost control
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where a gateway would run. For a cost control engagement, that means the work covers the gateway itself, its PostgreSQL spend database, the Redis layer needed once more than one proxy instance runs, the team and key structure, and the spend reporting finance will use. Before any work starts, the scope is agreed in writing, so the team, the virtual key model, the budget rules and the cost center export format are settled up front rather than discovered during the build.
Most engagements are fixed-scope. The written scope names the deliverables, such as the proxy deployment, the mapping of teams and applications to keys, the budget and rate limit configuration, the routing rules for cheaper or self-hosted models, and the documentation for finance and platform operators. It also states what sits outside the scope, for example model hosting on GPUs, enterprise license purchases or changes to applications that call the gateway. DeployOpen does not publish a price list. A quote follows from the written scope, so the reader should ask for the scope document first and check that each cost driver it names, such as the number of teams, providers and environments, is explicit.
Ongoing work is handled through retainers for support, upgrades and continuous testing. Gateway budgets and provider prices change over time, new model versions appear, and the gateway's own releases need regular upgrades, so a retainer is the natural place to keep those running after the first rollout. Before signing, confirm with DeployOpen what the retainer covers, how upgrades are tested against your virtual keys and budgets, and who is responsible for provider invoices and the cost reports. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports, attestations or certifications; independent auditors and certification bodies perform those.
