AI

AI is a resource that gives your code model inference through the customer's own Amazon Bedrock, Vertex AI, or Azure AI Foundry, with no API key in your application. It fits when your product calls language models from inside a deployment and the customer wants inference on their account, under their quotas and data-handling terms.

import * as alien from "@alienplatform/core"

const llm = new alien.AI("llm").build()

const api = new alien.Worker("api")
  .code({ type: "source", src: "./api", toolchain: { type: "typescript" } })
  .link(llm)
  .permissions("execution")
  .build()

export default new alien.Stack("acme")
  .platforms(["aws", "gcp", "azure"])
  .add(llm, "frozen")
  .add(api, "live")
  .permissions({ profiles: { execution: { llm: ["ai/invoke"] } } })
  .build()

In this stack:

• .link(llm) connects the AI resource to the api Worker, the workload (the running code) that uses it. Alien injects the AI resource's connection details, its binding, into the Worker, read by the SDK client.
• The execution permission profile, the named set of cloud permissions a workload runs with, grants ai/invoke: calling models.
• "frozen" means the customer's admin creates the AI resource during initial setup. "live" resources, like the Worker, are created and updated by Alien on every release. See Frozen and live.

The api Worker calls a model with an OpenAI-style client:

import { ai } from "@alienplatform/sdk"

const completion = await ai("llm").chat.completions.create({
  model: "gpt-oss-120b",
  messages: [{ role: "user", content: "Summarize this order." }],
})

PlatformsCopy Anchor Link

llm becomes the AI service in the customer's cloud. Calls are billed to their cloud account and authorized by the workload's own identity.

Per-cloud details are in Behavior and limits. The model list for each cloud is in Models.

Bring your own modelsCopy Anchor Link

AI is the in-deployment way for a customer to bring their own models. Each customer's inference runs in their account, and you ship no keys. The full flow, including open-weight models on the customer's GPUs, is in Local AI models in a deployment.

If your product stays hosted in your cloud, use the AI Gateway instead. See Local AI models.

Model choiceCopy Anchor Link

The model menu belongs to the customer's cloud, not to you. What you can call depends on which cloud they run and which models they've enabled.

If your product needs one model everywhere, or a provider none of the clouds host, use an external binding with your own provider key instead.

Frozen or liveCopy Anchor Link

AI can be "frozen" or "live". See Frozen and live.

ai/invoke grants inference and nothing else: no model management and no deployment writes.

OptionsCopy Anchor Link

There is nothing else to configure. The model, temperature, and every other setting belong to the request.

Changing models doesn't need a release, and one stack works across clouds whose model menus differ.

Use it in codeCopy Anchor Link

import { ai } from "@alienplatform/sdk"

const llm = ai("llm")

const completion = await llm.chat.completions.create({
  model: "gpt-oss-120b",
  messages: [{ role: "user", content: "Summarize this order." }],
})
console.log(completion.choices[0]?.message.content)

On a cloud binding, the SDK starts a small gateway process beside your code on first use. It signs each request with the workload's cloud identity and forwards it to the provider. See the API reference.

Any client libraryCopy Anchor Link

getAiConnection() returns a base URL that works with any OpenAI- or Anthropic-compatible client, including the Vercel AI SDK, the OpenAI SDK, and the Anthropic SDK:

import Anthropic from "@anthropic-ai/sdk"
import { getAiConnection } from "@alienplatform/sdk"

const { baseURL, apiKey } = await getAiConnection("llm")
const anthropic = new Anthropic({ baseURL, apiKey: apiKey ?? "" })

const message = await anthropic.messages.create({
  model: "claude-sonnet-4.6",
  max_tokens: 1024,
  messages: [{ role: "user", content: "Summarize this order." }],
})

Pass apiKey: "" on a cloud binding. Most clients otherwise fall back to a key from your environment, such as your personal ANTHROPIC_API_KEY, instead of the workload's identity.

Pick a model at runtimeCopy Anchor Link

Model availability differs per cloud and per account. List the models for this deployment instead of hardcoding one:

const models = await ai("llm").getAvailableModels()
// [{ id: "byo/gpt-oss-20b", provider: "openai", displayName: "GPT-OSS 20B" }, …]

Pass an id back as model, with or without the byo/ prefix.

Common patternsCopy Anchor Link

A model picker. Feed getAvailableModels() to a dropdown and send the chosen id with each request. displayName is the human label.

One client for every model. Claude speaks Anthropic Messages, the GPT-5 family speaks OpenAI Responses, and the rest speak Chat Completions. Alien translates between them, so a Chat Completions client can call Claude.

Use the model's native protocol when you need provider-specific features such as extended thinking or prompt caching. See Protocols.

Bring your own key off-cloud. On Kubernetes, Machines, and Local, the same code calls your provider directly with your key. Your code doesn't change between environments.

Local developmentCopy Anchor Link

There is no cloud identity on your machine, so locally the resource uses your provider key:

OPENAI_API_KEY=sk-... alien dev

• alien dev fails with an actionable error if the key is missing.
• Cloud model ids don't apply locally. Pass any model id your key can reach.
• getAvailableModels() returns a short built-in list instead of querying the provider.
• To use another OpenAI-compatible server, including one on your machine, set ALIEN_AI_LOCAL_BASE_URL.

PermissionsCopy Anchor Link

NextCopy Anchor Link

• API reference
• Behavior and limits
• Models
• Pricing