Models and providers

Model bindings

A node will never name an endpoint, a model or a credential directly. It will name 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 will say 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 will follow 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 will stay references: your source will name a reference, AEL will never write the credential into compiled files or logs, and it will never take it as a command-line argument.

ael config explain will show where each value comes from (command names may change before launch). A missing binding, an invalid endpoint or missing credentials will fail the run with a model configuration error before any model call.

Local and cloud models

A program that calls a model will only use an outbound connection: it will need no server of its own. Connections will 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 will record 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 will check each call against that record:

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

Explicit or default parameters

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

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

Realtime sessions

A realtime session will be a longer exchange of events with a model, such as a spoken conversation. It will have its own limits on duration, event size, buffered data and tokens, and it will be possible to interrupt or cancel it. The session's lifetime and each operation's budget will be separate: a long session will never extend the budget of the work inside it.

Model policies

A model-driven node will choose how it uses models:

• Every call of every policy will draw on the run's one budget: router calls, fallbacks, parallel branches, repairs and verifier calls alike.
• A verifier will give an opinion, not proof. Type checks and permission checks will still apply whatever it says.
• How a node declares its policy will be confirmed when the syntax is final.

Failures and usage

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

Testing without a live model

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