Jev Search lets a decision model pick the search engines, then ranks what comes back

A decision model chooses the sources, then the results are ranked

Jev Search searches the web in plain language, and the unusual part is who decides what to search. A decision model such as TypeSafe's Jev, Cloudflare's Clef or OpenAI's GPT-6 Luna chooses sources, time ranges and search terms, then ranks the results returned through Search1API. You get links and snippets, with visible relevance scores and editable filters, and no generated answers.

That last clause is a design position rather than a missing feature. The application returns ranked links with snippets and lets you judge them, rather than writing a paragraph and asking you to trust it. The visible relevance score is the counterpart to that choice: the ranking is exposed rather than hidden behind a summary.

The homepage is jev.s1.dev, and the README describes the project as built by Search1API and as an independent project, not an official TypeSafe product.

There is also an installable application form. You can add it from the browser, with Add to Home Screen on iOS and Install app on Chrome and Edge. The README is careful about what that gives you: searches still need a network connection, and the installed app caches only an offline page, not results.

The three stage pipeline

The How it works section describes three stages, and each stage is a separate concern.

The first is Understand. The configured decision model answers typed questions about your request, and the application uses those judgments to choose a query, sources and a time range. You can override the source and time chips.

The second is Search. Google, DuckDuckGo and Yandex search the open web. Hacker News, Reddit and GitHub each combine a Google site-restricted search with their dedicated engine, and Hacker News uses the news endpoint. X, arXiv, YouTube, Wikipedia, IMDb and WeChat use vertical engines. Calls run concurrently, and one failed engine does not discard another engine's results.

The third is Rank. The decision model scores each result for relevance. Results are merged by URL, ordered by relevance, engine agreement and original rank, and streamed as each lane finishes. Lower-scoring results are grouped separately, and a failed source shows a warning rather than a zero-result count.

Three details here are worth dwelling on. The concurrency is per engine, so a slow vertical engine does not hold up the rest. The merge by URL means the same page found by several engines appears once, and agreement across engines becomes a ranking signal in itself. And a failed source produces a visible warning rather than being silently counted as zero results, which is the difference between a broken search and an empty one.

The README gives three example requests, including Rust async runtimes on Hacker News this month, what Reddit users think of the Framework laptop, and new papers on speculative decoding. The last one names no source or time and lets the decision model choose, which is the case the whole design exists for.

The streaming API and the model picker

The application streams newline-delimited JSON from POST /api/ask, and the event types are worth knowing if you build on it.

The intent event includes judge, the decision provider that interpreted the request. The found event carries progress counts. The lane event carries ranked results, and the done event ends the stream. Since results are streamed as each lane finishes, a slow source does not delay the sources that are already done.

There are deadlines at both levels. Each engine has a 15-second deadline within an overall 30-second request deadline, and Google may start speculatively while the decision model interprets the question. Successful, non-empty engine responses are cached for 10 minutes to 6 hours, depending on the time window.

When more than one model is configured, the search box offers Auto and each distinct model. The list comes from GET /api/models, which exposes model names but no provider credentials. The chosen model is stored in the search URL and sent as m to POST /api/ask.

Auto uses the full configured provider chain. An explicit model uses only the providers serving that model, in their configured fallback order, and it never silently switches to a different model. The progress details show which provider interpreted the request, and ranking calls may use another provider for the same model if a fallback is needed. That last property, no silent model switching, is a correctness guarantee rather than a convenience, because otherwise your results would come from a model you did not choose.

There is also an optional s source list, capped at the number of supported sources, currently 12 entries before filtering. Longer lists return HTTP 400 before any provider calls are made. Repeated valid sources are merged preserving their first occurrence, so repeating a source cannot multiply search or ranking calls. Selecting all supported sources remains allowed.

Running it locally on Cloudflare Workers tooling

The stack is TanStack Start, React and the Cloudflare Vite plugin, deployed to Workers with KV and a rate-limit binding.

Local development requires Node.js 22.12+ and pnpm 10.8.0, an API key from Search1API, and at least one decision provider configured.

git clone https://github.com/superagents-lab/jev-search.git
cd jev-search
corepack enable
pnpm install --frozen-lockfile
cp .dev.vars.example .dev.vars
# Set SEARCH1API_API_KEY and at least one decision provider in .dev.vars.
pnpm dev

You open http://localhost:3030. The .env.example file is provided as a variable reference, but .dev.vars is the documented local configuration and it is ignored by Git, so keep it private.

One wrinkle deserves attention. Local development uses local KV and rate-limit bindings, but the Workers AI binding is remote and uses your wrangler login session. Wrangler opens that remote session when pnpm dev starts, even if JEV_PROVIDERS is unset or excludes Cloudflare models, so you need to authenticate with wrangler login or set CLOUDFLARE_API_TOKEN in the process environment first.

The remaining scripts are in package.json.

pnpm generate-routes
pnpm cf-typegen
pnpm test
pnpm build
pnpm exec wrangler deploy --dry-run

Tests mock providers and do not need API keys, and building does not call any provider. worker-configuration.d.ts is generated from the Wrangler configuration and .dev.vars.example, so it has to be regenerated after changing bindings or secrets.

The provider configuration is a single ordered list, and the comment in .dev.vars explains the semantics: the enabled decision providers in order of preference are typesafe, vercel, cloudflare, clef, clef-flash and openai. Unlisted providers stay off, and extra listed ones act as fallbacks on 402, 429 and 5xx. An empty value means typesafe.

Deploying, and the two things that belong to the hosted demo

Deployment to Cloudflare Workers needs an account with Workers and KV enabled, and the README walks through five steps with two warnings attached.

The first warning is about identifiers that are committed but wrong for you. You run pnpm exec wrangler kv namespace create jev-search-cache and replace the CACHE namespace ID with the returned one, because the committed ID belongs to the hosted demo and is not a credential. You also update the origin in src/lib/seo.ts and public/robots.txt to match your deployment, since the sitemap and changelog feed are generated from src/lib/seo.ts.

The second is about analytics. You remove or replace the Cloudflare Web Analytics snippet in src/routes/__root.tsx, because the committed token belongs to the hosted demo. The changelog in content/changelog/ describes the hosted demo, so you delete its entries or replace them with your own.

Both warnings are the same lesson: the repository ships with the hosted instance's configuration in place, so a fork that is deployed without editing them would be serving the original's analytics and caching in someone else's account.

The rate limit is the other operational detail. You choose a unique rate-limit namespace_id in your account, and the default limit is 10 searches per IP per minute per Cloudflare location, which is not a global spending cap. Searches triggered by source or time filter changes count toward the same limit, which is a detail worth knowing because filter changes are often not thought of as searches.

Provider keys go in as secrets rather than in the configuration.

pnpm exec wrangler secret put SEARCH1API_API_KEY

The project is MIT licensed with the LICENSE file at the root, the repository has no GitHub releases, and the last push was on 2026-10-07.

Where Jev Search is the wrong choice

Four cases argue against it.

The first is if you want an answer rather than results. The README states plainly that there are no generated answers, and the whole design is built around returning links, snippets and scores for you to evaluate. If the goal is a summary with citations, an assistant-style search product is the better fit.

The second is if you need your own search infrastructure. This application depends on Search1API for the actual engine calls, so you are paying a provider for the queries and inheriting their coverage. The multi-engine fan-out is a feature of that provider, not something the repository implements, and the vertical engine list is a property of Search1API's coverage.

The third is cost predictability. The rate limit is 10 searches per IP per minute per Cloudflare location, and the README says explicitly that it is not a global spending cap. Each search fans out to many engines and then to a ranking model, so a busy public deployment multiplies both costs, and the README says nothing about billing other than that cap.

The alternative in the same direction is to call the search providers yourself with a small service, which gives you control over the per-query budget, the cache policy and the ranking prompt. The difference in approach is that Jev Search gives you a working multi-engine pipeline with a decision model choosing the sources, streaming results as they arrive, and visible relevance scores, all of which is a fair amount of code to rebuild. If your requirement is a search experience rather than a search utility, this repository is the faster route, and if your requirement is control over spend and providers, it is not.

Editorial conclusion

Jev Search fits a developer who wants a search engine with an explicit, inspectable pipeline, where a decision model chooses the sources and the results carry visible relevance scores instead of a written answer, and who is prepared to run it on Cloudflare Workers with their own provider keys. It does not fit a reader who wants an answer rather than links, since the README is explicit that there are no generated answers. Run it locally with `pnpm dev` after copying `.dev.vars.example` to `.dev.vars`, and if you deploy it, replace the committed KV namespace ID and the analytics token, both of which belong to the hosted demo.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. superagents-lab/jev-search on GitHub