This looks great

Thanks!

We’ve also improved the README with clearer examples for different use cases:

• Streaming responses
• Using the “Simple” router with fallback + retries
• Tesla setup and configuration

So it should be much easier to get started now.
Feel free to check it out and let us know if you have any feedback!

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.

LlmComposer v0.12.0 released

This version removes deprecated configuration options and adds built-in cost tracking for multiple providers.

Removed (breaking changes)

• Removed deprecated :provider and :provider_opts keys. Use the :providers list instead.
• Removed global :api_key in Settings. Each provider should define its own key.
• Dropped backward compatibility handling for these deprecated options.

Added

• Automatic cost tracking for OpenAI, Google, and OpenRouter:
  • Fetches real-time pricing from provider APIs (models.dev and OpenRouter).
  • Adds a CostInfo struct in responses with token usage and cost breakdowns.
  • Supports both automatic and manual pricing configuration.

Changelog: https://github.com/doofinder/llm_composer/blob/master/CHANGELOG.md
Docs: https://hexdocs.pm/llm_composer/readme.html

llm_composer v0.12.2 Released

November 6, 2025

This update focuses on a key licensing change for the project.

License change

From v0.12.2, llm_composer is now released under the MIT license, replacing the previous GPL-3.0.

Why

The project originally used GPL-3 without fully considering its implications.
After using depscheck to our dependency review process (internal stuffs), we realized that GPL-3 could limit adoption in some environments or organizations.

To avoid any restrictions and ensure the library remains freely usable in all kinds of projects—open-source or commercial—we’ve switched to the more permissive MIT license.

Other updates

• Minor documentation and metadata changes reflecting the new license.
• No functional or API modifications; upgrading from any 0.12.x version is seamless.

Upgrade

{:llm_composer, "~> 0.12.2"}

mix deps.update llm_composer

Repository: https://github.com/doofinder/llm_composer

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

LLM Composer update — v0.16.1 → v0.19.1

Hey everyone! A lot has landed since the last update (v0.16.0). Here’s a recap of the highlights.

The biggest news: Amazon Bedrock now has full feature parity with the other providers — streaming, tool calls, structured output, and cost tracking all landed in v0.19.0. More on that below.

Reasoning model support (v0.16.1 → v0.17.1)

• Typed :reasoning_delta stream chunks across OpenAI, OpenAI Responses, and Ollama.
• New fields on %LlmResponse{}: reasoning_tokens, provider_model, cached_tokens, response_id.
• OpenRouter forwards reasoning context in multi-turn conversations.
• previous_response_id support for stateful OpenAI Responses conversations.

Cost tracking improvements (v0.17.0)

• chunk.cost_info populated on the final stream chunk — no post-processing needed.
• Cached token pricing: cached_tokens and cache_read_price_per_million added to %CostInfo{}, billed at the lower cache-read rate when available.

Cleaner function call API (v0.18.0)

• function_calls moved from %LlmResponse{} to %Message{} as a typed field, replacing the metadata[:tool_calls] indirection.

StreamChunk cleanup (v0.18.2)

• StreamChunk.tool_call renamed to tool_calls (typespec updated to match what parsers were already returning).

Amazon Bedrock — full feature parity (v0.19.0)

Bedrock went from completion-only to fully featured:

• Streaming via the ConverseStream API.
• Tool calls with full serialization and automatic merging of consecutive tool-result turns.
• Structured output via response_schema — mapped automatically to Bedrock’s outputConfig.
• Cost tracking — auto-populated in LlmResponse.cost_info when track_costs: true.
• Custom HTTP client using Mint (HTTP/1.1), with optional Finch support. Auto-injects itself as the ExAws HTTP client — no manual Hackney/Finch config needed.

Bedrock HTTP fix (v0.19.1)

• Forced HTTP/1.1 for non-streaming Bedrock requests to avoid Mint HTTP/2 flow control issues.

Full details in the CHANGELOG. Feedback welcome!

Hi all! Just released v0.20.0 — the headline is a new LlmComposer.Agent module.

LlmComposer.Agent — automatic tool-calling loop

Handles the full ask → execute → repeat cycle so you don’t have to manage it manually. Supports sequential and parallel tool execution, a configurable iteration limit, and per-tool error recovery.

LlmComposer.Agent.run(messages, tools: my_tools, provider: :open_ai)

Streaming agent (stream_response: true)

The agent now supports streaming, returning a lazy stream of StreamChunks:

• :text_delta — model text as it arrives
• :tool_call — emitted after each tool execution, result included (no extra telemetry handler needed)
• :done — terminal chunk with cumulative usage and the full Agent.Result

Works across all supported providers: :open_ai, :open_router, :open_ai_responses, :google, :bedrock, :ollama.

Telemetry improvements

Spans for run_completion and providers_runner, enriched agent events with per-tool arguments and reasoning deltas, plus a :telemetry_metadata option to scope handlers to a single run.

Full changelog: Comparing 0.19.6...0.20.0 · doofinder/llm_composer · GitHub