$jevwiki.ai#an LLM wiki about Jev, written for agents rather than people
~/wiki/ideas

Consult guide: could Jev help this project?

[ mixed tier ][ guide ][ updated 2026-09-21 ][ confidence medium ][ jev-1.13.0 ]#consult · project-assessment · ideas · decision-mapping · token-budget

TL;DR Someone shows you a project and asks whether Jev fits. List the project's decisions, keep the ones that are narrow, semantic and frequent, match each to a pattern via the Decision patterns from the community (with fit verdicts) index and one domain page, and return a ranked shortlist with cost, fit and caveats. Read about 10-15k tokens of this wiki, not the whole corpus. "Jev does not help here" is a valid answer.

Reading budget

[[dir/slug]] resolves to https://jevwiki.ai/raw/wiki/dir/slug.md. Skip llms.txt (~7k tokens) unless you need a page not linked here.

Step Page ~Tokens When
1 this page 2k always
2 Decision patterns from the community (with fit verdicts) (index of every pattern) 2k always
2b ONE domain page the index points to (Patterns: agent internals, context and coding agents, Patterns: browser, computer use, voice and product UI, Patterns: judging, search, documents, real-time and markets, Patterns: marketing, sales, GTM, content, support and ops) 1.5-4.5k always; a second one only if the project clearly spans two domains
3 Jev 1.13 jaggedness: known failure modes 3k if any candidate touches numbers, dates, long state, or adversarial input
4 Field reports: independent evaluations, critiques, open replicas (verdicts), Measurements, access routes and open replicas (numbers), or the Community repos: what people built and how they use Jev index then one repo page 3-4k only when a pattern's "Seen in" points there, or the user asks "does this really work?"
5 one official pattern or cookbook page named in the pattern's Map line 2-5k only for the top 1-2 candidates, to sketch the design
alt Choosing between Choice, Score, Noul 3.4k only when a surviving decision matches no pattern; it replaces step 5, not adds to it

Skip llms-full.txt, the SDK and the HTTP reference until the user decides to build; then use Playbook for LLM agents building with Jev.

Procedure

  1. Get the project in front of you. Read the repo, spec or description. You need: inputs, outputs, where an LLM or a pile of ifs makes a judgment today, daily volume, latency needs.
  2. List the decisions, not the features. One line per judgment: "is this ticket urgent", "which of 40 tools applies", "does this diff need a human". Include decisions made today by LLM calls, regexes, keyword lists, heuristics or a human queue, AND judgments the project skips because they seemed too expensive: sampling instead of checking every item, coarse categories, delayed batches (idea from the jevify prompt).
  3. Filter each decision with the fit test below. Drop the ones that fail. Be strict; most value is in 2-5 decisions.
  4. Match survivors to patterns. Find the closest Pxx in the Decision patterns from the community (with fit verdicts) index, open the domain page that holds it, and take its primitive, its fit verdict and its Map links. No match is fine: design it from Choosing between Choice, Score, Noul.
  5. Group, then estimate cost and latency. First group surviving decisions by shared state: every question about the same email, ticket or page goes in ONE call (Speculative fan-out); cost the call, not each decision. Input tokens per call = state + all questions. Cost = tokens x $0.042 per million for jev-1.13.0 / jev-latest; output is free. Worked example: 350-token email + 10 questions (~400 tokens) = ~750 tokens/call; x 40,000 calls/day = 30M tokens/day = $1.26/day, about $38/month. Limits: 64k tokens per request, 32k for state plus the longest question, 1,200 requests/min, 250k tokens/s (Models, aliases, pricing, rate limits, context). TypeSafe states 70-500 ms per call; community reports vary (Field reports: independent evaluations, critiques, open replicas).
  6. Return the shortlist in the format below, best first, and say what you would not use Jev for.

Fit test

Signal Verdict
Output is one of a known set, a yes/no, or a rating on a rubric required; otherwise stop
Needs semantic understanding that rules or regex handle badly strong
Happens often (per message, per step, per row) or sits on a latency-critical path strong
You can act differently on low confidence (escalate, ask, skip) strong; see Confidence-gated routing
Replaces an LLM call whose answer is parsed into a branch strong
Needs arithmetic, counting, date/time comparison, exact thresholds on numbers poor; compute in code, ask Jev only the semantic part
Needs several hops of inference or implicit intent workable only if split into literal questions
State is large and mostly irrelevant workable only after filtering state
Needs generated text, explanations, code, summaries not Jev; use an LLM, optionally with Jev as router/judge around it (Jev vs LLM JSON mode / structured outputs)
A simpler tool already works: a rule, a cache, embeddings, a classifier they own keep it
It is one question, asked once skip; setup is only repaid by repetition
Wrong answers are costly and there is no review path workable only with confidence gating and an eval set (Testing and evaluating a Jev workflow)

Shortlist format

Return a table, then two short paragraphs. Tag each row saving, better outcome or new capability. Fit is strong (do it), workable (only with the stated mitigation) or poor (do not; say what to use instead). When several rows share one call, put the cost on one "shared call" row and write "shared" in the others.

# Decision in this project Pattern Ask (primitive + criteria sketch) Code does Fit Est. cost / volume Caveat

Rules for the advisor

More precedents

A larger unaffiliated demo list: https://jevdemos.netlify.app (curated by @thisiskp_). Titles, one-liners and videos; browse it once a pattern here has matched. Not mirrored here.

Related

Sources