Skip to content
Compresr docs

LLM provider recipes

Pipe Compresr-compressed context into OpenAI, Anthropic, Gemini, or a local Ollama call.

Compresr doesn't call the provider for you. It returns a shorter string that you drop into the call you already make, in the slot the provider treats as reference material: system for OpenAI, Anthropic, and Ollama; system_instruction for Gemini. The user's actual question stays in the user-role slot.

Step 1: compress

Every recipe shares the same first step — build the client once (SDK overview) and compress the context against the user's question. The provider snippets below pick up from the variables defined here.

python

CompressResponse.data is Optional[CompressResult] in Python and nullable in TS; on error it is None/null. The recipes below read .data.compressed_context directly and assume the call succeeded. In production, wrap the compress call in try/except CompresrError (Py) or check if (!result.data) throw new Error(result.error ?? 'compress failed') (TS) before piping the string to the provider. See errors.

Step 2: call your provider

Compresr's token counts use tiktoken; every provider tokenizes differently, so the savings ratio carries over but the exact billed token numbers diverge. Pick your provider:

LLM provider

The OpenAI chat completions API treats the first {"role": "system", ...} message as instructions. Drop the compressed text there; keep the user's actual question in a user message.

python

OpenAI is the one provider where the counts nearly match: Compresr counts with tiktoken (cl100k_base for the GPT-4 family, o200k_base for GPT-5), so deltas from OpenAI's billing are usually within 1%.

Compress retrieved context, not instructions

Don't compress short, hand-written system prompts (instructions, output schemas, tool definitions) — Compresr is built for long, semi-redundant retrieved or accumulated context. Parameter semantics: Models. Failure handling for this two-call chain: Errors.