Inferring Jev's internals from 1,000 calls

About ten thousand, according to both the post and the essay it summarizes. This entry's own summary says roughly one thousand, so hold the count loosely; the caveat that matters more is that none of this is a published architecture, since TypeSafe ships no weights or research, so every conclusion is black-box inference.

Not in the reported tests. The notes say each question is isolated, with a secret code written into one question not retrievable from another, and that only shared state is visible to all of them. Roughly a hundred questions barely moved request time, because shared context is encoded and cached once.

Carefully, if at all. Adding irrelevant dummy options shifted the relative odds between the original options, and reversing option order slightly changed output probabilities. The returned confidence field is also not a learned score - it is arithmetic on the largest probability in the distribution, so it is not independent evidence.

Treat both as hypotheses. An expected calibration error of 0.0313 and a lower stated probability on hard math are the author's own measurements against a closed API rather than a vendor benchmark, and he flags the sparse mixture-of-experts backbone as his least certain guess, inferred partly from throughput on very long inputs.

A technical article called Jev's Architecture Unmasked, published on archerhume.com and summarized here by a Japanese engineer. The post is a note-taking thread rather than the original, and it links the article at the end, so the inference method lives there rather than in the thread.

The article leans toward reuse. Given the knowledge level Jev shows, it concludes the team most likely repurposed an existing causal decoder LLM rather than developing a new bidirectional encoder. The tokenizer does not match any public model exactly, with custom digit splitting and chunking.

Barely. The write-up found that server time hardly changes whether a question offers two choices or two hundred, and that up to about a hundred questions in one request add little processing time because the shared state is computed once and cached. That is evidence there is no token-by-token generation loop.