llm_composer v0.16.0 released (Feb 23, 2026)

Quick update since the last post (v0.12.2 / MIT switch) — quite a bit has landed since then.

What’s new in 0.16.0

• New provider: LlmComposer.Providers.OpenAIResponses — calls OpenAI’s /responses API with support for structured outputs and reasoning (provider/model-specific params passed via request_params), normalized into the usual LlmResponse shape. Since it targets the /responses API spec, it also works with compatible providers like x.ai (xAI/Grok), OpenRouter’s responses endpoint, and others.
• Typed streaming chunks: new LlmComposer.StreamChunk struct + provider-specific parsing turns raw stream events into typed values (:text_delta, :tool_call_delta, :done, …).
• LlmComposer.FunctionCallExtractors: centralizes function call extraction logic per provider.
• Provider-aware parse_stream_response: now comes in /2 and /3 arities and returns %StreamChunk{} values instead of raw decoded maps.
• Internals refactored to protocol-based adapters (LlmComposer.ProviderResponse + LlmComposer.ProviderStreamChunk) for cleaner normalization across providers.

Notable releases since 0.12.2

• 0.13.0 (Dec 2025): function-call workflow is now manual/explicit via FunctionExecutor + FunctionCallHelpers — breaking change, see changelog.
• 0.13.1 (Jan 2026): custom HTTP headers support for OpenRouter.
• 0.14.0 (Feb 4): configurable retry/backoff for provider requests.
• 0.14.1 (Feb 9): deep merge fix for nested request_params (e.g. Google’s generationConfig).
• 0.14.2 (Feb 10): LlmResponse.new/3 now returns {:error, …} instead of raising on unknown provider formats.
• 0.15.0 (Feb 17): configurable :json_engine (defaults to JSON, falls back to Jason); Google provider now preserves additionalProperties in response schemas.

Upgrade

{:llm_composer, "~> 0.16.0"}

Full changelog: llm_composer/CHANGELOG.md at master · doofinder/llm_composer · GitHub

Thanks for your efforts!

Could you highlight the differences from ReqLLM, discussed in this topic? I believe both libraries aim to solve the same problem.

We started this lib about a year ago (we’d been using it internally even before that) and only now decided to share it here.

Both libraries aim at the same thing: wrapping LLM APIs behind a unified HTTP client.

The main differences are:

• HTTP layer: we use Tesla, ReqLLM builds on Req.

• Routing: llm_composer includes a router with fallback + retries.

• API style: each library exposes a slightly different way to configure and work with “bots” or requests, so it depends which style you prefer.