Models and providers

Model bindings

A node never names an endpoint, a model or a credential directly. It names a model binding:

# nodes/summarize.node.ael
node summarize(input: Request) -> Summary {
    config {
        prompt: file("prompts/summarize.md");
        model: binding("primary_model");
    }
    return write_summary(input);
}

Configuration or the deployment says what primary_model means:

• the kind of API and the endpoint's address;
• the model;
• a reference to the credentials, never the credentials themselves;
• default parameters, the parameters a call may set, and a timeout.

Each ordinary setting of a binding follows the configuration layers, taken from the first of these that sets it: an authorized override for one run, the deployment's binding, a named environment variable or file, a shared configuration, then the default you declare. Credentials stay references: your source names a reference, AEL never writes the credential into compiled files or logs, and it never takes it as a command-line argument.

ael config explain shows where each value comes from. A missing binding, an invalid endpoint or missing credentials fail the run with a model configuration error before any model call.

A model binding is not one of the entries of a component's bindings { … } record, which name the packages that hold its memory, skills, knowledge, storage and databases; Bindings and model bindings tells the two apart.

Local and cloud models

A program that calls a model only uses an outbound connection: it needs no server of its own. Connections need authenticated TLS, except to a local model server you explicitly allow.

What an endpoint can do

Endpoints differ, even when they accept the same kind of API. A binding records what its endpoint and model can do: which kinds of input and output they take, whether they return structured output, call tools or stream, and which parameters they accept. AEL checks each call against that record:

• A parameter the endpoint does not accept is an error, never silently dropped.
• A kind of input the model cannot take, such as audio, is an error before the call.
• An address that claims compatibility is not taken as proof of every feature.

Explicit or default parameters

• Explicit: each call sets parameters from the list the binding allows.
• Default: calls set none, and the deployment's or provider's defaults apply.

Either way, your output limits and budget still apply. Leaving parameters out never removes a limit, and a default that the provider does not report is recorded as unknown rather than guessed.

Realtime sessions

A realtime session is a longer exchange of events with a model, such as a spoken conversation. It has its own limits on duration, event size, buffered data and tokens, and you can interrupt or cancel it. The session's lifetime and each operation's budget are separate: a long session never extends the budget of the work inside it.

Model policies

A model-driven node chooses how it uses models:

• Every call of every policy draws on the run's one budget: router calls, fallbacks, parallel branches, repairs and verifier calls alike.
• A verifier gives an opinion, not proof. Type checks and permission checks still apply whatever it says.

Failures and usage

• A refusal, an incomplete answer, a provider error and a cancellation are each a distinct outcome.
• An incomplete or cut-off answer never becomes a typed success.
• Input and output tokens are counted for every call, including retries, and matched with what the provider reports. Usage a provider does not report is marked unknown, never counted as zero. See Reporting, logs and replay.

Testing without a live model

Your tests and evaluations can use scripted or recorded model responses instead of a live endpoint, so they run without credentials or network access. See Evaluations and prompt releases.