Constructor ChatEndpoint

Namespace

MailFathom.AI.Chat

Assembly

MailFathom.AI.dll

ChatEndpoint(string, Uri?, string, ChatProviderApi)

Where a chat request is sent and what it is routed to.

public ChatEndpoint(string Alias, Uri? Address, string RoutedModelName, ChatProviderApi Api)

Parameters

Alias string

The deployment's own name for this endpoint, which is what a log, a metric, a resilience circuit, and a failure message call it.

Address Uri

The base address requests are sent to, or null for the provider's own default.

RoutedModelName string

What is sent as the model of a request, which for a cloud deployment is the deployment's name rather than the vendor's model identifier.

Api ChatProviderApi

Which of the provider's two request APIs a call is conducted through.

Remarks

The alias exists because the other two members are an address and a routing name, and an address may not be written down: it identifies a tenant and a resource, so a failure that named one would put it in every log line. The alias is a name the operator chose, which is exactly what ADR 0003 permits a message to carry. It is unique across every AI endpoint the deployment declares, embedding endpoints included, because a credential, a circuit, and a log line are all keyed by it.

There is no vendor and no model identity beside the routed name, and that is the difference from an embedding endpoint rather than an omission. A vector is stored and later compared against other vectors, so which model produced it has to be recorded and proved; an answer is produced, presented, and gone, so nothing downstream ever has to ask which model wrote it.

The API belongs here rather than beside the generation parameters because it is part of where a request goes: the two surfaces are two paths under one address, reached with one credential over one transport. A deployment that has to move to the other one is correcting how its endpoint is reached, not how its model is asked to answer.