> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gitar.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Bring Your Own Model

> Serve Gitar's LLM calls from your own account, through Anthropic, AWS Bedrock, or your gateway

export const ThemeImage = ({src, alt, width}) => {
  let lightSrc, darkSrc;
  if (src.includes("-light.")) {
    lightSrc = src;
    darkSrc = src.replace("-light.", "-dark.");
  } else if (src.includes("-dark.")) {
    darkSrc = src;
    lightSrc = src.replace("-dark.", "-light.");
  } else {
    lightSrc = src;
    darkSrc = src;
  }
  const style = width ? {
    maxWidth: width,
    marginInline: "auto"
  } : undefined;
  return <span>
      <img className="block dark:hidden rounded-lg border" src={lightSrc} alt={alt} style={style} />
      <img className="hidden dark:block rounded-lg border" src={darkSrc} alt={alt} style={style} />
    </span>;
};

Gitar can run every LLM call for your organization on your account instead of Gitar's. Your provider agreement, your data boundary, your bill.

Gitar still chooses the model for each task. You choose the account those calls are served from, and where they run.

## Before you begin

* Bring Your Own Model must be enabled for your organization. [Contact support](mailto:support@gitar.ai?subject=Bring%20Your%20Own%20Model) if you do not see the card.
* You need the organization admin role.
* Open **Settings -> Configuration -> Bring Your Own Model**.

## Choose a provider

Pick one option from the provider list. One option serves traffic at a time.

| Option | What you supply |
| - | - |
| **Anthropic** | An API key |
| **AWS Bedrock** | A residency geography and an IAM role |
| **LiteLLM** | Your gateway URL and an API key |
| **Portkey** | A provider slug and an API key |
| **OpenRouter** | An API key |

## Set up Anthropic

Paste an API key. Gitar stores it encrypted and calls `api.anthropic.com` with it.

<ThemeImage src="/assets/images/byom-anthropic-light.png" alt="The Anthropic option with its API key field" />

The key needs access to Opus, Sonnet, and Haiku. Verification tells you if a workspace restriction is in the way.

## Set up AWS Bedrock

Gitar assumes a role in your account per request through AWS STS, so no standing credential of yours is stored with Gitar.

<ThemeImage src="/assets/images/byom-bedrock-light.png" alt="The AWS Bedrock option showing residency geography, role ARN, the global inference toggle, and the optional guardrail fields" />

<Steps>
  <Step title="Pick your residency geography">
    Gitar routes to a geographic inference profile, so requests stay inside that geography's regions on the AWS backbone.

    | Geography | Regions AWS may route within |
    | - | - |
    | United States | us-east-1, us-east-2, us-west-2 |
    | European Union | 6 EU regions, entering at eu-central-1 |
    | Australia | ap-southeast-2 (Sydney), ap-southeast-4 (Melbourne) |
    | Japan | ap-northeast-1 (Tokyo), ap-northeast-3 (Osaka) |

    Your service control policies have to allow every region in the geography, because a request may land in any of them.
  </Step>

  <Step title="Create the role in AWS">
    Open **Create the role in AWS** in the card. It carries your external ID and the policies to copy, and it stays available afterwards for whenever you rebuild the role or audit who can assume it.

    Name the role with the `gitar-bedrock-` prefix. Gitar's permission to assume roles is scoped to that prefix, so a role named anything else cannot be assumed however its trust policy reads.

    The external ID is fixed for your organization and never changes. It is not a secret, but the role must require it. That condition is what stops anyone else who learns your role ARN from asking Gitar to assume it.
  </Step>

  <Step title="Enable the models in your AWS account">
    Submit the Anthropic use case details form, then have a principal with AWS Marketplace permissions invoke each model once from a region in the geography. That enables it account-wide.

    Listing models is not the same as being allowed to call them, which is what verification checks.
  </Step>

  <Step title="Paste the role ARN and verify">
    Paste the ARN into the card, then select **Verify connection**.
  </Step>
</Steps>

### Global cross-region inference

Off by default. Global inference routes worldwide, including outside your geography, so turn it on only if throughput matters more than residency. With it off, a model your geography cannot serve fails rather than leaving the geography.

### Apply your own guardrail

Optional. Name a guardrail from your Bedrock account and Gitar sends it on every inference call it makes with your credentials, so your own PII and content policy runs on Gitar's traffic.

Bedrock guardrails are per-request. A guardrail configured in your account has no effect on anything until it is named here, which is why this field exists rather than being picked up automatically.

Enter the guardrail's ID or its full ARN, then a published version number or `DRAFT`. Both fields are required together, since Bedrock rejects an identifier without a version.

The role needs `bedrock:ApplyGuardrail` on the guardrail on top of the base permissions. **Create the role in AWS** shows that statement once you enter an identifier.

Verification sends its test calls with the guardrail attached, so a mistyped ID or a missing grant fails there rather than on your first review.

<Warning>
  If you are using the guardrail to mask PII, set the input direction explicitly. Bedrock takes an action per direction, and a policy that sets only the default action leaves the input side untouched, so the model still receives the original text and only the response comes back masked. For masking before the model sees anything, set `inputAction` to `ANONYMIZE` and `inputEnabled` to `true` on each entity type.
</Warning>

<Note>
  A guardrail that masks code is a guardrail that changes what Gitar reviews. Placeholders like `{EMAIL}` replace the real text, so findings describe the masked version rather than your diff. Blocking is usually the better fit for source code, with masking reserved for the entity types you cannot let leave your account at all.
</Note>

## Set up a gateway

LiteLLM, Portkey, and OpenRouter are configured the same way: the endpoint, and a credential for it. Gitar speaks the Anthropic Messages format to all three. You host the endpoint for LiteLLM, and Portkey and OpenRouter host theirs.

### LiteLLM

In **Gateway URL**, enter the `https://` origin your proxy serves on, with no path. In **LiteLLM API key**, enter a virtual key.

<ThemeImage src="/assets/images/byom-litellm-light.png" alt="The LiteLLM option showing the gateway URL and API key fields" />

Gitar calls LiteLLM's [`/v1/messages` API](https://docs.litellm.ai/docs/anthropic_unified) using the Anthropic Messages format. LiteLLM looks up each requested `model_name` and routes it to the configured backend, including Anthropic, Bedrock, or Vertex.

The virtual key authenticates Gitar to LiteLLM. Keep backend credentials in LiteLLM and grant the virtual key access to the models shown by **Verify connection**. A Bedrock or Vertex deployment does not need a separate Anthropic API key.

| LiteLLM route | Model routing |
| - | - |
| `/v1/messages` | Gitar uses this route to invoke the gateway's configured `model_name` entries and their backends. |
| `/anthropic/v1/messages` | [Anthropic passthrough](https://docs.litellm.ai/docs/pass_through/anthropic_completion), with separate upstream Anthropic credentials. Gitar's LiteLLM option does not use this route. |

#### Troubleshoot refused requests

If every model shows **Refused**, check authentication before changing model names. A `401` with `API key is invalid` can come from the gateway or its upstream provider. The gateway logs identify which credential was rejected.

Test a small request to `/v1/messages` with the same virtual key. LiteLLM supports both `x-api-key: <virtual-key>` and `Authorization: Bearer <virtual-key>`. Gitar sends `x-api-key`.

If gateway logs show Gitar calling `/anthropic/v1/messages`, [contact support](mailto:support@gitar.ai?subject=LiteLLM%20Messages%20route). Older Gitar deployments selected that passthrough route. Changing a model alias does not fix a route authentication failure.

#### Gateways with model aliases

LiteLLM's `model_name` values are chosen by the gateway administrator. They are not a universal LiteLLM model catalog. Query `/v1/models` with the Gitar virtual key to find the names available to that key, then verify that those names can be invoked.

Gitar's Anthropic and LiteLLM options request `claude-haiku-4-5`, Anthropic's short alias for Haiku 4.5. The alias follows the most recent snapshot of that minor version. See Anthropic's [model IDs and versioning](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions#before-the-4-6-generation).

For a model-name mismatch on `/v1/messages`, add a `model_list` entry with the exact name shown by **Verify connection**. Copy the existing deployment's `litellm_params` and change only `model_name`. Keep the original entry for other clients and grant the Gitar virtual key access to the added name.

For example, a deployment exposed only as `claude-haiku-4-5-20251001` can also be exposed as `claude-haiku-4-5`. Both entries must route to the intended Haiku model. These customer-configured aliases apply to native model routing, not Anthropic passthrough.

After the model names are configured, verify the connection and run a review to check streaming and tool calls. Include the LiteLLM version and upstream provider when contacting support.

#### Network access

Your proxy has to be reachable from the public internet. Gitar refuses a bare IP address, `localhost`, and any `.internal`, `.local`, or `.svc.cluster.local` host when you save, and refuses a hostname that resolves into private address space when it connects.

If your proxy enforces an IP allowlist, permit Gitar's public IP addresses. See [Network Access](/connecting-code/network-access).

### Portkey

Enter the provider slug you want the traffic routed through, then your Portkey API key. The slug is the name you gave the Anthropic integration in your Portkey workspace.

<ThemeImage src="/assets/images/byom-portkey-light.png" alt="The Portkey option showing the provider slug and API key fields" />

<Note>
  A slug routes to whichever provider you wired up behind it, so the models Gitar needs have to be reachable through that provider. Verification calls each one and names any that are not.
</Note>

### OpenRouter

Enter an API key.

<ThemeImage src="/assets/images/byom-openrouter-light.png" alt="The OpenRouter option with its API key field" />

OpenRouter is a broker rather than a boundary. If you are here for a data-residency requirement, Bedrock is the option that enforces one.

### Another gateway

For a gateway that is not listed, [contact support](mailto:support@gitar.ai?subject=BYO%20LLM%20gateway).

## Verify the connection

Every option is verified the same way, and saving stays disabled until verification passes. Gitar sends one small request per model it needs, from your account, and reports what came back for each.

| Row says | What it means |
| - | - |
| **Answered** | The model exists and this credential may call it |
| **Refused** | The endpoint denied the call. The credential may be invalid, upstream authentication may have failed, or model access may be restricted |
| **Not offered** | The endpoint does not carry this model: a geography without it, or a gateway routing to a catalog that lacks it |
| **No answer** | Throttled, or a transient fault. Nothing to change. Verify again |

## Monitor a live configuration

Gitar shows a card on your dashboard when inference detects a credential, billing, or configuration problem. Bedrock configurations also receive background connection checks. Reviews are held rather than quietly routed back through Gitar's account, so nothing leaves your boundary without you choosing it.

| Card | What to do |
| - | - |
| **API Key Invalid** | Your key was rejected. Re-enter it and verify again |
| **Permission Denied** | Your credential was refused. For Bedrock, check that the trust policy still names Gitar's principal and that model access is on |
| **Configuration Cannot Serve Traffic** | Your geography carries no model Gitar can use. Pick another geography, or allow global inference |
| **Spend Limit Reached** or **Billing Issue** | Raise the limit or settle the balance with your provider, then select **Retry** |

Held work resumes on its own once the configuration serves again.

## What Gitar stores

An Anthropic or gateway credential is held encrypted in Gitar's secret store, and the configuration keeps only a reference to it.

A Bedrock configuration stores no credential at all. The role ARN, geography, and external ID are all non-secret, and the credential is minted per request by STS.

**Clear** removes the configuration and every credential stored with it, and returns your organization to Gitar's own account.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.