jw1224

An LLM takes (text in) -> (text out).

Jev takes (…questions in) -> (…probabilities out)

So Jev won’t write a story or emit arbitrary structured data. But if you ask it the right questions, it can make near-instant “decisions” against those questions, with accuracy and world knowledge on par with LLMs. The economic advantage is that it’s parallelizable and can give back up to 255 answers at once, in milliseconds.

With a ratio of 1:√2, you can cut the sheet in half parallel to its shorter side, and each half keeps the same proportions.

There are some amusing apps which read the MacBook's lid angle sensor. I remember one of them played a creaking noise through the speakers when you open or close it... Somehow I doubt App Store review will let that in for the Duo, but we can always hope.

I've used a similar technique with my own tools. It helps to save context overall, by deferring the detailed instructions not only to when they're needed, but also to where they're needed.

Simply loading the browser Skill alone, doesn't always mean a browser is actually necessary (or supported). The user might've want them to control their main desktop browser; or the user might be pointing them toward a read-only HTML file that doesn't need rendering; or the sandbox might prevent network access; etc...

Codex is especially 'keen' to use Skills (especially by comparison to Claude), I often see it load Skills which it doesn't go on to use, because the main Skill content says "when not to use this". So I'm sure this is a product design decision to help with those kinds of circumstances.

Interesting, I've come to the opposite conclusion: a lack of types (or types that are only weakly enforced) costs me significantly more tokens in the long-run to maintain, and makes it far too easy for models to silently introduce bugs.

I run all my projects now in TypeScript with the strictest possible settings, including disabling `ts-ignore` markers.

(This would drive me absolutely insane, but my agents get over it pretty quickly!)

> When Claude Fable 5 declines a request, the Messages API returns stop_reason: "refusal" as a successful HTTP 200 response, not an error

This is precisely what comes to mind when I think “successful”.

Not OP, but I generally agree. Models are powerful enough now to reliably instruct other models. They don’t need fancy tools or IDEs, just the command line.

With deterministic workflows, type-safe languages and test suites, agentic loops pretty much “can’t fail”. They will continue until the types resolve, the tests pass, and the project requirements are deterministically met.

By that point it’s literally just a case of typing a prompt in to a text field, and waiting.

Skills already are "just asking the model". Unless you'd prefer to type out the same instructions every single time?

Skills are literally just Markdown documents that get loaded into context when the /skill-name is invoked.

> “To stave off some obvious comments:

> yoUr'E PRoMPTiNg IT WRoNg!

> Am I though?”

Yes. You’re complaining that Gemini “shits the bed”, despite using 2.5 Flash (not Pro), without search or reasoning.

It’s a fact that some models are smarter than others. This is a task that requires reasoning so the article is hard to take seriously when the author uses a model optimised for speed (not intelligence), and doesn’t even turn reasoning on (nor suggest they’re even aware of it being a feature).

I asked the exact prompt to ChatGPT 5 Thinking and got an excellent answer with cited sources, all of which appears to be accurate.