DEV Community: Alexander Lukashov

Our MCP server was fine. Cloudflare was returning HTML.

Alexander Lukashov — Thu, 10 Sep 2026 09:50:32 +0000

This is what our MCP endpoint returned to a client speaking JSON-RPC:

HTTP/2 403
content-type: text/html; charset=UTF-8
server: cloudflare

Attention Required! | Cloudflare
Please enable cookies.
Sorry, you have been blocked

A program was being asked to enable cookies.

We did not see that for three days, because that is not what the client reported. The client reported a parse failure, and a parse failure points at your own serialization, not at a machine four thousand kilometres away.

What it looked like from inside

The connector could not talk to our server. The tools never listed. Everything we could check on our side looked correct: valid JSON-RPC, right content type, right status codes, protocol revision we support.

So we did the reasonable thing and started fixing the things that were wrong but adjacent.

GET /{prefix}/_mcp was returning JSON. Per the Streamable HTTP spec it should return 405 if the server does not offer an SSE stream on GET. We changed it. It is a real fix and we kept it.

It changed nothing.

That is the value of shipping one variable at a time. If we had bundled that change with anything else, the next result would have been unreadable.

The thing that actually settled it

We wrote a minimal MCP server that imitated our own response shape exactly: application/json on POST, 405 on GET. A hundred lines, no auth, no database, nothing of ours in it. Then we exposed it through an ngrok tunnel and pointed the same connector at it.

It worked immediately. Tools listed, first try.

That one result eliminated most of the search space. Our response shape was fine, because a server with the same shape worked. The protocol was fine. The connector was fine. What was left was everything between the connector and our application, which is exactly the part we had not been looking at, because it is not in the repository.

If you take one thing from this: when you cannot find the bug in your code, build something that cannot possibly contain it and see whether the problem follows. The mimic server took an hour. It saved the rest of the week.

It was the user agent

Here is the same request, same body, same endpoint, varying only User-Agent:

user-agent                          code  content-type              bytes
Claude-User/1.0; +claude.ai          200  application/json            156
Claude-SearchBot/1.0; +claude.ai     200  application/json            156
anthropic-ai                         200  application/json            156
curl/8.7.1                           200  application/json            156
ClaudeBot/1.0; +claude.ai/bot        403  text/html; charset=UTF-8   4543
GPTBot/1.2; +openai.com/gptbot       403  text/html; charset=UTF-8   4543

A Cloudflare managed rule, on by default, blocking AI crawlers. Nobody on our side had turned it on. Nobody had turned it off either, which is the point.

Look at the fourth row. curl passes. Every tool you reach for when something is broken is on the allowlist, which is why this survives so long. You test the endpoint, it answers, you conclude the endpoint is fine, and you go back to reading your own code.

One limitation worth stating: every row above was sent by curl, so the TLS fingerprint was held constant while only the header changed. That proves the user agent alone is enough to trigger the block. It does not prove the user agent is the only signal, and bot detection also reads the ClientHello. If you allow an agent by name and it still gets refused, that is the next variable to vary.

The taxonomy is where it goes wrong

Anthropic runs three crawlers on purpose, so that a site owner can make three separate decisions.

ClaudeBot collects content that may contribute to training. Claude-User fetches a page because a person just asked Claude a question. Claude-SearchBot indexes for search results. Three names, three robots.txt entries, three different trade-offs. The split exists precisely so you can refuse training and stay reachable.

Cloudflare has a category for exactly that middle case. It is called AI Assistant, and here is who is in it, as the crawler list shows it today:

ChatGPT-User            OpenAI        AI Assistant
MistralAI-User          Mistral       AI Assistant
Perplexity-User         Perplexity    AI Assistant
DuckAssistBot           DuckDuckGo    AI Assistant
Meta-ExternalFetcher    Meta          AI Assistant
Manus Bot               Manus         AI Assistant

Claude-User             Anthropic     AI Crawler

Look at the naming. ChatGPT-User, MistralAI-User, Perplexity-User, Claude-User. One convention, one job, four vendors. Three of them are filed as assistants and one is filed as a crawler.

Meta gets it right twice over: Meta-ExternalAgent is an AI Crawler and Meta-ExternalFetcher is an AI Assistant, which is the same split Anthropic makes and the same split OpenAI makes.

So this is not a taxonomy that has failed to catch up with agents. The category exists, it is populated, and six vendors are in it correctly. One row is filed wrong.

The consequence lands on one vendor's users. Block the AI Crawler category, which is what the default does, and ChatGPT-User, Perplexity-User and the rest keep working. Claude-User does not. You made one policy decision and got a different outcome depending on which assistant your customer happens to use, without being told that is what you were choosing.

Fixing it on your side means allowing that agent by name, and first you have to work out that you need to. Ours now refuses the training crawlers and passes the user-initiated traffic, which took a deliberate change rather than anything the default did for us.

Fixing it properly is one row in Cloudflare's own table.

Nothing in the response says you were blocked

This is what makes it expensive rather than annoying.

There is no JSON error. No error code. No header explaining the refusal. cf-mitigated is absent. All you get that a machine can read is server: cloudflare and a cf-ray id, and neither of those means anything to a JSON-RPC client that expected an object and got a document.

So the client raises a parse error, and a parse error is a lie about where the problem is. It points inward, at your serializer, your framework, your content type. Every hypothesis it suggests is about code you own.

The part almost nobody uses: this is configurable. The same screen has a Configure Response control that sets the status code and message returned to blocked crawlers. If the thing behind your CDN is an API, a JSON body with an explicit reason costs nothing and turns three days of debugging into one line in a log. Blocking somebody is fine. Blocking them in a format they cannot parse is a choice you probably did not mean to make.

The raw evidence

Both sides of the same request, so you can see what a client has to work with.

Allowed, Claude-User:

HTTP/2 200
content-type: application/json

{"jsonrpc":"2.0","id":1,"error":{"code":-32002,
 "message":"Server not initialized",
 "data":{"hint":"Call initialize first and reuse Mcp-Session-Id header."}}}

That is our server refusing the call, correctly, in the protocol, with a hint saying what to do next. 156 bytes.

Blocked, GPTBot:

HTTP/2 403
content-type: text/html; charset=UTF-8
server: cloudflare
cf-ray: a38529b8ec8bc239-BEG

Attention Required! | Cloudflare
Please enable cookies.
Sorry, you have been blocked
You are unable to access fxns.io

4543 bytes of HTML. No cf-mitigated header, no JSON, nothing naming a rule. A client written against the MCP spec has no branch for this.

The same thing decides whether agents can discover you

Agent cards, OAuth protected-resource metadata, MCP discovery documents: all of it is converging on /.well-known/. That only works if the thing fetching it is allowed to fetch.

Ours is reachable, and here is how you tell:

/.well-known/oauth-protected-resource     404  application/json
/definitely-not-a-route                   404  application/json

body: {"message":"Route not found","error_code":"route_not_found",...}

The 404 is ours. Same JSON envelope as any unknown route, which means the request reached the application. A block page instead of your own error format means it did not. Check whose 404 it is, not whether you got one.

The five minute version

Take your own endpoint and run the request you care about six times, changing only the user agent:

for ua in "curl/8.7.1" "Claude-User/1.0" "ClaudeBot/1.0" "GPTBot/1.2"; do
  curl -s -o /dev/null -w "$ua %{http_code} %{content_type}\n" -A "$ua" \
    -X POST https://your.endpoint/_mcp -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
done

Run it again in a month. The category a crawler sits in is Cloudflare's data, not yours, and it can be refiled without anything changing on your side, including the test you ran to prove your rule was safe. Check per user agent, not per category, and check more than once.

If the codes differ, or the content types do, the layer in front of you is making decisions you did not make. Watch the content type especially: a proxy can answer 200 with an HTML body, and no status check will ever catch that one. In Cloudflare they live under AI Crawl Control, in the Security section, one row per crawler. Then decide which of those decisions you actually want, because refusing training crawlers and refusing your customers' agents are not the same choice, and by default they are the same switch.

Updated after publishing: added the AI Assistant category table after a reader asked how the vendors line up, noted that the user agent matrix held the TLS fingerprint constant, and extended the check to content type after a reader pointed out that a proxy can answer 200 with an HTML body.

One question, 437,000 tokens: what real agents found in our MCP server

Alexander Lukashov — Tue, 08 Sep 2026 12:48:00 +0000

One question. 437,000 input tokens.

Not a hard question either. An agent connected to our MCP server, asked something a support engineer answers in a sentence, and worked its way there through twenty tool calls, each one dragging every earlier answer along behind it.

Nothing was broken while that happened. The server answered initialize correctly, spoke the 2025-03-26 revision, returned valid JSON-RPC to everything we threw at it. All of which turned out to be beside the point.

So we pointed real agents at production and watched. 18 scenarios, two vendors, a 5 dollar budget that we topped up once. This is the long version with the traces in it. There is a shorter one on our blog if you only want the conclusions.

What the server is

Briefly, because it shapes everything below.

FoxNose stores content as collections: schema-defined records with typed fields, some of them vector indexed. The MCP server is generated from that schema and served from the same URL prefix as the REST API. Fixed catalog of seven tools regardless of how many collections exist, five read and two optional write.

Collections are what an agent chooses between, so a badly described collection is effectively invisible. And the agent inherits exactly the rights of the API key it connects with, so there is no second allowed-tools list drifting out of sync with the first.

What the harness actually is

A scenario is a question in plain English, a set of tools, and a check.

The checks are where we made the most mistakes, so start there. They do not look at the answer text. Model output moves between runs, and a suite that asserts on wording is a suite you quietly stop trusting. They look at the trace: which tools ran, in what order, with what arguments, which errors came back, how many tokens the whole thing burned.

A check is a small predicate over the run:

any_of(
    no_tool_errors(),
    recovered_after("unknown_resource", then="search_records"),
)

That second branch exists because of a mistake I will get to at the end.

We ran everything twice, on Anthropic's hosted MCP connector and on OpenAI's hosted MCP in the Responses API. Same server, same questions, two clients.

Finding 1: the bill is round trips, not bytes

Back to those 437,000 tokens.

A hosted connector runs the tool loop on the vendor's side. Every iteration re-sends the whole conversation to the model. So a tool call does not cost what it returned. It costs what it returned, times the number of turns after it.

Input tokens per scenario, before and after we shipped truncated search results and changed the page size:

scenario	before	after
R4	437,751	78,072
N5	175,421	26,078
R5	128,800	17,054
R8	115,027	12,607
R7	93,770	123,831

Same questions, same collections, same models. The only thing that moved is how much each call handed back and how many calls it took to get there.

R7 went the wrong way, and it is the clearest evidence for the point. It compares two collections, five hits each was not enough, so the agent searched again and again and finished at fourteen tool calls. A smaller page moves cost out of the payload and into the turns, and the turns are the expensive part. One scenario out of nine moving backwards was a trade we took, but it is the shape to watch.

These numbers are from the Anthropic connector. Every scenario ran on both, but the token comparison above is single vendor.

Twenty calls against fourteen is not twenty over fourteen. Everyone tunes model choice. Almost nobody counts round trips.

What we shipped. Text fields in search results are capped at 1000 characters by default, and every field that got cut carries a marker with its path, its locale, and the original length. So the agent knows per field whether it is holding a fragment. An 11,917 character body arrives as 1000 and says so. get_record hands over all 11,917.

Page size went to a default of 5 with a maximum of 100, and both numbers live in the tool's JSON schema, so the model reads the range in the catalog before its first call.

We could not choose a good page size for everybody, so we stopped trying and told the caller the range instead. Publishing the bounds mattered more than which number we picked.

Finding 2: your error strings are control flow

An agent hit an error, read the hint attached to it, did exactly what the hint said, failed the same way, read the same hint again. No crash. Nothing logged as wrong. It spent its entire iteration budget being obedient to a wrong instruction.

One line out of place caused it. We return structured errors, an error code plus a message plus a hint saying what to do next, and one code had been handed a different error's hint. Code right, status right, wrong sentence.

A person reads a wrong hint and shrugs. A model does not shrug. The hint is the next instruction.

Here is the same mechanism working, which is the part I actually want to show you. Real trace, from a scenario where the agent guessed:

discover_resources                                  ok
search_records  resource_id="documentation"         unknown_resource
                hint: call discover_resources and reuse exact resource_id
search_records  resource_id="kb_foxnose"            ok
get_record      MbJbdnzj9fJw                        ok

Four calls. It invented an identifier, got told exactly how to recover, recovered, answered. The whole exchange costs less than one wide search. Cheap recovery is something you build on purpose, and it only works when every hint points at its own failure.

Finding 3: a JSON-RPC notification is defined by the absent id

Small, pure protocol, which is why it lives here and not in the short version.

In JSON-RPC 2.0 a notification is a request with no id member. That is the entire definition. You must not reply to one, and you must reply to everything else.

Our server was deciding by method name. Anything starting with notifications/ got treated as a notification.

Those two rules agree nearly always, which is how it survived as long as it did. They part company when a client sends notifications/initialized with an id. That is a request. The spec says answer it. We sent silence.

No client we tested does this. It is the kind of thing that surfaces a year from now, in an integration you did not write, with a symptom that looks nothing like the cause. We key off the presence of id now, like the spec says.

Finding 4: the client decides your authentication

We had two auth schemes, both requiring you to write your own Authorization header. Never a problem, because every client we developed against was one where we wrote the header ourselves.

Hosted connectors do not work that way. One token field, always sent as Authorization: Bearer <token>. That is the whole interface. No configuration, no workaround.

So our server could not be used from the two clients most people reach for first. Not broken. Unusable. And invisible from the inside, which is the part that stuck with me.

What we shipped. Bearer tokens: opaque, 47 characters, no colon so they cannot be confused with a public:private pair, shown once at issue, bound to an existing API key and exactly as powerful as it.

Then we measured how long it actually takes to cut someone off:

deleting the key            took effect after 305 s
emptying the key's role     took effect after 284 s
revoking a bearer token     took effect on the next request

The first two are a permission snapshot cache expiring. Revoking the token skips it, because the token itself stops resolving. Worth knowing before the day you need it.

Finding 5: two vendors, two shapes

We wrote the OpenAI transport after the Anthropic one and assumed it was the same code with the nouns swapped. It would have been wrong in three places.

Tool call arguments arrive parsed in one and as a JSON string in the other, so you parse in one transport and must not in the other.

The OpenAI SDK types the error field on an mcp_call as an optional string. The wire sends a dict:

{"type": "mcp_tool_execution_error",
 "content": [{"type": "text", "text": "<json>"}]}

Trust the annotation and you will eventually call a string method on a dict, in a branch that only runs when something has already gone wrong. Great place for a second bug.

The third one will bite anyone building on the Anthropic connector. It runs at most 10 tool iterations per request. If the agent has not finished, you get stop_reason: "pause_turn" with the partial work. HTTP 200. No error field anywhere.

A client that checks only for end_turn records a success and shows a truncated answer. We caught it because a scenario answered half a question and the harness passed it.

Where our own tests were wrong

A check that forbids all errors forbids recovery. Our no_tool_errors check failed three scenarios that were completely fine. In each one the agent guessed, got a hint, corrected itself, answered. The trace higher up in this post is one of them.

We had spent real effort making guessing cheap, then written a check that punished guessing. That is where the any_of at the top comes from. If your surface is meant to be explored, your tests have to let it be explored.

A negative result is not a result. We checked that a key from one environment cannot read another. It could not, and I nearly wrote that down as proof of isolation.

Then we checked whether the key could read anything at all. "Access denied" looks identical whether the isolation held or the credential was already dead. This caught us three separate times: isolation, bearer auth, revocation. Each of those needed a positive control sitting beside it, a case you know should succeed. Without one, all you have proven is that broken things stay broken.

What it cost

Under ten dollars of API spend across about ten days. The harness is a few hundred lines. Reading traces took far longer than running them.

Final state is 18 out of 18 on both vendors, against production.

If you are shipping an MCP server: take five real questions, run them through a hosted connector, and read the traces rather than the answers. Count the calls. Look at what each one handed back. Then ask whether a model that cannot see your dashboard could have done better than that.

Updated after publishing: added the one scenario that regressed, and noted that the token numbers come from the Anthropic connector.

Hybrid search for your app in an afternoon, for $0

Alexander Lukashov — Tue, 28 Jul 2026 18:00:44 +0000

Somebody's card gets declined. They open your help center and type "my money disappeared". Your article is called "Troubleshooting failed payments". Not one word in common, so search returns nothing and they write to support instead.

Keyword search only finds what you already named correctly. Semantic search fixes that, and then misses the other way: ask it for the error code NB-2001 and it hands you something thematically close instead of the page with that string in it. Hybrid runs both and merges them, so exact matches take the top and meaning fills in below.

The usual price for that is a vector database, an embedding pipeline and a sync job between your content and your index. Here is the version with none of those. It took an afternoon and cost nothing.

Quick disclosure: I built FoxNose, and Loquix is mine too. Everything below runs on a free account, and there is a short list at the end of cases where you should use something else.

The two pieces

FoxNose stores the content and does the search. Mark a field searchable and vectorizable and every record you publish is indexed for keywords and vectors. Hybrid search is on the free tier, and for a small product the free tier is enough to just run this.

Loquix is MIT web components, including a <loquix-search-dialog> you can drop in. Plain custom elements, so React, Vue or nothing at all.

The browser calls the search API directly. No backend of yours in the middle.

1. Describe the content

Sign up and create a project. FoxNose provisions one environment for it, Production, and you can add more later for staging or previews. An environment is a separate database with its own API host at https://{environment_key}.fxns.io. Note that key down, you need it in a minute.

Inside the environment, create a collection. Mine is called articles. Then give it a schema in the visual editor: fields, types, flags, publish. Schema versions are drafts until you publish them, so there is no way to half-apply a change.

I used a help center for a fictional product, 24 articles:

Field	Type	Flags
`title`	text	searchable, vectorizable
`slug`	string	-
`summary`	text	searchable, vectorizable
`body`	text	searchable, vectorizable
`category`	string	searchable

That is the whole search setup. searchable indexes the field for querying, vectorizable means embeddings get generated on every publish. No embedding code, nothing to keep in sync, no index to create.

Two things worth knowing before you load anything. Full-text search lives on text fields, not string, so anything people will actually search inside wants to be text. And a field's type cannot be edited later, only recreated: you remove the field and add a new one in its place, then load the content again. Cheap now, annoying after you have data.

2. Load the content

npm install @foxnose/sdk

Three values go into your .env here: the environment key from a minute ago, the collection key, and a management API key you create in the environment settings.

// seed.js
import fs from 'node:fs';
import { ManagementClient, SimpleKeyAuth } from '@foxnose/sdk';

const articles = JSON.parse(
  fs.readFileSync(new URL('./articles.json', import.meta.url), 'utf8'),
);

const client = new ManagementClient({
  environmentKey: process.env.FOXNOSE_ENV_KEY,
  auth: new SimpleKeyAuth(
    process.env.FOXNOSE_MGMT_PUBLIC_KEY,
    process.env.FOXNOSE_MGMT_SECRET_KEY,
  ),
});

await client.batchUpsertResources(
  process.env.FOXNOSE_COLLECTION_KEY,
  articles.map((article) => ({
    external_id: article.slug,
    payload: { data: article, name: article.title },
  })),
);

client.close();

Run it with node --env-file=.env seed.js on Node 20.6 or newer, so you do not need dotenv for this.

external_id makes it an upsert, so you can re-run this as often as you like. Each write validates the record, generates the embeddings, indexes it and publishes it.

You can also just type content into the visual editor, which is the point for a real product: support people edit help articles without a deploy.

3. Put the search online

Content is served through what FoxNose calls a Flux API. Create one, give it a prefix, connect the collection. Three settings matter for calling it from a browser:

connect the collection with both get_many and get_one, or results come back without content
make the API public, meaning anonymous reads (writes still need a key)
turn on Allow all origins so the API accepts calls from a browser at all (fine here, these articles are public anyway)

Now you have an endpoint:

https://{environment_key}.fxns.io/help-center/articles/_search

No key in your frontend, no proxy to hide that key.

4. Search

// flux.js
const BASE = 'https://YOUR_ENV_KEY.fxns.io/help-center';

export async function hybridSearch(query) {
  const response = await fetch(`${BASE}/articles/_search`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    signal: AbortSignal.timeout(10000),
    body: JSON.stringify({
      search_mode: 'hybrid',
      find_text: {
        query,
        fields: ['title', 'summary', 'body'],
        threshold: 0.85,
      },
      vector_search: {
        query,
        fields: ['title', 'body'],
        top_k: 25,
        similarity_threshold: 0.6,
      },
      hybrid_config: {
        vector_weight: 0.4,
        text_weight: 0.6,
        rerank_results: true,
      },
      limit: 25,
    }),
  });
  if (!response.ok) {
    throw new Error(`Search failed: ${response.status} ${await response.text()}`);
  }
  return (await response.json()).results;
}

One request, two ranked lists, one answer. NB-2001 returns the error codes page. "my money disappeared" returns the payments article. search_mode also takes text or vector if you ever want one side on its own.

threshold: 0.85 is your typo tolerance: at 1.0 matching is exact, lower is fuzzier, so "pyament declined" still lands.

Then there are two numbers that decide how good this feels, and neither has a universally right value:

similarity_threshold is the floor for "close enough" on the semantic side. Every document is a little bit similar to every query, so this is where you cut. Too low and a question about baking bread returns your billing articles. Too high and paraphrases stop working. 0.6 fits these 24 articles.

The weights settle words against meaning. Text-heavy works for a help center, where people search for strings that literally exist: error codes, plan names, button labels. For a product catalog, where nobody knows your wording, push the vector side up.

There is no magic here, which I think is the good news. It is arithmetic over two ranked lists. Load your own content, throw your real queries at it, move the two numbers, look at what comes back. Twenty minutes of that beats any default.

Filters live next to all this: where takes typed operators over any searchable field, combined with all_of and any_of.

5. The dialog

npm install @loquix/core lit

<loquix-search-dialog
  id="search"
  heading="Search help center"
  placeholder="Search help articles..."
  kbd="⌘K"
  mode="plain"
  hide-answer
></loquix-search-dialog>

mode="plain" keeps it a search box and hide-answer drops the LLM answer block, which is a different article. You get a real modal <dialog> with a focus trap, keyboard navigation, loading states and a chip row, none of which you write.

It knows nothing about any backend. It fires events and takes plain arrays:

import '@loquix/core/tokens/variables.css';
import '@loquix/core/define/define-search-dialog';
import { hybridSearch } from './flux.js';

const dialog = document.getElementById('search');

const CATEGORIES = [
  { id: 'getting-started', name: 'Getting started' },
  { id: 'billing', name: 'Billing' },
  { id: 'account', name: 'Account' },
  { id: 'api', name: 'API' },
];

let hits = [];
let category = 'all';

function render() {
  const shown = category === 'all'
    ? hits
    : hits.filter((hit) => hit.data.category === category);

  dialog.results = shown.map((hit) => ({
    id: hit._sys.key,
    title: hit.data.title,
    snippet: hit.data.summary,
    url: `/help/${hit.data.slug}`,
    source: CATEGORIES.find((c) => c.id === hit.data.category),
  }));

  dialog.sources = CATEGORIES
    .map((c) => ({ ...c, count: hits.filter((h) => h.data.category === c.id).length }))
    .filter((c) => c.count > 0);

  dialog.activeSource = category;
}

async function runSearch(query) {
  if (query.trim().length < 2) {
    hits = [];
    dialog.results = [];
    dialog.sources = [];
    return;
  }

  dialog.state = 'searching';
  try {
    hits = await hybridSearch(query);
    category = 'all'; // a new query starts unfiltered
    render();
  } catch (error) {
    console.error(error);
    hits = [];
    dialog.sources = [];
    dialog.results = [{ id: 'notice', title: 'Service is too busy. Try again.' }];
  } finally {
    dialog.state = 'idle';
  }
}

let timer;
dialog.addEventListener('loquix-change', (e) => {
  clearTimeout(timer);
  timer = setTimeout(() => runSearch(e.detail.value), 250);
});

// Enter fires submit, Cmd+Enter fires ask even in plain mode, so wire both
dialog.addEventListener('loquix-search-submit', (e) => runSearch(e.detail.query));
dialog.addEventListener('loquix-search-ask', (e) => runSearch(e.detail.query));

dialog.addEventListener('loquix-search-source-select', (e) => {
  category = e.detail.sourceId;
  render();
});

window.addEventListener('keydown', (e) => {
  if ((e.metaKey || e.ctrlKey) && e.key === 'k') {
    e.preventDefault();
    dialog.show();
  }
});

Three notes on that, because they are easy to miss:

.results and .sources are JavaScript properties, not attributes. Setting them in HTML does nothing.

Debounce is yours to add. Every keystroke would otherwise be its own request, and one request counts the same whether it returns one result or twenty five.

The chips filter what you already fetched, so their counts and their clicks describe the same set of results. No extra request, instant. The same strip is built for a bigger job: give each kind of content its own collection, fire one query per collection in parallel, and each chip becomes a source with its own count as the answers arrive.

React users: @loquix/react wraps every component, events arrive as props like onSearchSubmit. Both packages ship types.

What this is, and where it stops

Worth being straight about the shape of it: FoxNose is not a search engine. It is a typed content database built for LLM agents and RAG, with hybrid search included, which is why one API holds your records and retrieves them and there is nothing to sync in between.

A product that does search and only search goes further in specific places: merchandising rules, search analytics, highlighted snippets, facet counts across a whole corpus, US data residency, edge latency at very large scale. All real features, and if your product lives on one of them, use Algolia. For most teams shipping a help center or in-app search, none of them come up in a normal month.

If you would rather run infrastructure, Typesense and Meilisearch are excellent and free at any volume.

Take it

The whole thing is in one repo: https://github.com/loookashow/hybrid-search-help-center. Copy .env.example, add your keys, then npm install, npm run seed, npm run dev.

Two flags on a schema, one fetch, one component, two numbers to tune. Next time I will put a language model on top of the same API so the box can answer in sentences and cite the articles it used.

Go type "my money disappeared" into your own product's search. Curious what comes back.

Why I made my paid product fully free for personal use

Alexander Lukashov — Tue, 19 May 2026 16:25:33 +0000

I spent two months thinking about pricing before I let myself write the pricing page.

That is not a humblebrag, it slowed everything down. The product was technically ready in March. By April it could have been on sale. But every time I sat down to define the free tier, something did not sit right, and I would close the tab and go fix a bug instead.

What unstuck it was not a framework, a benchmark, or a YC essay. It was one question I could not answer to my own satisfaction. I want to write about it, because the question is generalizable and I think a lot of solo makers building tools quietly trip over it.

A bit of context first. I have been a technical product manager at large tech companies for many years, always on B2B SaaS, always with a team, always for someone else's company. The product I was pricing is Notch, a screen recorder for Mac and Windows. It is the first desktop app I have shipped under my own name. So this was the first time I was personally on the line for a pricing decision, with my own money funding the development and my own name on the receiver.

The freemium playbook I almost ran

When I sketched the pricing card the first time, it looked almost exactly like what every other screen recorder does:

Free tier with a 5-project cap, limited by 1080p output quality, and a watermark on exports
Paid tier at $49 one-time that removes both

This is the freemium playbook by default. The free tier is a trial in disguise. Generous enough to demo the product, restrictive enough that anyone using it seriously has to upgrade. Loom does it. Screen Studio does it. Camtasia does it. Tella does it. So did the spreadsheet I was modelling.

The numbers added up. The conversion funnel made sense. I built the watermark into the export pipeline. I implemented the project counter and a "you've hit your limit" modal. I tested both. They worked.

I just did not want to ship them.

The question I could not answer

The discomfort was not moral. I had convinced myself the freemium model is honest enough, since the limits are visible upfront. The discomfort was about a specific user I kept picturing.

That user is someone like me five or ten years ago: an engineer recording their first screencast tutorial for their blog, a student doing a class project, a hobbyist showing their indie game on Mastodon. Someone who is not going to make a dollar from the thing they are recording. Someone for whom $49, even one-time, is meaningful money.

Why am I asking them to pay?

I sat with that question for two weeks. Every answer felt thin.

"Because the software costs me money to maintain."

OK, true, but that user is not loading my support queue. They are not going to email me. They are using the product silently.

"Because if I let them export for free, they will never upgrade."

They were never going to upgrade. They do not have a use case for the Commercial license, they are not running paid work through it. The "upgrade" framing is a trick I would be playing on someone who could not fall for it.

"Because it is the standard model in the category."

The least convincing answer of all. "Everyone does it" has never been a strong reason to do anything.

The honest version of the question kept reformulating itself in my head:

Why should someone pay me if they are not making money from this themselves?

I did not have a good answer. So I stopped trying to find one.

What I changed

I removed the project cap. I removed the watermark. I removed all limits. The personal tier of Notch is fully free. No degraded export, no nag screens, no asterisks. You install the app, you hit record, you export your video. Done.

The Commercial license is still there. It is $49 one-time, with team pricing for 3 and 10 seats. The split is not "free for limited use, paid for everything". It is "free for personal use, paid for revenue-generating use". The line is the purpose of the recording, not the feature set.

This means:

A student making a class project: free, forever, with full features.
A bootcamp graduate recording tutorials for their portfolio: free.
An OSS maintainer recording a feature demo for a GitHub issue: free.
A teacher recording an async lesson for their students: free.
A consultant making client deliverables: Commercial license.
A SaaS team recording onboarding videos: Commercial license.
A YouTuber monetizing their channel: Commercial license.

The free tier and the Commercial tier are the same software. The license is what changes.

The objection I expected

I had a draft of this post that opened with the predictable objection: "But how will you actually make money?"

I cut it because I think it deserves a real answer, not a defensive setup. Here is the real answer.

Most non-monetizing users were never going to pay anyway. Walking into a freemium model assuming they are conversion-able is wishful. The honest math: if 95% of free-tier users would never pay regardless of how much you crippled the free tier, your "free tier" was effectively gifting them a worse product than they could have had, and resenting them for not converting.

Commercial users are different. They have a budget line for tools. They are comparing me to Loom at $18/user/month or Screen Studio at $108/year. A one-time $49, or $29/user for a 10-pack, is the cheapest thing in their procurement queue. They are going to pay.

Goodwill compounds. The student who got Notch for free for a year, who graduates and goes to a SaaS company that needs internal training videos, that is the person who pitches Notch to their boss. Not because of switching costs, but because they already know it works and trust it. That kind of advocacy does not show up in a conversion funnel, is almost impossible to A/B test, and stacks over years.

The "real free tier" is a marketing position. It is also a moat. Every competitor who runs the freemium-with-limits playbook is implicitly telling their non-monetizing users "we tolerate you, for now". That is not a feeling people seek out.

The deeper reason

I will be honest about the part that is not a pricing argument.

I went into product management years ago because I love watching the results of my work get used. Not "purchased". Used. The thing I find satisfying about shipping is people getting value. If I could only sell products and never see them in someone's hands, I would have stayed in e-commerce.

Building "another commercial product", one more entry in a category, optimized for revenue capture, was not a strong enough reason for me to spend a year of my evenings on something. It is a thing I could have done with my day job's time instead. The reason I built Notch is that I kept wanting it to exist and nothing else delivered it. The reason I am shipping it is that I want other people to have it too.

A pricing model that restricts the people most likely to enjoy the product, in order to maximize revenue from the people also most likely to enjoy the product, is solving for the wrong thing.

The team and Commercial side will pay for itself. I would rather underearn from the model I chose than overcharge through one that fights my own reason for building.

What I'd tell another maker

Three things, briefly.

Pricing reveals what you actually think your product is for. If the only way the math works is by limiting the people who would love your product most, the math might be wrong.

The freemium playbook is the default, not the answer. It works for some categories, usually ones with high marginal cost per user, strong network effects, or genuine paid value the free tier cannot replicate. Most maker tools are none of those.

Trust your discomfort. I spent two months avoiding writing a pricing page because the model I was about to ship felt wrong. That feeling was data. I should have listened to it sooner.

If you are curious what the product looks like with this pricing applied: Notch is on Mac and Windows, fully free for personal use, no account, no cloud, no nags. Commercial license is one-time, $49.

I am happy to argue any of the above in the comments. I think I am right, but I have been wrong about pricing for a living.

May the force be with you.

I Evaluated Every AI Chat UI Library in 2026. Here's What I Found (and What I Built)

Alexander Lukashov — Wed, 18 Mar 2026 18:00:24 +0000

TL;DR:

React stack → assistant-ui
Full agent framework → CopilotKit
Quick prototype or non-React → Deep Chat
Python backend → Chainlit (check project status first)
Multi-framework + composable → Loquix

⚠️ Conflict of interest: I'm the author of Loquix, one of the libraries reviewed here. The independent reviews come first. Loquix gets its own clearly-labeled section at the end, written by me about my own work — treat it accordingly. If you want the quick take: for most teams, assistant-ui (React) or Deep Chat (everything else) is the more pragmatic answer.

Before the reviews: four types of lock-in

After evaluating all of these libraries, the biggest insight wasn't about any specific tool — it was that "lock-in" isn't one thing. There are at least four distinct flavors, and understanding which one you're accepting changes how much it matters:

Type	Example	When it bites
Framework	assistant-ui (React-only)	When you need to support other frameworks
Architecture/runtime	CopilotKit	When your agent infrastructure evolves independently of your frontend
Ecosystem	Vercel stack	Creeps up over time; each layer pulls you deeper
API-surface	Deep Chat	When your requirements outgrow the component's config options

Framework lock-in is rarely a problem if your whole team is on React. Architecture lock-in hurts when backend and frontend evolve at different speeds. Ecosystem lock-in you feel slowly — you start with useChat, six months later you're on Vercel hosting, each step made sense. API-surface lock-in only matters when your requirements outgrow the defaults.

I'll reference these types throughout the reviews so you can calibrate the tradeoffs for your situation.

What "chat UI" actually requires

"Messages going up, input at the bottom" — I thought the same thing. Then I started building. Here's the real scope:

Core: Token-by-token streaming without UI glitches, markdown + code blocks with syntax highlighting, a composer that auto-grows and handles Shift+Enter.

Interactive layer: File attachments (drag-and-drop + clipboard paste), feedback buttons for RLHF, a stop-generating button (you'll add this at 2 AM after your agent writes a 4,000-word essay about semicolons), model selectors.

Trust layer: Citations, reasoning traces, tool execution logs, cost estimates. Users increasingly expect to see why the AI said what it said.

The invisible stuff: Accessibility (WCAG, keyboard nav), theming that survives a designer, i18n.

Build all of that from scratch: 2–4 weeks, before a single line of agent logic. That's why this market exists.

The libraries

assistant-ui ⭐ ~7.9k — React, composable, headless — MIT

YC-backed. The library that shows up in every "build a ChatGPT clone" thread.

Follows the Radix headless pattern — unstyled primitives (Thread, Composer, Message) you compose yourself. State management is thoughtful, streaming is first-class, Vercel AI SDK integration is tight.

Who it's for: React + Next.js teams that want maximum control without implementing the hard parts. If your whole stack is React, this is the safe default — mature ecosystem, responsive maintainers, well-designed composability model.

Where it hurts: React-only (framework lock-in). Vue, Svelte, Angular, vanilla JS — not supported. "Headless" also means you do all the design work; getting a polished UI requires assembling many pieces and the learning curve is real.

Lock-in type: Framework.

CopilotKit ⭐ ~28.6k — React, agent framework with UI — commercial tiers available

Not just a UI library — an agentic application framework that includes UI components. Drop in <CopilotPortal />, get a full copilot experience. Agents can read your app state, call your functions, generate UI dynamically. They co-created AG-UI and partnered with Google on A2UI.

Who it's for: Greenfield projects where you're buying into their whole architecture. If you need deep agent-app state sync and generative UI, nothing else comes close.

Where it hurts: If all you need is a good chat interface, this is a flamethrower for a candle. More importantly: it's not just framework lock-in, it's architecture lock-in. You're adopting their agent execution model, state sync, action system — not just swapping in components. On brownfield projects with existing agent infrastructure, that means rethinking things you've already built.

Lock-in type: Architecture/runtime (the heaviest kind).

Vercel AI SDK + AI Elements — React, hooks + growing component layer — MIT

The AI SDK is everywhere: model-provider abstraction with useChat / useCompletion hooks. Not a UI library at its core, but Vercel has been expanding into actual components with AI Elements — composable React components on top of the SDK.

Worth mentioning separately: the Vercel AI Chatbot is the official open-source reference implementation built on this stack. Many teams use it as a starting point or benchmark for what a production chat UI looks like.

Who it's for: Anyone already in the Vercel ecosystem. AI Elements is worth evaluating alongside assistant-ui if you're on Next.js.

Where it hurts: The Vercel stack has gravitational pull. You start with useChat. Six months later you're on Vercel hosting. Each step made sense individually — the cumulative effect is ecosystem lock-in that's softer than CopilotKit's but real.

Lock-in type: Ecosystem.

TanStack AI — alpha, framework-agnostic hooks — MIT

TanStack — the team behind React Query, React Router, React Table — launched their AI toolkit. Framework-agnostic core, adapters for React, Solid, vanilla JS. Headless, type-safe.

Important context: this is alpha from a team with a strong track record of shipping production-grade, widely-adopted tools. That's different from "alpha from unknowns." If it matures the way React Query did, this will be a serious foundation layer.

Who it's for: Nobody in production yet. Watch this space.

Where it hurts: No pre-built UI components — hooks and utilities, not a chat interface. Vue and Angular adapters aren't there. Not ready for production today.

Google A2UI — declarative format for agent-generated UI

Agents send JSON describing which components to render; your frontend renders them from a trusted catalog. No executable code from the agent — no XSS nightmares. Framework-agnostic by design. Ships initial renderers for Lit, Angular, Flutter.

Who it's for: Teams building agent-generated dynamic UIs. The CopilotKit integration is worth watching, and this is one of the more interesting directions for generative UI / RSC-style patterns outside the React ecosystem.

Where it hurts: It's an infrastructure layer, not a component library. Not something you'd drop into a project and ship today.

Deep Chat ⭐ ~3.3k — Web Component, framework-agnostic — MIT

The one that made me sit up. A single Web Component for AI chat — framework-agnostic, built-in connections to OpenAI, HuggingFace, Cohere, Azure, Stability AI, AssemblyAI out of the box. Ships with speech-to-text, text-to-speech, file uploads, image handling.

Time-to-working-chat: under 10 minutes. No backend glue required to get started.

Who it's for: Prototypes, internal tools, non-React projects, or anywhere chat is a feature rather than the core experience. Best option when you need something working fast that doesn't care about your frontend framework.

Where it hurts: One component with configuration options, not a composable system. When you need to restructure layout, inject custom UI between messages, or add domain-specific controls — you're working within what the property API can express. Same tradeoff as any "convention over composition" approach: faster start, less flexibility when requirements diverge from defaults.

Lock-in type: API-surface.

Chainlit ⭐ ~11.4k — Python-first, full-stack

The go-to for Python developers who wanted a chat UI without touching JavaScript. Write your agent in Python, get a polished web UI with reasoning steps, file uploads, markdown.

Caveat: The original team stepped back from active development in May 2025. Community maintainers have picked it up. Worth verifying current project status before building on it.

One more thing: "Chat UI" is becoming "Agent UI"

Streaming is solved. Every library handles it well now — it's no longer a differentiator.

What's not solved is composition for agent-specific UI patterns: approval flows, reasoning traces, tool execution displays, cost transparency. These are becoming table stakes, not features. Libraries that only solve the messaging problem will feel incomplete within a year.

Generative UI (agents that emit UI, not just text) is the next frontier — watch A2UI + CopilotKit here, and the RSC patterns in the Vercel ecosystem.

Loquix — what I built, and why you probably shouldn't use it yet

Repeat disclosure: this is my library. Everything below is me describing my own work. The same "where it hurts" standard I applied above applies here too.

None of the options above fit my specific situation: a product where the customer's frontend framework isn't fixed, and I wanted composable building blocks rather than a monolithic widget or agent runtime.

So I built Loquix — a Web Components library on Lit, specifically for AI chat interfaces. (npm install @loquix/core)

The approach

35 individual Web Components that compose like this:

<loquix-chat-container>
  <loquix-chat-header slot="header">
    <loquix-model-selector slot="actions" />
  </loquix-chat-header>
  <loquix-message-list>
    <loquix-message-item role="assistant">
      <loquix-message-content streaming />
      <loquix-message-actions>
        <loquix-action-copy />
        <loquix-action-feedback />
      </loquix-message-actions>
    </loquix-message-item>
  </loquix-message-list>
  <loquix-chat-composer>
    <loquix-prompt-input />
    <loquix-drop-zone />
  </loquix-chat-composer>
</loquix-chat-container>

Verbose, yes. But when your designer says "move feedback above the message" — you move the component. No prop drilling, no checking if feedbackPosition is a valid prop value.

Backend integration is a type-only interface with no runtime dependency on any specific provider:

interface AgentProvider {
  send(messages: Message[], options?: SendOptions): Promise<{
    stream: ReadableStream<string>;
  }>;
}

Works in React, Vue, Svelte, Angular, vanilla JS. @loquix/react ships with proper wrappers for React's synthetic event system. Vue/Svelte dedicated packages are planned, not shipped.

Lock-in type: Platform (Web Components/Shadow DOM model, Lit if you extend components deeply) — just at the browser standards level rather than the library level.

Where it hurts — same standard as above

No production deployments. I can't point you to a production app using Loquix. That's a significant unknown that none of the other libraries in this review share.

Small community. No Stack Overflow answers. You'll be reading source code.

Incomplete roadmap. Reasoning traces, citations, cost estimates — Phase 4 and 5 — still in development. If you need those today, build them yourself or wait.

Lit learning curve. Consuming is easy. Deep customization requires understanding Lit's reactive model and Shadow DOM. React developers find this counterintuitive at first.

No built-in provider integrations. Deep Chat connects to OpenAI in 10 minutes. assistant-ui integrates with Vercel AI SDK out of the box. Loquix gives you a TypeScript interface and says "implement it." Better for experienced teams; more friction for everyone else — the same critique I'd apply to any library that takes this approach.

Concrete example where assistant-ui wins: chat UI integrating with Vercel AI SDK's useChat, rendering generative UI streamed from server, thread persistence, all in Next.js. With assistant-ui: well-documented, battle-tested. With Loquix: you'd be wiring streaming yourself, no RSC integration (Web Components and React Server Components don't mix naturally), and you'd be the first person to try this combination in production. Hard to justify.

If your situation is specifically "multi-framework team that wants composable components and is willing to be an early adopter" — evaluate it. Otherwise, the options above are more pragmatic.

The decision table

Situation	Recommendation	Maturity
React + Next.js	assistant-ui	✅ Production-ready
Full agent framework, generative UI	CopilotKit	✅ Production-ready
Provider abstraction + React	Vercel AI SDK + AI Elements	✅ Production-ready
Quick prototype, non-React, embedded widget	Deep Chat	✅ Production-ready
Python-first backend	Chainlit	⚠️ Check project status
Multi-framework + composable, early adopter	Loquix	🚧 No production deployments
Agent-generated dynamic UI	A2UI + CopilotKit	👀 Watch this space

Greenfield vs. brownfield: heavier frameworks (CopilotKit, Vercel full stack) accelerate you on greenfield when you're choosing everything fresh. Thinner UI layers (assistant-ui, Deep Chat, Loquix) cause less friction on brownfield where the architecture already exists.

The days of spending weeks building chat UI from scratch are over. Pick a library, commit, and spend your engineering time on the thing that actually differentiates your product.

If I missed a library you've used in production, drop it in the comments.

Unless you enjoy writing auto-scroll logic at 2 AM. In which case, I have a useEffect cleanup function I'd like to sell you.