Core Concepts

Nodes

A node is the fundamental unit of Interlocute. It is a persistent, addressable AI endpoint with its own identity, configuration, memory partition, and usage tracking. You create a node, configure its model, system prompt, and policies — then call it via its stable subdomain: https://my-node.interlocute.ai.

Each node is independent. Different nodes can use different models, have different configurations, and maintain separate memory partitions. There is no limit on the number of nodes you can create.

Identity & addressability

Every node has a stable ID and a permanent endpoint URL. This address does not change when you update configuration, swap models, or rotate API keys. Integrations built against a node's address continue to work across all changes.

Threads & messages

A thread is a conversation between a caller and a node. Each thread maintains an ordered sequence of messages and tracks conversation state across turns. Threads are the unit of state management in Interlocute.

• Threads persist until explicitly closed or expired
• Each message in a thread is attributed to a sender (user or node)
• Thread IDs are stable — you can resume a conversation at any time
• Different threads on the same node are isolated from each other

Chat & chit

Interlocute distinguishes between chat (the interactive message exchange) and chit (the deterministic node information sheet for discovery and governance). Chat carries meaning for the user. Chit tells callers and agents what the node is, what it can do, and what to expect operationally — without relying on model inference.

For more detail, see Chat & Chit.

Policies, quotas, & refusals

Nodes operate within policies — rules that define what the node can do and how much it can spend.

• Quotas — token budgets that cap spending per day, month, or per API key
• Refusals — conditions under which the node declines a request (off-topic, policy violation)
• Access restrictions — API key scoping and domain allowlists

Policy enforcement is logged. Every refusal, quota hit, and access denial is recorded with the reason and the request that triggered it.

Observability & cost

Every node interaction is logged with full token accounting: input tokens, output tokens, computation tokens, latency, and the API key used. Costs are calculated per interaction and attributed to the specific node and key.

This is built in — there is nothing to configure and no third-party logging integration required.

Triggers

Nodes can be invoked on a schedule (cron-style) or in response to events, making them proactive rather than reactive. Triggered executions have access to the same capabilities as interactive calls — memory, tools, streaming.

See Triggers for details.

Request lifecycle

Every request to /chat flows through authentication and policy checks before reaching the node runtime. The runtime delegates to the underlying LLM. The response is delivered to the caller along with usage data (tokens consumed, latency). Meanwhile, the node's /chit endpoint remains available for callers to discover the node's identity and capabilities.

Next steps

• Quickstart — make your first API call
• Auth & Keys — set up your credentials