Bring Your Own LLM

Bring Your Own LLM (BYOLLM) lets you configure your organization’s large language model providers for use with ADM. You can connect a provider directly or connect through an enterprise LLM gateway.

ADM provides the agents and tools that support data-management tasks. The configured model interprets requests and participates in those workflows, such as discovering assets, investigating data-quality issues, and coordinating actions.

Before you begin

Prepare the following information before configuring a provider:

• Access to ADM Settings and permission to configure LLM providers.

• Credentials for the provider or gateway, and access to the models you intend to use.

• The applicable endpoint, region, deployment name, or model identifier.

• For a gateway connection, the authentication details and any additional headers supplied by your gateway administrator.

Confirm with your administrator that the ADM environment can reach the required provider and authentication endpoints. Use a provider and model approved for the data your organization will process.

Access LLM settings

1. From the home page, select Settings in the left navigation menu.

2. Select the ADM Settings tab.

3. Select LLM Settings.

4. Open the LLM Providers panel and start a New Provider configuration.

The AI Model page displays the available models, including models associated with configured custom providers.

Enter provider details

Select a Provider Type, then enter the provider details.

The available provider types are AWS Bedrock, Azure OpenAI, OpenAI, Anthropic, and LLM Gateway.

Do not enter passwords, API keys, or other secrets in Provider Name, Description, or model display names.

Configure provider credentials

AWS Bedrock

Select AWS Bedrock to configure access to models through Amazon Bedrock.

Under Credentials, select a Bedrock authentication method.

Direct AWS IAM

Select Direct AWS IAM and complete the following fields.

AWS temporary credentials consist of an access key ID, a secret access key, and a session token. The credentials expire, so ensure that the values supplied to ADM remain valid.

The AWS identity must have permission to invoke the configured models. Depending on the API operations used, this includes bedrock:InvokeModel and, for streaming inference, bedrock:InvokeModelWithResponseStream. Additional requirements can apply to the selected Bedrock inference configuration.

After configuring authentication, add the models that ADM will access through this provider.

Azure OpenAI

Select Azure OpenAI to connect to your organization’s Azure OpenAI resource.

Azure OpenAI API keys and resource endpoints are available from the resource’s Keys and Endpoint settings. Versioned Azure OpenAI APIs use an api-version parameter.

Model identifier: Azure OpenAI requests use the model’s deployment name. When adding an Azure model, enter the deployment name expected by your endpoint in Model ID. A deployment name can differ from the underlying model’s name.

OpenAI

Select OpenAI to configure a direct OpenAI API connection.

Obtain the key from your organization’s OpenAI API account. Keep it confidential and confirm that the associated project can access the intended models.

Under Models, enter the API model identifiers you intend to use.

Anthropic

Select Anthropic to configure a direct connection to the Claude API.

Obtain the key from the Anthropic Console. A direct Anthropic connection uses Anthropic credentials; accessing Claude through a cloud provider uses that provider’s authentication instead. For example, configure AWS Bedrock when using Claude through Bedrock.

Under Models, enter the Claude API model identifiers available to the account.

Configure an LLM Gateway

What is an LLM gateway?

An LLM gateway sits between an application and its model services. ADM sends requests to the gateway, which routes them to the model configured behind that endpoint.

Depending on its implementation, a gateway can centralize authentication, access policies, request routing, usage monitoring, and quotas. These capabilities are configured in the gateway; creating a connection in ADM does not itself enable them.

OpenAI-compatible describes the interface exposed by the gateway, not necessarily the company that hosts the underlying model. A gateway can expose multiple providers through an OpenAI-compatible interface.

Gateway compatibility requirements

For the LLM Gateway provider, ADM calls the Chat Completions API, not the Responses API. Requests use the following path:

Set Gateway endpoint to the gateway's API base URL, including any required base path. ADM appends /chat/completions; do not include that operation path in the field.

The gateway and selected model must support the following capabilities for full ADM functionality.

A successful basic text-generation request alone does not establish compatibility. After selecting the configured model on the AI Model page, validate the ADM workflows you intend to run.

Choose an authentication method

Select LLM Gateway, then choose an Authentication method.

OAuth client credentials is an application-to-application authentication flow. It authenticates the application rather than requiring an individual user to sign in for each request.

OAuth client credentials

Complete the following fields when OAuth client credentials is selected.

Microsoft Entra ID scope

For the Microsoft Entra ID v2 client-credentials flow, Scope is required.

Use the target resource’s application ID URI followed by /.default. For a gateway registered with an api:// application ID URI, the value has this form:

The identifier must refer to the gateway API resource you are requesting access to. It is not necessarily the same as the client application’s Client ID. Other resource URI formats are possible, so use the value supplied by your administrator. A missing or incorrect scope can prevent token issuance.

Bearer token authentication

Select Bearer token (static) when your gateway administrator supplies an access token directly. Provide the gateway endpoint and the token in the fields displayed for this authentication method.

This method uses an existing token instead of obtaining one through a client ID and client secret. “Static” describes how the token is supplied; it does not mean the token is valid indefinitely. Arrange replacement according to your organization’s token-expiration and rotation requirements.

Additional headers

Use Additional headers when the gateway requires secret headers in addition to the selected authentication method.

Select Add header and enter the header name and value provided by your administrator. For example:

The configured headers are sent with gateway requests. Leave this section blank when no additional headers are required.

Treat header values as credentials. Do not enter these secrets in model request parameters.

Add models

Use the Models section to define the models available through the provider. Select Add Model to add another model entry.

The Model ID and Display name serve different purposes. Changing the display name does not change which model is invoked.

Use the identifier appropriate to the connection:

Model identifiers can differ across platforms, even for the same underlying model. Azure additionally distinguishes a deployment name from the underlying model name.

Gateway model request parameters

For an LLM Gateway model, Request parameters (JSON) lets you specify optional request-body parameters for that model.

The form specifies a default of:

Values you supply override the corresponding defaults. For example, when supported by your gateway and model:

Enter valid JSON and use only parameters accepted by the gateway and underlying model. Parameter support differs between models and API versions.

A maximum-token setting is a generation limit, not an estimate of actual usage. It does not mean every request consumes that many tokens, and it does not cap the combined usage of a workflow that makes multiple model requests. Reasoning models can also count non-visible generated tokens toward output limits.

Set the default provider, test, and save

Optionally, select Set as default provider to mark this provider as Default in the provider list and list it first. This does not select a model or change which model ADM uses.

Optionally, select Test Connection to check the configuration without leaving the form. Review the result and correct any reported configuration issues.

Select Create Provider to save the provider. Saving also runs a connection check in the background, whether or not you manually selected Test Connection. Select Cancel to leave the form without creating the provider.

Select the model ADM uses

Creating a provider does not change the model ADM uses. ADM uses the model selected on the AI Model page. If the Acceldata-provided model is selected, ADM continues to use it until an administrator selects the new model.

Choose a provider and model

Provider selection and model selection are different

Choose the provider according to your organization’s approved infrastructure, authentication, network, regional, and commercial requirements.

Choose the model according to the quality, tool-calling capability, response time, and cost required by the workload. Cloud-hosted and direct-provider offerings can differ in feature availability and pricing.

There is no universal provider choice that guarantees the lowest token consumption.

Recommended selection approach

Start with a model that has been validated for your ADM release and intended workflows. Establish a quality baseline, then evaluate less expensive alternatives against the same tasks.

For quick summaries and reformatting, evaluate a faster, lower-cost model. For root-cause analysis and multi-step investigations, prioritize reasoning quality and reliable tool use. This distinction is consistent with Acceldata’s published ADM model-selection guidance.

Compare cost per successfully completed task, not only price per token. A lower token rate is useful only when the model meets the task’s accuracy and reliability requirements.

Model certification

Support for a provider type does not establish that every model available through that provider has been certified for ADM.

Before production use, confirm the validated combination of ADM release, provider, model identifier, and configuration with Acceldata. A successful connection test is not a substitute for workflow validation.

Examples for a model evaluation

The following are evaluation candidates and pricing references—not an Acceldata-certified model list.

Prices below are published standard direct-API rates checked on September 24, 2026, in USD per million tokens. The OpenAI values shown use short-context rates.

The model descriptions and rates above come from the providers’ documentation; the suggested evaluation roles are starting points, not ADM benchmark results.

Check API compatibility before proposing a model. For example, GPT-6 Sol and Luna support function calling through Chat Completions only when reasoning is disabled; reasoning-enabled tool workflows use the Responses API. This must match the ADM integration.

Actual charges can differ with hosting provider, processing tier, context length, caching, regional processing, and negotiated terms. Use the rates applicable to your connection rather than assuming direct-API prices apply everywhere.

Understand token consumption

What contributes to usage?

Token consumption is not limited to the text entered by the user or the final answer displayed in ADM.

Provider documentation explicitly accounts for tool definitions, tool-call content, and tool results in token usage. OpenAI also documents that reasoning tokens are billed as output tokens.

Running an ADM tool is not, by itself, a fixed LLM-token charge. The model-facing descriptions, arguments, results, and subsequent model calls are what contribute to LLM usage.

Are tokens fixed because ADM uses a defined set of tools?

No. ADM supplies the tools and workflow, but that does not make token consumption fixed.

Even with the same available tools, usage can differ because of the amount of context supplied, the number of model calls, the size of tool results, and the model’s generated output. Models can also use different tokenizers, so identical text does not necessarily produce identical token counts.

The distinction is:

Token consumption is how many tokens the workflow actually uses.
Token cost is what the provider charges for those tokens.

A lower-priced model can reduce cost, but it should be compared using actual task usage and completion quality—not an assumption that every model consumes the same number of tokens.

Estimate usage and cost

Establish a workload-based estimate

Use a pilot workload that represents the customer’s expected usage. For each task, record the provider and exact model, all model calls, input and output usage, task completion, and response time.

Measure complete tasks rather than only individual chat messages. A single user request can require several model calls in a tool-driven workflow.

A useful measurement report separates task types, such as asset discovery, data-quality investigation, and multi-step analysis. Report average usage and a higher-usage percentile, such as the 95th percentile, so the customer can see both typical and heavier executions.

Where available, token-counting APIs can help estimate input size before execution. They do not predict the full output or all future calls in an agent workflow; actual usage records remain necessary for a reliable task estimate.

Calculate token cost

For standard uncached text requests:

Sum usage across every model call involved in the task.

For cached requests, calculate the applicable cache categories at their respective rates. Include any gateway or other service charges separately. When reasoning tokens are already included in reported output tokens, do not add them again.

Worked example

The following values are hypothetical. They explain the calculation and are not measured ADM consumption estimates.

Assume a task makes three model calls:

At an assumed input rate of $2 per million tokens and output rate of $10 per million tokens:

One thousand tasks with exactly that usage would cost $59 in model-token charges, excluding other charges.

This is an arithmetic example, not a forecast. Replace the assumed usage and rates with measurements and pricing from the customer’s deployment.

Reduce cost without compromising task quality

Evaluate less expensive models against the same acceptance criteria. Keep requests focused on the relevant assets, time range, and output, and avoid requesting unnecessary detail.

Where supported by the integration, model, and provider, output limits and caching can also help control spending. Verify the effect using measured task cost rather than assuming a configuration change produces a particular saving.