Cosortium acts as a proxy for LLM calls. With 1 LOC change (API URL), make any LLM powered app - Smarter & Cheaper: via Ensemble topologies, like OpenRouter's Fusion. On some tasks you can get Fable performance for 1-6% the cost by fusing responses of mutli cheaper llms - Reliable: Durable DAG execution improves success rates of LLMs by an order of magnitude. Via result parsing, automatic retries - Optimizable: Built-in wiring for benchmarks, with autoresearch/GEPA/MIPROv2-style optimization
No reviews yetBe the first to leave a review for Consortium
Maker
📌
Cosortium acts as a proxy for LLM calls. With 1 line of code change (API URL), Consortium lets you make any LLM powered app
- Smarter & Cheaper: via Ensemble LLM topologies, similar to OpenRouter's Fusion API. On some tasks like deep-research, code review, and Legal you can get Fable-level performance for 1-6% the price by fusing the responses of multiple cheaper models
- Reliable: Durable DAG execution improves the success rates of long/complex workflows by an order of magnitude. With result parsing, automatic retries, retry policies.
- Auditable: Full audit trails of every request, response, attempt, prompt, etc.
- Optimizable: Built-in wiring for industry-standard and custom benchmarks, with autoresearch/GEPA/MIPROv2-style optimization techniques.
This is not a replacement for n8n or similar. Consortium focuses on Ensemble LLM topologies, changing the way your LLM does its reasoning and forms an answer to support multiple topologies that fit different use cases.
Some use cases may need LLM-as-Judge, some may need Adverserial debate, some may need simple fusion (informed capitan), and some may need self-consistency. With consortium, thats a 1 click change. Your application code remains unchanged.
Report
Honestly the ensemble cost angle is super compelling, would love to see you add some kind of latency budget per request though. Right now if one of the fused models drags, the whole call drags and downstream apps get stuck waiting. Even just a configurable timeout per branch with graceful fallback to the fastest response would be huge.
Report
Maker
@ufuk375410 You can easily configure timeout per workflow or per each node inside the workflow, and the retry-policy supports rich options of how to handle timeouts
Honestly the ensemble cost angle is super compelling, would love to see you add some kind of latency budget per request though. Right now if one of the fused models drags, the whole call drags and downstream apps get stuck waiting. Even just a configurable timeout per branch with graceful fallback to the fastest response would be huge.
@ufuk375410 You can easily configure timeout per workflow or per each node inside the workflow, and the retry-policy supports rich options of how to handle timeouts