About Redeo

Your model knows more than it can surface in a single pass. Ask GPT a hard question and you get one answer — the first thing that came to mind. But the model has richer knowledge, better reasoning, and more nuance buried inside it. The problem isn't the model. The problem is that we ask models to answer in one shot.

Redeo is the programming layer for inference-time reasoning. It sits above the model and below the application — the place where reasoning strategies are written down declaratively, the way SQL writes down queries.

The Thesis

Inference-time structured deliberation — Chain-of-Thought, Tree-of-Thoughts, reflexion, self-consistency, debate, recursive refinement — is an axis of capability orthogonal to model scale and composing with scale rather than competing with it. A small model wrapped in the right search-and-verify program can match a frontier model on hard benchmarks at a fraction of the cost.

Internal evidence (pre-release): early internal runs show an 8-step search strategy ladder substantially improving GPT-4o-mini on hard reasoning benchmarks (Humanity's Last Exam, SimpleBench, AIME, GPQA Diamond) versus one-shot generation. These are directional, pre-launch numbers. A reproducible public benchmark harness is the next milestone — until it ships, treat headline figures as internal rather than independently verified.

The Problem with One-Shot Generation

When you send a prompt to an LLM, you get back whatever the model produces on its first pass. No exploration, no evaluation, no second guessing. Sometimes that's fine. But for hard questions — nuanced analysis, complex reasoning, creative tasks — one pass leaves better answers on the table.

Research has shown this repeatedly. Tree of Thoughts. Self-Consistency. Reflexion. Debate. Recursive refinement. These strategies all share the same insight: if you let a model explore multiple paths, evaluate what it finds, prune the bad ones, and iterate on the survivors, you get significantly better results than one-shot generation.

The problem isn't discovering new strategies — it's implementing them. Each one requires custom orchestration code, state management, error handling, and observability. Every team reinvents it. Most don't bother. So most LLM applications ship one-shot prompts and leave better answers on the table.

LangChain fumbled the glue layer. Model labs internalized search into the weights rather than exposing it. Nobody has built a declarative language + runtime for inference-time reasoning programs. The evidence says this layer should exist; Redeo fills it.

LADR — the Language

LADR (Language for Adaptive Deliberation and Reasoning) is a declarative DSL for describing search strategies. Instead of writing orchestration code, you write roughly 30 lines of YAML.

LADR is declarative and Turing-complete — structurally capable of unbounded loops, recursion, conditional branching, and runtime self-modification via dynamic steps. Turing-completeness is deliberate: real reasoning is unbounded, and forcing every ladder into a fixed hop ceiling fights the domain. What keeps LADR safe is not grammar restrictions but platform-enforced runtime ceilings: spend caps, hop ceilings, LLM-call ceilings, recursion-depth ceilings. Every execution hits hard resource caps.

This is the safety model in practice. A malicious or buggy published ladder can loop freely, but every LLM call costs money — the spend cap hard-kills the execution the moment it exceeds the budget. This is what makes untrusted published ladders safe to run, not grammar restrictions.

Every LADR config is validated before it runs — bad references, invalid field shapes, and constraint violations are caught before a single LLM call is made. The config is the single source of truth: it defines the strategy, the data flow, the controls, the safety envelope, and the output.

The grammar is closed and small: steps, fields, knobs, gates, jumps, slates, recursion, dynamic steps. Every primitive is first-class, runtime-bounded, and statically analyzable.

Ladders — the Programs

A ladder is a search strategy written in LADR — saved, versioned, and shareable. The canonical identifier is `@author/name`, rendered publicly at `library.redeo.io/@author/name`. The URL is the identifier — one thing, not two.

Every ladder exposes itself as an OpenAI-compatible API endpoint. Anything that talks to OpenAI can talk to a ladder — swap the base URL, pass an author/name path, and your existing application gets better answers. No code changes. The caller never needs to know what's happening behind the scenes.

Visibility tiers, in order of openness:

The platform manages versioning, authorship, routing, and (for paid ladders) billing. Username renames create permanent redirects — existing references keep working forever (GitHub model).

Foundry — Author

Foundry is where you build ladders. Use the visual step editor to add steps, define fields, configure knobs, set system prompts, wire up data flow, declare slates, and set execution budgets — or paste raw YAML directly and let Foundry parse and validate it.

When you run a ladder in Foundry, each step appears as a stage card showing the assembled prompt and the LLM's output. You can watch the search unfold in real-time, inspect intermediate outputs at every stage, drill into recursion depths, and debug issues without reading logs. Knob controls let you adjust parameters and re-run to see how the strategy responds.

Save your work as a ladder. Edit, re-run, iterate. Publish to the library when you're ready.

Studio — Run

Studio is where you use ladders. It's the consumer experience — first-class observability for running and monitoring search strategies. Send a message, watch the live timeline render each step as it executes, click any node to inspect its output, and see the final answer emerge from the search.

No config editing. No building. Just clean, real-time visibility into how a ladder processes your question. Studio makes search strategies accessible to anyone — you don't need to know LADR to benefit from a well-designed ladder.

Library — Discover

The Library at `library.redeo.io` is the public directory of published ladders. Every published ladder gets a public, crawlable page containing its full config. Measured benchmark outcomes, version history, fork lineage, and `Redeo Verified` badges are on the roadmap — the long-term plan is for ranking to weigh verified outcomes more than popularity, with the same dataset feeding the corpus thesis below.

The Corpus Thesis — the Long Game

If the public directory works and generates real usage data, that dataset is itself a research artifact no lab can produce. Product → usage data → corpus → research flywheel.

Every paid call is a structured measurement of "strategy X on task Y produced outcome Z." The "train future models on known-good strategies" thesis stops being a hypothesis the moment users generate it for you. It's a side-effect of shipping the marketplace well.

The Bigger Picture

Redeo makes search strategies into first-class objects. Write once in LADR, share as a ladder, call from anything. The model doesn't change. How you use it does.

This isn't about training bigger models or collecting more data. It's about how you let models use what they already know. A small model running a well-designed search strategy can surface answers that a large model misses in one shot. The intelligence was always there — it just needed better exploration to find it.

We believe reasoning improves through a simple loop: try, reflect, adjust. Redeo applies this loop at inference time, and makes it programmable.

Where to Go Next