docs
Features

Applications

How applications work in Optiak.

An application represents one AI-powered project, service, environment, or product surface. It is the unit that owns external API credentials and application-specific module settings.

Application Structure

Each application includes:

  • Overview - Usage, reliability, cost, budget, and model breakdown for that application.
  • Requests - A request-by-request trace view with status, selected model, provider, latency, tokens, cost, and timeline.
  • Modules - Application-level configuration for guardrails, data integrations, tools, models, Smart Router, inference defaults, and cost budget.
  • Credentials - Application API keys used by external services to call the public Gateway API.
  • Settings - Admin-only controls such as pausing or deleting the application.

Applications can be Active or Paused. Paused applications keep their configuration and credentials, but Gateway API requests for that application are rejected until the application is activated again.

Creating an Application

When creating an application, provide a name and optional description, then configure the same module areas available later in Modules:

  • Guardrails
  • Data Integrations
  • Tools
  • Models
  • Smart Router
  • Inference
  • Cost

These settings can be changed after creation. Admins can also edit the application name and slug from Settings. Slugs use lowercase letters, numbers, and single hyphens.

Module Settings

The Modules tab is where admins tune how requests behave.

Guardrails

Guardrails let an application apply safety policies to AI traffic.

Optiak supports:

  • Prompt Injection Detection - Identifies attempts to override system instructions.
  • PII Detection - Identifies personal and sensitive information so it can be handled according to policy.

Depending on configuration, detections can be audited, blocked, or redacted.

Read more in Guardrails.

Data Integrations

Vector Search augments prompts with relevant content from selected organization data sources.

The organization must enable vector search and make at least one data source available before an application can use it.

Application modes:

  • Per request - Vector search is available, but requests must opt in with vector_search_enabled.
  • Always on - Vector search is active for all requests to the application.
  • Disabled - Vector search cannot run for the application.

Applications can enable multiple data sources. A request only searches data sources enabled at both the organization and application levels.

Read more in Data Integrations.

Tools

Web Search augments prompts with current web results.

The organization must enable web search before an application can use it.

Application modes:

  • Per request - Web search is available, but requests must opt in with web_search_enabled.
  • Always on - Web search is active for all requests to the application.
  • Disabled - Web search cannot run for the application.

When web search is blocked by organization settings, the application cannot enable it.

Read more in Tools.

Models

Application models are selected from the organization-enabled catalog. If a model is not enabled in Company Setup -> Models, the application cannot use it.

Use this to keep different applications on different model sets. The public /models endpoint returns the final model list available to an application API key.

Read more in Models and Routing.

Smart Router

Smart Router lets requests use model: "smart" instead of naming a specific model.

When enabled, Optiak chooses from smart-routing-eligible models that are also enabled for the application. The available strategies are:

  • Balanced - Balance cost and quality.
  • Cost - Prefer lower cost per token.

If Smart Router is disabled, requests using smart are rejected. Use a specific public model ID instead.

If Smart Router is enabled but no smart-routing-eligible models are enabled for the application, requests cannot be routed until at least one eligible model is enabled.

Inference

Inference settings define application-level defaults for model requests.

You can configure:

  • System prompt - A default instruction applied by the application.
  • Application prompt behavior - How the application system prompt is combined with request-level instructions (system/developer messages or Responses instructions):
    • Append - Keep request-level instructions first and add the application system prompt after them.
    • Replace - Ignore request-level instructions and use only the application system prompt.
    • Prepend - Put the application system prompt before request-level instructions.
  • Max completion tokens - A default cap for generated response length.

Temperature is not an application-level default. Send it per request following the Chat Completions or Responses API semantics.

Cost

Cost budget lets admins set a monthly budget for an application and decide how Optiak should react when that budget is reached.

When a budget is set, Optiak can surface budget status in the application experience and apply the configured budget action, such as alerting the team or pausing the application when the monthly limit is reached.

Application Settings

Admins can use Settings to:

  • Edit the application name.
  • Edit the application slug.
  • Pause or activate the application.
  • Delete the application.

Deleting an application is permanent. Pausing is reversible and does not delete credentials, but traffic authenticated with that application's keys is rejected while it is paused.

Credentials

Application API keys authenticate external services against one application.

Keys can include a name, optional label, optional description, and optional expiration. The full key is displayed once at creation time. After that, the UI only shows the prefix.

Revoking a key immediately prevents new traffic authenticated with that key.

Provider keys are different. Provider keys are added in Company Setup -> Models and let Optiak call upstream model providers.

Copyright © 2026