Twigg icon

Twigg

Twigg is a stateful HTTP API for storing LLM conversations, assembling model context, and routing requests across providers for persistent chat and tool-using apps.

Twigg

Stateful LLM API for stored conversations

Twigg is a stateful HTTP API for applications that use large language models. It combines hosted conversation storage, context assembly, and model routing: an application creates a chat, sends the next prompt or event, and receives a streamed response without resending the full transcript.

The chat is not tied to one model. Twigg prepares the stored context for the model selected on each turn and routes the request to supported provider networks. The application still owns the agent loop and tool execution, while Twigg provides the conversation ledger, provider translation, streaming response, and request cost information.

Features

Stateful conversation storage

Create a chat once and address later turns by its chat ID. Twigg stores the conversation ledger, so requests contain the latest event instead of a client-maintained transcript.

Context assembly and controls

Twigg assembles the stored conversation to fit the context window of the selected model. Its documentation also references configurable prompts, saved tools, context budgets, and retention settings.

Per-turn model routing

Choose a model for each response request rather than binding the conversation to one model. The service translates the assembled context for the selected provider.

Streaming responses and run data

Responses are delivered as a `text/event-stream` with run identifiers, content deltas, warnings, tool-call status, usage, cost, and terminal status. There is no documented non-streaming response mode.

Application-controlled tool loop

Applications can submit prompt events and tool-result events through the same responses endpoint. Twigg reports pending tool calls, but the application remains responsible for executing the tools.

Cost reporting and run recovery

Twigg exposes a model catalogue and records what each request cost. Idempotency keys, persisted history, and run inspection support recovery when a connection drops or a provider fails.

Use cases

  • Persistent conversational applications

    Build chat or support workflows that persist a conversation by ID. The application sends each new user event while Twigg retains the prior ledger and assembles the context for the next response.

  • Model comparison and provider flexibility

    Use a single conversation interface while selecting different models for different turns, such as changing the requested model as requirements or provider availability change. Model names should be taken from Twigg's live catalogue.

  • Tool-using agents

    Implement an agent whose tools run in your own application. Twigg streams tool calls and accepts the resulting tool output, while your code retains control over execution and the surrounding loop.

  • Direct API integrations

    Connect an existing HTTP client to a stateful model backend without adding a product SDK. The integration can use bearer authentication and a server-sent event reader to process incremental output.

Pros and Cons

Pros

  • Conversation history is stored outside the underlying LLM providers, reducing the need for the application to resend transcripts on every turn.
  • Models can be selected per request, allowing a conversation to move between catalogue models and provider networks.
  • Context assembly is handled for the selected model's context window, with documented controls for prompts, tools, budgets, and retention.
  • The streamed `done` data includes usage and cost fields, while run and history endpoints support inspecting persisted results after interruptions.

Cons

  • The API is streaming-only in the documented workflow; clients need HTTP and server-sent event support.
  • There is no SDK, so integration is built directly against the HTTP API.
  • Your application must execute tools and manage the agent loop; Twigg reports and accepts tool calls but does not run them.

FAQ

What is Twigg?

Twigg is a hosted context store, context assembler, and model router exposed through an HTTP API. Your application creates a chat, submits new events, and receives streamed responses while Twigg stores and prepares the conversation context.

How does a typical Twigg integration work?

Create a chat with `POST /api/v1/chats`, keep its returned ID, then submit prompts to `/responses`. Each request includes the model and only the new input; Twigg retains the conversation history. Responses use server-sent events, so the client must support streaming.

Can a conversation switch models?

Yes. The model is selected per request rather than fixed on the chat. Twigg says it can route requests to Anthropic, OpenAI, Google, xAI, Fireworks, or OpenRouter; request model names should be selected from the live catalogue.

Does Twigg run tools or manage the agent loop?

No. Twigg does not execute tools. Your application runs the agent loop and tools, submits tool results to the same responses endpoint, and continues reading the stream. It also records request cost and usage in the completion data.

Quick Facts

Category
Developer Tool
Product type
Stateful LLM API
API base URL
https://api.twigg.ai
Authentication
Bearer API key
Response format
Server-sent events (`text/event-stream`)
Provider routing
Anthropic, OpenAI, Google, xAI, Fireworks, and OpenRouter