Question 1

The badge says live API unverified. Is this safe to build on?

Accepted Answer

Treat it as an early-evaluation library, which is how the author frames it. Offline tests, samples and package-consumer checks pass, but live Jev compatibility is unverified and live testing is deferred, so validate the service and your own application before production. Live tests exist but are separately opt-in, use synthetic inputs and have a documented request budget; the normal test suite needs no Jev credentials at all. The pinned .NET 10 feature band in global.json is 10.0.4xx, so you need that SDK.

Question 2

What does running with --offline actually prove?

Accepted Answer

That the plumbing works, not that the model is any good. The README says --offline is explicit, uses labelled synthetic HTTP responses, does not evaluate a model and does not demonstrate model quality. The point is that missing live credentials never silently select offline mode, so a green sample run is not something you can mistake for a validated integration. You can move to live calls later with the Set-JevUserSecrets.ps1 script, which prompts for a masked key and passes it through stdin rather than command arguments.

Question 3

Is the Microsoft.Extensions.AI integration real or just wrappers?

Accepted Answer

It is composition, not generation, and the README is careful about which is which. AIFunction exposes explicitly configured decision operations as tools, IChatClient routing selects among caller-registered real chat clients, and DelegatingChatClient assessments review inputs or buffer outputs before returning them. Not supported is native chat, embeddings, image, speech, files and realtime, because the documented Jev service does not offer them. The Jev key enables decisions, not another provider's generative model.

Question 4

How do retries and rate limits behave, and can a failure get billed twice?

Accepted Answer

Retries are narrow by default: only 429 and 529. Ambiguous network failures and other 5xx need explicit replay opt-in, and the README notes they may be billed. Requests are immutable with owned JSON values so concurrent calls are safe, cancellation covers HTTP, response reads and retry waits under a total deadline, and there is no automatic provider fallback. Keys, prompts and error bodies stay out of default SDK messages, though raw native data and opt-in error bodies can still be sensitive.

Question 5

Can I run decisions locally with Ollama instead of paying for a cloud key?

Accepted Answer

Yes, through ElBruno.AI.Decisions.Ollama with Ollama v0.35.0 or later and a pulled System One decision model such as nimble, clef or Tev1, pointed at http://localhost:11434/. No API key is needed. Native System One support requires 0.6.1 or later because the published 0.6.0 package used a chat-logprob approach, and live local compatibility is still unverified.

Question 6

What are the real input limits, and what does the confidence number mean?

Accepted Answer

Text requests are capped at 64 KiB and are never truncated. Choice option counts depend on the model, typically 2 to 26 against an API maximum of 255, and the shared Score API takes 2 to 10 ordered levels. On Ollama the confidence figure is 1 - H(p)/ln(N), a measure of how concentrated the distribution is, explicitly not calibrated correctness.

Question 7

How do I install it, and what is in the box?

Accepted Answer

Four MIT-licensed NuGet packages on .NET 10, currently 0.6.2 as early access: ElBruno.AI.Decisions for the shared IDecisionClient plus separate Foundry, Ollama and Jev providers. Jev talks to https://api.typesafe.ai with the key configured as Jev:ApiKey through user secrets, and AddJev registers JevDecisionClientAdapter for dependency injection. The original ElBruno.AI.Jev package is not yet deprecated.

ElBruno.AI.Jev

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev guides

From the Jev community