DEV Community: Sébastien Conejo

Free Models, Zero Compromise: Routing to Local and Free Tiers

Sébastien Conejo — Thu, 02 Jul 2026 08:34:45 +0000

Not every request needs a frontier model, and a surprising share of them can run for nothing at all. The problem is that "free" usually sounds like "worse," so teams pay for every request just to be safe. Routing is what removes that trade-off.

There are actually two separate pools of zero-cost inference, and they behave very differently. It's worth knowing both before you decide what to send where.

Pool one: local models

Run a model on your own hardware and the marginal cost of a request is zero. Manifest connects local servers the same way it connects anything else: Ollama, LM Studio, and llama.cpp, plus any other OpenAI-compatible server you point it at.

Three things make local special. It's free, in the sense that you pay for electricity, not per token. It's private, because the prompt never leaves your machine. And it has no rate limits, because you aren't sharing a quota with strangers. The catch is just as simple: you need the hardware, and a small local model is not Opus. Which is exactly why you don't send it the hard work.

Pool two: free API tiers

The second pool lives in the cloud. A lot of providers run a genuinely free tier, and Manifest keeps a curated list of them. At the last sync that was over a hundred free models across more than a dozen providers.

A few highlights, all free and most without a credit card: Groq serves Llama 3.3 70B and Llama 3.1 8B on ultra-fast hardware, Cerebras pushes around 2,600 tokens a second, and OpenRouter exposes more than 35 models with a :free suffix, including DeepSeek R1 and Qwen3 Coder. NVIDIA NIM opens 100+ models to anyone in its developer program, while Google's Gemini 2.5 Flash and Mistral's free Experiment plan round things out.

That catalog isn't static. It's an open-source list we maintain and sync once a day, so as free tiers appear and disappear the page keeps up. You can browse the whole thing at manifest.build/free-models.

So where is the compromise?

This is the honest part, because "zero compromise" is a claim worth earning.

The compromise people are afraid of is quality, and that is the one routing actually removes. You don't send a free or local model your hardest request and hope. You send it the work it handles just as well as anything else: summarizing a ticket, extracting a field, classifying a message, drafting a first pass. For those tasks, a fast 8B model and a frontier model produce the same answer, and only one of them shows up on the invoice.

Free tiers do come with strings, and we won't pretend they don't. They have rate limits, often a few dozen requests a minute and a few hundred a day. Some cap the context window on the free plan. And a few log or train on your free-tier traffic: Google notes that free Gemini prompts may be used to improve its products, and some trial keys aren't cleared for commercial work. Our list flags those warnings on each provider for exactly this reason.

That is the whole case for handling this with routing instead of by hand. Non-sensitive, simple work goes to a fast free tier. Anything private stays on a local model, where nothing leaves your machine. And real frontier models are kept for the requests that genuinely need them. Each request lands where it fits, so the limits of any one option stop being your problem.

How it works in Manifest

You don't wire your app to Ollama, or to Groq, or to any single provider. You point it at one endpoint, set the model to auto, and let Manifest score each request and route it. Assign a local or free model to your simple and standard tiers, or list them as fallbacks, and the easy traffic stops costing money without you touching the code again.

And it isn't a black box. Every response carries headers showing which model answered, which tier it landed in, which provider served it and why, so you can see exactly how much of your traffic ran for free.

The point of "zero compromise" was never that free models have no limits. It's that those limits stop mattering once each request goes to the thing that handles it best. Sometimes that is a frontier model. Far more often than most teams expect, it's something that costs nothing.

Manifest is open source, and the free-models catalog is live. Browse it and connect your first free provider at manifest.build/free-models.

The reliability stack for LLM agents: tools and methods

Sébastien Conejo — Thu, 02 Jul 2026 07:51:09 +0000

A request can fail at three moments: before you send it, while it runs, or after it returns. Different tools and habits cover different moments. This is a directory grouped by what each one does.

Methods you apply yourself

You apply these for free, and they rule out several common failures before you reach for a tool.

Pick the model that fits the request. A small fast model handles simple calls, and a larger one handles reasoning. One model for everything wastes budget on the easy calls and hits rate limits faster on the hard ones.
Check compatibility before you switch models. Two models are rarely interchangeable, even under the same API. They differ on accepted parameters, tool handling, and context size, so a quick check before a swap saves a broken deploy.
Pin explicit versions instead of moving aliases. An alias that repoints to the current model changes under you without warning, and a fixed version keeps your behavior stable.

Model references

You need model specs in one place to choose fast: context window, parameters, cost, capabilities.

modelparams.dev is a community catalog of model parameters. We maintain it so you can compare models at a glance instead of opening ten documentation tabs.

Structured outputs and validation

Constraining the shape of a request or a response rules out most format errors before they reach the provider.

Instructor returns validated, typed objects from an LLM using your schema, with automatic retries.
Outlines guarantees schema-compliant output during generation rather than parsing it afterward.
Pydantic defines and validates the data models the two tools above build on.

Repair and routing at runtime

A request that gets past prevention still breaks in production: a provider rate-limits you, a model got retired, a schema one provider accepts another rejects. Routing and repair keep the app up when that happens.

Manifest lets you set free models as primary and your own API-key models as fallback, so traffic switches over when the free ones hit their limit. We're also building Auto-fix, which catches a failing request, patches it, and sends the corrected version through. It's in early access right now.

Guardrails

Content checks catch safety or policy issues in a response.

Guardrails AI validates inputs and outputs against configurable rules like toxicity, PII, and format compliance.
NeMo Guardrails adds programmable rails for topics, safety, and dialogue flow.

Observability and traces

A trace records what happened on every request. You see what broke, and you fix it with the runtime tools above.

Langfuse traces every LLM call, tool invocation, and latency in a timeline, open source.
Arize Phoenix gives open-source tracing and evaluation with strong support for RAG and multi-step agents.
Datadog LLM Observability brings LLM traces, errors, and cost into the same platform as the rest of your infrastructure.

Evaluation and regression testing

Model and prompt changes drift in quality. A test suite surfaces the drop before it reaches production.

Promptfoo replays a set of test cases against your prompts and models from a config file, and wires into CI.
Braintrust scores prompt and model changes and can block a deploy when quality degrades.

How the pieces fit

Each category covers a different moment. Methods and catalogs help you choose before you send. Structured outputs constrain the shape. Routing and repair catch what still breaks in flight. Observability and evals tell you what to fix at the source. Coverage at each moment rarely comes from one product.

I stopped prompting my agent. Now I design the loop that prompts it.

Sébastien Conejo — Tue, 30 Jun 2026 16:04:33 +0000

We're moving past the era where working with an agent meant typing a prompt, waiting, reading the diff, typing again.

You are the loop in that setup. Your attention is the constraint, not the model. The agent sits idle until you show up.

I wanted out of that cycle. Not completely out, I'll get to that. But I wanted to stop being the operator and become the supervisor instead.

I run a personal AI agent on a VM. It triages my emails, monitors Reddit, handles parts of my calendar. It is built on Hermes, an open-source agent framework.

For months I still had to prompt it every morning. Tell it what to do, review, correct, tell it again. The model was good. I was the slow part.

So I built a loop. The architecture borrows from Karpathy's autoresearch: a propose-execute-evaluate-keep/discard cycle where the agent searches for improvements inside a fixed evaluation harness. The optimization loop itself fits in four files.

Four files on disk

No framework. No SDK. A Python script and four files.

contract.md defines what the agent can do. The boundaries. I wrote it once.
target/ holds the files the agent can edit. The only thing that changes between runs.
eval scores the output. Returns a number. This file is immutable, which matters more than it sounds: because the agent can't edit its own judge, it can't hack the score. The eval stays honest even when the agent gets creative.
state/ logs every experiment, every score, every keep or discard. Append-only.

The script itself is a while loop:

while budget > 0:
    planner reads contract + state → proposes a change
    generator modifies target/
    eval scores the result
    if better → keep
    if worse → revert
    log everything
    budget -= 1

The models do the thinking. The script is plumbing. It's also greedy hill-climbing, which means it can get stuck in local optima. For my use case that's fine. For yours it might not be.

One design decision that mattered
I learned this the hard way. My first version had one model classify my emails and rate its own confidence. Confidence was always "HIGH." The scores looked fine. The results were mediocre.

The problem: one model generating and evaluating produces correlated errors. It has the same blind spots on both sides. In practice it feels like two optimists agreeing with each other. The loop looks healthy while the quality drifts.

The fix for my setup was context separation. I split it into two calls where neither sees the other's reasoning. The generator never sees why the evaluator scored it low. The evaluator never sees the generator's chain of thought. They share the artifact and the score, nothing else. You can do this with the same model on two separate calls.

On top of that, I route them to different models through Manifest, our LLM router that lets you send specific requests to different models and patches failures on the fly instead of letting them drop. One HTTP header picks which neural network handles each role. This reduces correlated blind spots, since different training data produces different failure modes. But it's a reinforcement, not the core mechanism. Two different models can still share biases from similar RLHF pipelines. The context wall does the heavy lifting.

Disagreements between the two turned out to be my best quality signal.

Writing the eval is the actual skill

This is the part I underestimated and the part that matters most.

Most people stall here. "What do I measure?"

Take email triage as an example. Every mornin the agent classifies my inbox and marks noise as read. It reports what it did. I correct the mistakes: "that one was important," "that one is noise." Each correction becomes a test case.

The eval re-classifies past emails with the current rules and compares them against my corrections. Score = percentage match. The loop optimizes that number.

Every correction expands the definition of "good." More corrections, bigger test set, harder eval, tighter rules. After a few days I correct less often, partly because the rules got better, partly because I trust it more. Both are happening and I try not to confuse the two.

Writing the eval took me longer than writing the loop. The loop is a while with an if/else. The eval forces you to define what "good" means in a way a script can check.

My other mistake

No state file. The agent forgot everything between runs. Every morning it started fresh, re-learned the same patterns, made the same calls. Adding a TSV log and a rules file on disk turned a forgetful script into something that accumulates instead of resetting.

The agent forgets. The file doesn't.

When a loop is the wrong tool
Loops re-read context, retry, explore. They cost tokens on every run whether they ship anything or not. If your task doesn't repeat weekly, a good prompt is cheaper.

Before building one, check five things:

Does the task repeat? Can you score the output with a number? Can the agent run what it produces? Does the loop have a hard stop? Is the eval hard to game?

That last one is easy to miss. If your loop optimizes a score, the optimizer will find ways to inflate it that don't mean the output got better. My eval scores against past corrections, which means I can reach 100% on the history with rules that fail on new emails. The fix is the same as in ML: hold out recent data so the optimizer can't see all the answers.

Miss one of these and you have a manual prompt pretending to be automation.

What actually changed

I didn't remove myself from the loop. That would be a lie. I still correct a few emails in the morning, and those corrections are the ground truth that makes the eval work. Without me, the loop has nothing to optimize toward.

What changed is my role. I went from operator to supervisor. I used to sit in the loop at every turn, reviewing every output, prompting the next action. Now I define what good means, then step back. The loop runs on its own on Sunday, tries twenty variations of the rules, keeps whatever scores higher, discards the rest. Monday morning the triage is a little sharper than last week.

I still design the contract. I still write the eval. But I set the standard and let the loop chase it, instead of chasing every email myself.

My OpenClaw agent wouldn't stay autonomous. Here's what fixed it.

Sébastien Conejo — Wed, 18 Mar 2026 19:36:13 +0000

If you’ve set up automations in OpenClaw and they worked for a few hours then stopped silently, this is for you. The agent forgets its instructions, cron jobs show up empty, and you end up babysitting something that was supposed to be autonomous. I had the same problem. It took me a week of trial and error to get my agent to actually run on its own. If you’re hitting the same wall, here’s what fixed it for me.

One thing before we start: don’t use OpenClaw to configure itself. Use Claude Code or any coding agent to write the skill files, the rules, the scripts. Then let OpenClaw execute them. OpenClaw is good at running systems but less at building them. Sometimes when I asked it to write its own config, something would be off or missing and I couldn’t figure out why. Building the files externally and dropping them into the workspace was just more predictable.

Thanks for reading! Subscribe for free to receive new posts and support my work.

The skill file

Chat instructions don’t persist. You explain the tone you want, the agent nails it once, then forgets after compaction. Three sessions later it’s back to “Great thread! This is indeed a crucial topic in the AI landscape.”

What helped most was putting the instructions into a skill file. A markdown file in your workspace that the agent reads before every action. Mine has four sections:

identity (who the agent pretends to be on each platform),
voice rules (max 2 sentences, no hashtags, no AI filler, with concrete good and bad examples),
posting rules (when to mention my product and when not to),
and anti-drift rules.

The anti-drift section seems to make the biggest difference so far. Re-read the skill file before every session. Start fresh every 3 posts. If something fails, stop and report instead of retrying. Log every action with SUCCESS or FAILED. Still early but the agent has been way more consistent since I added this.

How I did it:

I wrote the full skill file in Claude Code, then told my agent

“Create a file at skills/social-media-skill.md with this content:”

and pasted it in. Verify it’s there with:

“Show me the content of skills/social-media-skill.md.”

Your agent lies

I asked my agent to post a comment using the built-in browser tools. It came back:

“I navigated to the post, typed the comment, clicked submit. The comment is live.”

I went to check and saw… Nothing. I mean, an empty comment box. It hallucinated the entire sequence.

What helped: I stopped relying on the browser tools and used dedicated tools instead. For Reddit, I found a clean skill on ClawHub (by theglove44) that uses Reddit’s API directly. I inspected the source before installing, one JS file, 16KB, no suspicious code, just standard Reddit API calls. For Twitter, I used xurl which handles the API natively. For anything that needed actual browser interaction, I wrote a Puppeteer script in Claude Code. In all three cases, the agent calls the tool, the tool does the work, returns a clear result, no hallucinated clicks!

I also added a rule in my skill file: “Never say you completed an action unless you can show the tool output confirming it.” Much more reliable so far.

How I did it:

I wrote two scripts in Claude Code and dropped them in the workspace scripts folder. The first one, reddit-search.mjs, scans subreddits via Reddit’s public API and scores each post by opportunity (upvotes, velocity, number of comments, topic keywords). The second, reddit-comment.mjs, uses Puppeteer with my existing Chrome session to actually post comments, with verification at each step (login check, comment box found, submission confirmed). I also installed the Reddit skill via ClawHub for API-based reads, and updated the skill file to say:

“Do NOT use the browser tool to post. Use the scripts and skills only.”

Both scripts are open source:

Heartbeat and cron

The heartbeat fires every 30 minutes and loads your full context each time. If your HEARTBEAT.md says “check email, calendar, Twitter, memory, projects,” you’re burning a massive context window 48 times a day.

Cron jobs run at specific times in isolated sessions. I use heartbeat for monitoring only and cron for actions. I have two cron jobs: daytime posts every 9-24 minutes with variation, nighttime posts hourly with a 3-hour quiet window.

How I did it:

I told my agent “Create two cron jobs” with the exact schedule I wanted. Then I verified they actually existed by running openclaw cron status in my terminal. If it shows jobs: 0, the agent didn’t create them even if it said it did. Keep asking until the number matches what you requested.

Memory breaks silently

When conversations get long, OpenClaw compacts them. The summary loses things. The agent forgets your corrections and starts drifting without telling you.

How I did it:

I told my agent

“Add this rule to AGENTS.md: before any compaction, save the 5 most important facts from the current session to memory/YYYY-MM-DD.md.”

I also created a separate log file for my specific use case (memory/social-media-log.md) so the agent has a concrete record of what it posted instead of relying on its own memory.

Verify with: “Show me the content of AGENTS.md” and check the rule is there.

One agent, one task

I started by trying to do everything at once. Multiple platforms, multiple personas. The agent got confused fast and the quality dropped.

What worked: one agent focused on one task only. It becomes good at that one thing. Once it’s stable and consistent, I can duplicate the approach for another task with a separate agent. Not before.

The files that matter

SOUL.md: personality. AGENTS.md: rules and memory protection. HEARTBEAT.md: monitoring only. Skill file: how to post, voice rules, anti-drift. Social media log: every action with results. Two cron jobs: day schedule and night schedule.

I’m still iterating on all of this, but so far each change made a noticeable difference. If you’re building something similar, I hope this saves you some of the trial and error.

How to stop burning money on OpenClaw

Sébastien Conejo — Tue, 03 Mar 2026 00:10:45 +0000

OpenClaw is one of the fastest-growing open-source projects in recent history. 230,000 GitHub stars, 116,000 Discord members, 2 million visitors per week. All of that in two months. People are running personal AI agents on their Mac Minis and cloud servers. It works, and it is genuinely useful.

Like any major shift in how we use technology, it comes with constraints. After speaking with over a hundred OpenClaw users, cost is the topic that comes up in almost every conversation. Someone sets up their agent, starts using it daily, and two weeks later discovers they have spent $254 on API tokens. Another spent $800 in a month. These are not power users pushing the limits. These are normal setups with normal usage.

Where the money goes

Your agent sends every request to your primary model. A heartbeat check, a calendar lookup, a simple web search. If your primary model is Opus 4.6, all of it goes through the most expensive endpoint available.

Your costs stack up from four main sources:

System context - SOUL.md loads into the prompt on every call. Other bootstrap files like AGENTS.md contribute depending on what the agent needs. Even with memory pulled in through search rather than loaded raw, the base system context still adds up. On a typical setup, you are looking at thousands of tokens billed on every single request.
Conversation history - Your history grows with every exchange. After a few hours of active use, a session can carry a large amount of tokens. The entire history tags along with every new request.
Heartbeat checks - The heartbeat runs in the background every 30 minutes by default. Each check is a full API call with all of the above included.
Model choice - Without routing, every request is sent to a single primary model, whether the task is simple or complex. That prevents cost optimization.

One user woke up to an unexpected $141 bill overnight because the heartbeat was hitting the wrong model.

Put all of this together on an unoptimized Opus setup and you can easily spend more per day than most people expect to pay in a month.

Use one agent with skills instead of many agents

This is the highest-impact change you can make and almost nobody talks about it.

A lot of users build multi-agent setups. One agent for writing, one for research, one for coding, one to coordinate. Each agent runs as a separate instance with its own memory, its own context, and its own configuration files. Every handoff between agents burns tokens. Each agent adds its own fixed context overhead, so costs scale with every new instance you spin up.

OpenClaw has a built-in alternative. A skill is a markdown file that gives your agent a new capability without creating a new instance. Same brain, same memory, same context. One user went from spending hundreds per week on a multi-agent setup to $90 per month with a single agent and a dozen skills. The quality went up because context stopped getting lost between handoffs.

Keep one main agent. Give it a skill for each type of work. Only spin up a sub-agent for background tasks that take several minutes and need to run in parallel.

Route each task to the right model

The majority of what your agent does is simple. Status checks, message formatting, basic lookups. These do not need a frontier model. Only a small fraction of requests actually benefits from premium reasoning.

Without routing, all of it hits your most expensive endpoint by default. One deployment tracked their costs before and after implementing routing and went from $150 per month to $35. Another went from $347 to $68. Smart routing tools can reduce costs by 70 percent on average.

OpenClaw does not ship with a built-in routing engine, so you need an external tool to make this work. Manifest handles this out of the box. It classifies each request and routes it to the right model automatically, so your heartbeats and simple lookups go to Haiku while complex reasoning still hits Opus. That alone cuts your bill dramatically without any manual config per task.

If you prefer a DIY approach, you can set up multiple model configs or write a routing skill yourself, but it takes more effort to get right.

Cache what does not change

Your SOUL.md, MEMORY.md, and system instructions are the same from one call to the next. Without caching, the provider processes all of those tokens from scratch on every single request. You pay full price every time for content that has not changed.

Prompt caching is a capability on the provider side. Anthropic offers an explicit prompt caching mechanism with a documented TTL where cached reads cost significantly less than fresh processing. Other providers handle caching differently or automatically, so the details depend on which model you are using. The point is the same: static tokens that hit warm cache cost less than tokens processed from scratch.

This is where the heartbeat becomes relevant. If your heartbeat fires often enough to keep the provider's cache warm between calls, every check reuses the cached system context instead of reprocessing it from zero. Cache TTLs vary by provider and configuration. Anthropic's standard TTL is around 5 minutes, with longer windows available depending on the setup. Community members have found that aligning the heartbeat interval just under whichever TTL you are working with keeps the cache alive. Combine that with routing your heartbeat to a cheap model and each background check costs a fraction of what it would on a cold Opus call.

The key principle is simple. Make sure your static content (system instructions, bootstrap files) sits at the beginning of your prompt and variable content comes at the end. That structure maximizes what the provider can cache. One user documented a drop from $720 to $72 per month primarily through this approach.

Shrink your context window

Every message you send includes your full conversation history. After a few hours that history alone can cost more than the actual answer. Three things you can do about it.

Start new conversations often. This is the easiest win. Instead of running one conversation for an entire day, start a fresh one every couple of hours. Your agent keeps its long-term memory across conversations but drops the accumulated back-and-forth. Context resets to your bootstrap files only.

Clean up your SOUL.md. Everything in that file loads on every single call. If you have task-specific instructions sitting next to your personality rules, you are paying for all of it every time. Move the specialized parts into skills. They only load when the agent actually needs them.

Optimize how memory loads into context. OpenClaw uses memory_search to pull relevant memories into your prompt, not the raw file. But the more memories accumulate over weeks of use, the more context those searches can return. Configuring the QMD backend and tuning what gets retrieved keeps that footprint tight. Some community members have built structured memory layers on top of this and cut their base context to a fraction of what it used to be.

Run a local model for the simple stuff

Running a model on your own hardware eliminates API costs for the tasks that do not need a cloud model.

You pay for hardware once. After that, every inference is free. For heartbeats, classification, and routine lookups, local models are more than capable.

The popular choice right now is Qwen 3 32B. On an RTX 4090 it runs at 40+ tokens per second. A Mac Mini running 24/7 handles the lightweight workload while cloud models only get called for complex reasoning.

Ollama makes the integration simple. Install, pull the model, point your OpenClaw config at the local endpoint for specific task types. It works through an OpenAI-compatible HTTP endpoint.

Track your costs daily

Every user who cut their bill says the same thing. The fix was not a specific technique. It was seeing where the money went.

Checking your bill once a month hides everything. You miss the day a cron job misfired. You miss the skill that routes to Opus when it should hit Haiku.

Use an observability tool that shows you per-prompt, per-model cost breakdowns. When you can see exactly which request went to which model and what it cost, problems become obvious. The fixes usually take minutes once you see the data.

Some routing tools offer real-time tracking with daily budgets and alerts so you catch problems before they compound. Your provider dashboard already tracks spending, but the granularity varies.

Where to start

Start with visibility. Set up an observability tool so you can see which prompts cost what and which models they hit. You cannot optimize what you cannot measure.

If you are running multiple agents, switch to one agent with skills. That is the highest return for the least effort.

Route your heartbeat to a cheap model. This alone makes a noticeable difference on a 24/7 agent.

Enable prompt caching. It takes minutes to set up.

Keep your context lean. Clean up your SOUL.md, start new conversations regularly, and switch your memory to vector search.

Add a local model if you have the hardware. It handles heartbeats and simple tasks at zero marginal cost.

Based on what we've observed across multiple OpenClaw deployments, applying these changes can reduce monthly costs by five.

If you're running OpenClaw agents and want to keep costs under control, we built Manifest for that. It's free, open source, and gives you real-time cost tracking with smart model routing. Feedback is welcome, we're building this with the community.

The OpenClaw ecosystem is exploding. I mapped the key players actually gaining traction.

Sébastien Conejo — Tue, 03 Mar 2026 00:04:45 +0000

I curated the key players shaping the OpenClaw ecosystem, just 2 months after launch.

What's happening around OpenClaw is unlike anything I've seen in open-source AI.

In 60 days:

230K+ GitHub stars
116K+ Discord members
ClawCon touring globally (SF, Berlin, Tokyo...)
A dedicated startup validation platform (TrustMRR)
And an entire ecosystem of companies, tools and integrations forming around a single open-source project.

Managed hosting, LLM routing, security layers, agent social networks, skill marketplaces. New categories are emerging in real time.

Some of these players are barely weeks old. And established companies like OpenRouter, LiteLLM or VirusTotal are building native integrations.

I mapped the ones that matter right now: The Claw Market Map, Q1 2026 Edition.

If you're a VC looking at AI infra, an operator deploying agents, or a founder building in this space, this is the landscape today.

Most of what's on this map didn't exist 60 days ago.

This is what happens when an open-source project ships with the right primitives at the right time. The community doesn't just adopt, it builds.

I'll keep updating this map. If you're a key player in the OpenClaw ecosystem and I missed you, drop a comment.

The OpenClaw ecosystem is exploding. I mapped the key players actually gaining traction.

Sébastien Conejo — Fri, 27 Feb 2026 18:59:07 +0000

I curated the key players shaping the OpenClaw ecosystem, just 2 months after launch.

What's happening around OpenClaw is unlike anything I've seen in open-source AI.

In 60 days:

230K+ GitHub stars
116K+ Discord members
ClawCon touring globally (SF, Berlin, Tokyo...)
A dedicated startup validation platform (TrustMRR)
And an entire ecosystem of companies, tools and integrations forming around a single open-source project.

Managed hosting, LLM routing, security layers, agent social networks, skill marketplaces. New categories are emerging in real time.

Some of these players are barely weeks old. And established companies like OpenRouter, LiteLLM or VirusTotal are building native integrations.

I mapped the ones that matter right now: The Claw Market Map, Q1 2026 Edition.

If you're a VC looking at AI infra, an operator deploying agents, or a founder building in this space, this is the landscape today.

Most of what's on this map didn't exist 60 days ago.

This is what happens when an open-source project ships with the right primitives at the right time. The community doesn't just adopt, it builds.

I'll keep updating this map. If you're a key player in the OpenClaw ecosystem and I missed you, drop a comment.

I built an open-source alternative to OpenRouter that runs on your machine for your OPenClaw 🦞

Sébastien Conejo — Fri, 27 Feb 2026 03:43:13 +0000

Stop overpaying for your OpenClaw usage!

There is a way to drastically reduce your costs. It is Manifest! A free open-source platform that intercepts every prompt and routes it to the appropriate model that can handle it.

The platform gives you real-time cost per prompt, model and message so you always know where your tokens go. You can set budget alerts and usage limits.

Everything runs locally on your machine. We never collect your messages or prompts, only metadata for telemetry.
The platform is fully open source and self-hostable. If you prefer not to run it locally we also have a cloud version.

Our goal is to give every OpenClaw user full control over their agent spending.

We just shipped this and will improve it with the community. If you try it out we'd genuinely love your feedback on GitHub or Discord. Tell us what's broken, what's missing, what you'd want next. It would help a lot. 🙏

Our website

Our Github

I built a platform that enables AI agents to execute complex tasks

Sébastien Conejo — Sat, 14 Feb 2026 23:08:21 +0000

Hey everyone,

With OpenClaw, Claude Code, Codex CLI, agents are getting incredibly good at reasoning. But they still struggle with certain actions. Booking a restaurant, scraping a page, filling out a complex form. They break down when precision, sequencing, and reliability actually matter.

We're building a platform where your OpenClaw agent can call purpose built services designed to execute high precision tasks reliably.-> https://manifest.new

If this resonates and you’ve had to look for services or build something to make your agents work better, I’d love to hear about it in the comments.

🔥 5 Epic Tools To Launch Your MVP Now

Sébastien Conejo — Fri, 22 Aug 2025 15:21:32 +0000

Whether you’re a solo founder, an indie hacker, or a CTO, one thing matters more than anything: shipping fast. Thanks to AI, a new wave of tools makes it possible to go from idea to product in record time.

We’ve picked 5 that cut out the usual pain and let you move straight to building.

UploadThing

UploadThing is a modern alternative to S3 built for developers. It handles the heavy lifting of file storage and delivery while giving you a type-safe API, a CDN, and simple routes you control from your code.

You decide what files can be uploaded, add auth and metadata with middleware, and process results on completion. It integrates with all major frontend frameworks and has backend adapters for Express, Fastify, H3 and more.

A clean developer-first way to add secure file uploads without the usual S3 pain.

Try it out

Manifest

Manifest is an open source backend to ship fast. It allows you to define your backend in a single file. It has simple code approach easy for developers to read and write and easy for LLMs to generate.

Most existing backend tools are painful. They are bloated, they force you into endless configuration, and they lock you into complexe dashboards. Manifest takes the opposite path. You just describe your backend in a YAML file to instantly get data, logic, auth, storage and an admin UI.

It runs self-hosted out of the box with SQLite, Postgres, MySQL or MariaDB. A Cloud version with AI is coming soon. It will take you from an idea to a production backend instantly.

Try it out

CopyCoder

CopyCoder is an AI-powered tool that lets you clone and scaffold complete web applications in minutes. By uploading screenshots of your target app, CopyCoder generates optimized prompts that can be run directly in Cursor to build a working frontend almost instantly.

And by the way, it works perfectly with Manifest, presented just above. Install Manifest to your project in Cursor and let the chat spin up the backend for your frontend.

Perfect for solo founders who want to turn ideas into production-ready apps without wasting time on boilerplate.

Try it out

Tally

Tally is the simplest way to create online forms without coding. It works like Notion but instead of blocks you add fields, type your questions and build a form in seconds.

You get unlimited forms and submissions for free with advanced features like conditional logic, payment collection, file uploads, e-signatures, hidden fields and integrations with tools like Notion, Google Sheets, Airtable and Zapier.

When you publish your form, you get a shareable link and all the responses land in your dashboard. It gives you exactly what you need when you want to ship a prototype with a form to test an idea or collect insights from real users.

Try it out

Rork

Rork is an AI-powered no-code platform focused on mobile apps. You describe your idea in plain English and it generates a working iOS and Android app using React Native and Expo. You can preview your app instantly in the browser or on your phone with Expo Go, then publish it to the app stores.

It’s especially useful if you want to ship a mobile app quickly, whether it’s a social app or a fitness tracker. You can also import Figma designs and iterate with prompts.

There’s no free plan though, you’ll need a paid subscription starting at about 25€ per month to export and actually use the apps you generate.

Try it out

Conclusion

These 5 tools remove the friction that usually slows you down and give you the shortest path from idea to product.

If you need to ship a product fast whether it is an app, a prototype, an MVP or even to win a hackathon these tools will save you precious time.

If you use them let me know what you think in the comments and feel free to suggest other tools

😉 Thank you

Build a backend with Cursor and Manifest in just 5 minutes 😱

Sébastien Conejo — Mon, 23 Jun 2025 18:10:26 +0000

TL;DR

In this article, I’ll show you how to build a backend in under 5 minutes using Manifest directly from your Cursor IDE.

We’ll start from a static real estate listing app and replace static data with a fully functional backend: data, filters, CRUD, and admin panel!

Introduction

If you’re experimenting with AI-powered development, you’ve probably seen two types of tools emerge.

First, there are vibe coding tools like Lovable or Bolt. They’re great at turning a short prompt into a polished UI. For quick prototypes, they feel magical. But when it comes to integrating a backend, they hit a wall. You stay stuck with mock data without backend logic.

The second are AI code editors like Cursor or Windsurf. These let you code with assistance, directly in your environment. But even then, generating the backend is where problems start.

The AI spreads logic across too many files. Once you iterate, it introduces strange changes that are hard to track. Reviewing everything becomes exhausting, and you can’t really trust that the result is secure. You still need backend skills to understand what was generated and make sure nothing breaks or leaks.

You might consider using one of the many no-code BaaS platforms. Some of them now offer MCPs to bridge the gap between visual tools and AI code editors, but their core experience is still tied to their studio. Even with those improvements, you end up switching back and forth, breaking your flow and slowing down iteration.

Manifest solves this by allowing you to code or vibe-code a backend instantly. No drag and drop. Just 1 YAML file easy to read and edit both by developers and LLMs.

Prerequisites

Before getting started, make sure you have Node.js installed on your machine.

Used Tools

Here’s an overview of the tools we’ll be working with:

Cursor: An AI-powered code editor. In this tutorial, we’ll use it with its default LLM, Claude Sonnet 3.5.
Manifest: Manifest is the backend for developers who want to ship fast. We will use it to create instantly a backend with data, storage, logic and an admin panel.
- Fits naturally into AI-assisted coding. No bloated no-code UI
- Easy and safe to validate
- Reduce LLM token usage by up to 90%
- The fastest way to build a backend.
- It's open source and can be self-hosted effortlessly.

→ Try Manifest

Project setup

We’ll start from an existing frontend that displays a few real estate listings using static sample data.

Our goal is to replace this static data with a backend powered by Manifest. We'll keep the existing structure and avoid adding unnecessary complexity. So the data can be managed by administrators.

Now, let’s take a quick look at how the current frontend works before installing the backend.

The current UI is a simple real estate listing page. It displays a few sample properties with basic details like title, image, price, surface and more.

The project has a client/ folder that contains the frontend. It was generated using bolt.new, which gives us a nice starter to work with and allows us to stay focus on the backend work.

Each property follows a consistent structure defined in a types/Property.ts.

The sample data is located in data/properties.ts. This is the static content we’ll replace with real data from our backend.

These properties are rendered using a PropertyList component.

Now that we’ve seen how the frontend works, let’s install Manifest and bring it to life.

Install Manifest

Manifest is designed to integrate directly into your AI code editor. It doesn’t require any external dashboard or setup flow. Everything lives in a single YAML configuration file.

From the root of your project, run the following command:

yarn create manifest server --cursor

This will create a server/ folder containing your backend Manifest.

Once the folder is generated, open manifest/backend.yml. In this YAML file, you should see a default template of a backend, called My pet app.

Now, let’s ask Cursor to generate the backend for our real estate app.

Here’s the prompt I used:

Cursor replies with a YAML file describing your backend. In my case, it named the project: name: Real Estate Listing App 🏠 and defined the three core entities: Property, Agent and Inquiry.

# This is a sample file for a backend.yml manifest backend.
# Read more about the manifest format here: https:/manifest.build/docs

name: Real Estate Listing App 🏠
entities:
  Property:
    properties:
      - title
      - { name: price, type: number }
      - location
      - city
      - { name: bedrooms, type: number }
      - { name: bathrooms, type: number }
      - { name: surfaceArea, type: number }
      - description
      - { name: image, type: image }
      - {
          name: type,
          type: choice,
          options: { values: ['House', 'Apartment', 'Studio'] },
        }
    belongsTo:
      - Agent
    policies:
      read:
        - access: public

  Agent:
    properties:
      - name
      - email
      - phone
      - { name: photo, type: image }
    policies:
      read:
        - access: public
      create:
        - access: public

  Inquiry:
    properties:
      - name
      - email
      - message
    belongsTo:
      - Property
    policies:
      read:
        - access: public
      create:
        - access: public

The assistant also explains its choices, especially the access policies.

Let’s accept this version for now.

To start the backend and access the generated API and admin panel, just run:

npm run manfiest

Once it’s up, go to http://localhost:1111/api to explore your API routes and test them in the Swagger interface.

You can also explore the admin panel by visiting: http://localhost:1111
Here, you’ll find all your entities listed with a full interface to manage your data.

Try creating a few residences and agents directly from the UI. You’ll instantly see them appear in your API responses too. On my side, I seeded mock data running npm run manifest:seed from the server repository.

Now that the backend is running, it’s time to connect the frontend to real data.

Connect the frontend to the backend

Let’s replace the static content with real data from our backend.

1. Install the Manifest SDK

We can use either the REST API or the SDK. For this tutorial, I chose to use the SDK. To do so, run this command in your client folder:

npm i @mnfst/sdk

Once installed, we can use the SDK to fetch the data from our backend.

In App.vue, replace the static data import with a real API call using the SDK:

import Manifest from '@mnfst/sdk'

This imports the Manifest SDK. It allows us to interact with the backend.

const manifest = new Manifest()

This creates a new instance of the Manifest client. It will automatically connect to the local server running on localhost:1111.

const properties = ref<Property[]>([]) const loading = ref(true) const error = ref<string | null>(null)

Here we set up reactive state:

properties will hold the residences fetched from the backend.
loading lets us show a loading state while we wait.
error will capture any issue if the request fails.

onMounted(async () => {
  try {
    const res = await manifest.from('residences').find({ perPage: 100 })
    properties.value = res.data
  } catch (e: any) {
    error.value = e.message || 'Unknown error'
  } finally {
    loading.value = false
  }
})

This code runs when the component mounts. It fetches up to 100 properties from the backend and stores them in the properties array. If something goes wrong, we store the error message.

For now, we keep it simple by fetching everything in one request. We could add pagination later using the page and perPage options provided by Manifest.

You’ll also need to update the template to reflect the loading and error states:


<div v-if="loading" class="loading">Loading properties...</div>
<div v-else-if="error" class="error">{{ error }}</div>
<PropertyList v-else :properties="properties" />

This ensures that:

A loading message is shown while we wait for the data
An error message appears if the fetch fails
The property list only renders once the data is available

Now your frontend is powered by backend data and ready for the next step. Let’s take a look at the result in the browser:

What we’ve got so far

At this point, your frontend is fully connected to a real backend.

You can browse residences, apply filters, and manage listings in a clean admin interface.

What’s most interesting is how little code we had to write for the backend:

Most of the logic lives in a single YAML file. That’s what makes Manifest a perfect match for an AI code editor like Cursor.

✅ The LLM gets a clear, structured context to work with.
✅ It can generate reliable changes without scattering logic across the project.
✅ You stay in control and iterate faster.

This was the main goal of this tutorial: show how fast and safe it can be to bring real data into a frontend project, thanks to how naturally Manifest integrates into your AI coding environment.

Want to go further?

Manifest supports essential backend features like file uploads, authentication, custom hooks and so on.

The full version of this project with inquiry forms and email is available on GitHub:

→ github.com/SebConejo/real-estate-example

Manifest is an open source young project.
It’s evolving fast thanks to the feedback we get from early users. We’d love to hear what you’re building, what’s missing, and what you’d like us to add next.

👉 Try it here: manifest.build

⭐️ Star us on GitHub: github.com/mnfst/manifest

7 insanely fast dev tools to build, deploy, and move on ⚡🔥

Sébastien Conejo — Thu, 06 Feb 2025 21:45:31 +0000

Trae

Trae is an AI-powered IDE designed to boost developer productivity by offering intelligent code suggestions, debugging assistance, and optimization tools. It combines a sleek interface with advanced AI to help developers write and refine code faster and more efficiently. Trae supports multiple languages and frameworks, making it a versatile tool for both prototyping and production-level coding. While it’s not affiliated with TikTok, its seamless integration and AI-driven features position it as a strong contender in the developer tools space, rivaling popular IDEs like VS Code with Copilot, or Cursor.

Try it out 🔥

Manifest

Manifest is a minimalist, streamlined Backend-as-a-Service (BaaS) designed for speed and simplicity. It lets you define your backend in a single YAML file, instantly getting a REST API, a database, an SDK, and an admin panel.

No complex setups. No unnecessary configuration. Just a lightweight backend that gets out of your way, so you can build and deploy faster than ever.

Here’s how effortlessly you can define a backend:

name: my portfolio
entities:
  Project:
    properties:
      - title
      - description
      - role
      - { name: score, type: number }
      - { name: date, type: date }
      - { name: url, type: link }
      - {
          name: photo,
          type: image,
          options:
            {
              sizes:
                {
                  small: { height: 403, width: 805 },
                  large: { height: 806, width: 1610 },
                },
            },
        }
  Contacts:
    properties:
      - name
      - email
      - { name: message, type: text }

👉 Yes, this is the entire backend of a portfolio. Crazy, right? I actually put it to the test in my latest article: I Built a Portfolio in Minutes with Bolt and Manifest. Check it out! 🚀.

Try it out 🔥

Mermaid

Mermaid is an open-source JavaScript library that allows users to generate diagrams and charts from plain text in a simple and intuitive way. Using a Markdown-like syntax, it enables the creation of flowcharts, sequence diagrams, Gantt charts, and more, directly within documentation or code. Its main advantage** lies in its ease of integration and ability to automate visual creation, making it an ideal tool for developers and technical teams looking to add charts easily.

Mermaid.js is a JavaScript-based diagramming tool that lets you write flowcharts, sequence diagrams, Gantt charts, and more—using a simple markdown-like syntax.

flowchart LR
    A[Hard] -->|Text| B(Round)
    B --> C{Decision}
    C -->|One| D[Result 1]
    C -->|Two| E[Result 2]

The code above generates the following chart. I love it!

Perfect for technical documentation, dashboards, and wikis, it integrates seamlessly with Markdown-based platforms like Notion, GitHub, and Docusaurus.

Try it out 🔥

Sevalla

Sevalla is a modern alternative to Heroku that makes it easy to deploy and manage applications, databases, and static sites, with support for Git, Docker, and Cloudflare for fast and optimized deployments. Its streamlined workflow eliminates unnecessary complexity, allowing developers to focus on building rather than configuring.

Try it out 🔥

Keystatic

Keystatic is a Git-based headless CMS that lets developers and content teams manage structured content in flat files, without needing a database.

No databases, no backend! Just structured content stored directly in your repo.

Try it out 🔥

Lovable

Lovable is an AI-powered Full Stack Engineer that makes app development very fast and effortless, without writing a single line of code. It connects seamlessly with platforms like Supabase.

By transforming natural language prompts into fully functional applications, Lovable significantly reduces development time. It supports large codebases and offers a rich collection of templates. Whether you're a beginner or an experienced developer, Lovable helps you turn ideas into working products with minimal effort.

Try it out 🔥

Drizzle

Drizzle is a lightweight, high-performance ORM for TypeScript that provides a type-safe, SQL-first approach to database management. It supports PostgreSQL, MySQL, SQLite, and SQL Server while prioritizing speed, simplicity, and full TypeScript integration.

Unlike traditional ORMs, Drizzle follows a data-mapper pattern, allowing direct control over queries without abstractions. Its fluent API makes writing SQL intuitive, safe, and efficient, making it an ideal choice for serverless applications, high-performance APIs, and SQL-focused projects.

Try it out 🔥

🚀 Ready to build better?

In 2025, speed and simplicity are the keys to efficient development. Tools like Manifest, Keystatic, and Drizzle strip away unnecessary complexity, while Lovable and Trae AI introduce automation to supercharge your workflow. These tools help you build, deploy, and move on—without the bloat.

Which of these tools will you try first? Let me know in the comments! 🚀

If you found this article useful, share it with your peers and community.

Got other awesome projects in mind? Drop them in the comments! 👇