Skip to main content
Version: v1.1.x

Manage a Client's Model Access

This guide explains how a platform administrator controls which models a client uses on a PaletteAI Inference Launchpad appliance. Model access depends on whether a model runs locally on the appliance or is reached through an external provider.

  • Local models. Every client with a valid API token can call every model served locally on the appliance. You do not grant access to local models. To choose which local model handles a client's requests, route the client with a tier map.
  • External models. A new client cannot reach external models until you enable egress for it. External access is denied by default and is granted per client. External models include built-in frontier providers and hosts you register as external inference endpoints. Refer to Register an External Inference Endpoint.

To understand how clients and models relate, refer to Clients and Quotas.

Prerequisites​

  • A running PaletteAI Inference Launchpad appliance, with the console reachable.
  • An existing client. To create one, refer to Create a Client.
  • Console access with permission to manage clients. Managing clients can require operator access.
  • (External models only) For a built-in frontier provider, a provider key. For a registered endpoint, the endpoint already registered. Refer to Register an External Inference Endpoint.

Route a Client to Specific Models​

Use a client's tier map to route the client's model aliases to the models you choose.

  1. From the left main menu, select Access & Policy.

  2. On the Clients & API tokens page, select the client to open its detail panel.

  3. Select the Routing section.

  4. In the Tier map, select Add alias rule, or edit an existing row.

  5. Set the Alias prefix, such as claude-opus-, and the Model it routes to. Local models, frontier targets, and models from a registered external inference endpoint appear in the picker. Endpoint models are listed as <id> / <model>. The Tier map starts with seven seeded alias prefixes, claude-fable-, claude-opus-, claude-sonnet-, claude-haiku-, gpt-, gemini-, and grok-, which you can map but not remove.

  6. Save the client.

The tier map applies to the selected client. Requests from other clients follow their own tier maps, so they are not routed to that model unless you configure their tier maps as well. For requests the tier map does not settle, such as a request that sends auto, refer to Configure Semantic Routing. For how the two controls combine, refer to Routing Behavior.

Allow a Client to Reach External Models​

Enable egress, then add each provider or registered endpoint the client may use.

  1. From the left main menu, select Access & Policy.

  2. On the Clients & API tokens page, select the client to open its detail panel.

  3. Select the Egress section.

  4. Select Enable egress.

  5. Select Add provider key.

  6. In Provider, select a built-in frontier provider or a registered endpoint id.

    • For a frontier provider, enter the provider key.
    • For a registered endpoint, the Key field is hidden. The credential was set when you registered the endpoint, and the table shows box-managed. To register an endpoint first, refer to Register an External Inference Endpoint.

  7. Set a positive Daily limit, and then select Save. Egress is fail-closed on the cap, so a limit of $0 blocks that provider or endpoint for the client, and the table shows $0 blocked.

Frontier-model bursting is configured separately and is out of scope for this guide.

For the common shape (an enterprise Anthropic subscription, mostly local traffic, occasional flagship), use the following opinionated defaults after completing the steps in Allow a Client to Reach External Models. For the mental model behind each choice, refer to Frontier Providers.

  1. Store the same enterprise Anthropic key on every client that should have frontier access (Pattern A: one contract, one key pasted per client).
  2. Set the tier map so claude-opus-* routes to Anthropic and claude-sonnet-* and claude-haiku-* route to a local model. This captures most of the intended traffic mix because Claude Code defaults to Sonnet for cheap-tier turns and reserves Opus for hard work.
  3. Set the Daily limit to the monthly cap you agreed with finance, divided by the days in the billing period.
  4. Configure on_exceed=local so the client falls back to a local model when the budget runs out, instead of returning HTTP 429.
  5. Leave Enable egress on for these clients and off for every client that does not need frontier access.
  6. Skip bursting for now. Enable it later only if local capacity becomes the recurring bottleneck.

To verify the setup, send a request that resolves to the flagship tier through this client and check the response headers for X-AIBox-Frontier: anthropic on a successful frontier turn, or X-AIBox-Frontier: budget-exhausted after the budget runs out. If neither header appears, the client is bypassing the appliance. Refer to Common Misconfigurations.

Next Steps​