sonic182

Llm_composer - Elixir library for building LLM-based applications

Hi everyone, at Doofinder we have been building llm_composer for some new apps, and we thought it could be useful to share it with the community.

llm_composer is an Elixir library that simplifies working with large language models (LLMs) like OpenAI’s GPT, OpenRouter, Ollama, AWS Bedrock, and Google (Gemini).

It provides a streamlined way to build and execute LLM-based applications or chatbots, with features such as:

Multi-provider support (OpenAI, OpenRouter, Ollama, Bedrock, Google Gemini/Vertex AI).
System prompts and message history management.
Streaming responses.
Function calls with auto-execution.
Structured outputs with JSON schema validation.
Built-in cost tracking (currently for OpenRouter).
Easy extensibility for custom use cases.

A key feature is the provider router that handles failover automatically.
It will use one provider until it fails, then fall back to the next provider in the list, applying an exponential backoff strategy. This makes it resilient in production environments where provider APIs can become temporarily unavailable.

Under the hood, llm_composer uses Tesla as the HTTP client.
For production setups, especially when using streaming, it is recommended to run it with Finch for optimal performance.

More info and docs:

HexDocs: LlmComposer — llm_composer v0.20.0
GitHub:

https://github.com/doofinder/llm_composer

9 comments

#http_client #library #llm

10 850 9

2026-06-30 09:02:36 UTC

First Post!

mercyf

This looks great

Post #1

Most Liked

sonic182

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

Post #7

Jskalc

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.

Post #3

sonic182

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.

Post #4

Last Post!

sonic182

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

Post #9