Fragaria: Chain-of-Thought Reasoning API
Fragaria is a powerful and flexible Chain of Thought (CoT) reasoning API that leverages various Language Model (LLM) providers and incorporates Reinforcement Learning (RL) techniques to solve complex problems and answer intricate questions. Named after the botanical genus of strawberries, Fragaria pays homage to the famous “How many ‘r’s in strawberry?” problem, symbolizing its ability to tackle both simple and complex queries with equal finesse.
Features
- Multi-Provider Support: Seamlessly switch between OpenAI, Groq, and Together.ai as LLM providers.
- Chain of Thought Reasoning: Employ sophisticated CoT techniques to break down and solve complex problems.
- Reinforcement Learning: Utilize RL algorithms to continuously improve problem-solving strategies and adapt to new challenges.
- Adaptive Learning: Enhance performance over time through a SQLite-based scoring system integrated with RL techniques.
- Configurable: Easy-to-update YAML configuration file for flexible setup of both LLM and RL parameters.
- OpenAPI Documentation: Comprehensive API documentation with Swagger UI and ReDoc.
- CORS Support: Built-in Cross-Origin Resource Sharing for easy integration with web applications.
Why a dedicated CoT layer instead of prompting each model directly
Chain-of-Thought prompting — asking a model to reason step by step before producing a final answer — works differently across providers: the prompt formats that elicit good reasoning from one model don’t necessarily transfer cleanly to another, and providers periodically change how their models respond to the same reasoning cues. Calling each provider’s API directly means every application that wants CoT-style reasoning has to maintain its own provider-specific prompting logic, and re-tune that logic whenever a provider updates a model. A dedicated API layer exists to absorb that variability once, in one place, rather than in every application that consumes it.
Why reinforcement learning on top of Chain-of-Thought
Chain-of-Thought by itself is a prompting pattern, not a learning mechanism — the model doesn’t get better at reasoning through repeated use unless something closes the loop between an answer’s correctness and the reasoning strategy that produced it. Fragaria’s RL layer is that closing step: a SQLite-based scoring system records how well a given reasoning approach performed, and that signal feeds back into how future queries are handled. Over many queries, this lets the system’s problem-solving strategy adapt to the kinds of questions it’s actually being asked, rather than relying on a single static prompting strategy applied uniformly regardless of query difficulty.
The provider-switching design decision
Building multi-provider support in from the start — rather than hard-coding against one API — is a deliberate hedge against two realities of working with hosted LLMs: providers differ in cost, latency, and capability for any given task, and no single provider is reliably best across every workload. A YAML-configurable setup means the choice of provider (and the RL parameters governing how aggressively the system adapts) is an operational decision made at deploy time, not a decision baked into application code — which matters in practice because the cheapest provider for a simple factual query is often not the best provider for a query that needs several reasoning steps chained together correctly.
Why the API surface matters as much as the reasoning engine underneath
A reasoning engine that works well but is awkward to integrate gets adopted slowly, if at all — which is why Fragaria ships OpenAPI documentation with both Swagger UI and ReDoc, and built-in CORS support, alongside the CoT and RL machinery. Those pieces don’t make the reasoning any better, but they determine how much friction a developer faces going from “this API exists” to “this API is called from my application,” and that friction is often the actual bottleneck standing between a useful reasoning API and one that never gets integrated anywhere.