DEV Community: Paul Piper

My Thoughts on Jev, After the Private Beta

Paul Piper — Fri, 18 Sep 2026 08:32:07 +0000

Jev is the first model in a long while that I wanted in production the same week I tested it. It is also the first one I have to explain by what it refuses to do, because it is different.

It is not your normal llm. It does not chat. It does not write. It does not reason. What it does is something different - it judges, scores and categorizes and it does so at a fraction of the cost and incredible speed. It hands back typed values: a choice from a list, a score on a scale, or a yes/no probability. Every answer carries a confidence number. That's all.

Diogo Almeida founded TypeSafe AI with Erik Gafni and Sasha Sheng, and they came out of stealth on 15 September with $40 million led by DCVC. Almeida is ex-OpenAI, one of the people behind RLHF and InstructGPT. So it is kinda cool that they are taking this entire industry into a different direction.

I have long been a proponent of the idea that specialized tiny models at a fraction of the cost should become the industry norm. I don't always want a reasoning model arguing for minutes with itself, sometimes I just want a confident answer and Jev promises this.

Where it is genuinely fantastic

So I ran a test and replaced some of the core routines in various of my projects. Jev delivered whenever I asked it to do micro-decisions, routing, and performed as a real judge. It did better than Mistral-small or similar models, it was faster, more accurate.

The case I benchmarked hardest on was an intent gate. I often add these to my projects - they check what the user "wants to do" and then reroute accordingly to a proper model with a selection of tools. It helps keep things slim (prompts included) and reduces tokens. And I often use it to check if the user is sneakily trying to do something I don't want them to - ie, misuse my software for something.

I had close to 70 cases, and reran the script three times. Jev got every single one right in all three rounds. The median was 250 ms and on average it ran between 453 and 688 ms. Out of every model I put in that bench (I tried a few) it was the only one that never once blew the 1.5 second budget. That was what I had hoped for - accurate performance for something other models would take longer for.

The second case was a judge with no incumbent at all. One yes/no question on a slide deck, 40 slides, one call, 1.41 seconds. It caught claims in that deck that I had read past myself - Jev spotted them accurately.

Where it does not fit

I cannot talk about Jev without talking about the downsides. Like I said in the intro, Jev is not your normal llm and you should not treat it as such. It is also incapable of handling many use cases, such as:

No images. The input is always text, objects or arrays.

No prose output, which sounds obvious until you go through your own candidate list and find how many of them need one human-readable sentence at the end.

It is not OpenAI compatible, either. The api endpoint is different at the moment. Though I bet that'll get solved quickly, for now it means that you cannot swap it in as a model name in a config file, so every single use is new code. That is a real cost and it is worth knowing before you get excited.

The business model is unqiue

Lastly, I should talk about the business model. Jev costs only $0.042 per million input tokens and the Output is free, which they describe as too cheap to meter.

They named the model after William Stanley Jevons, which is not subtle and not meant to be. Jevons paradox says that making a resource cheaper raises total consumption rather than lowering it. So the pricing is not a launch discount, it is the thesis: at four cents a million tokens, you may start wondering which "micro decision" you can now actually route to an llm, when it was simply too costly before.

The transactions are tiny and so are the costs. They are in it for the long run rather than for this quarter and it gets me excited to play around with Jev some more and see if I can come up with new business models, too.

Conclusion if there is one

I think that Jev is a fantastic addition to the model space. It ventures into a region that opens up new possibilities for all of us and it gets me excited over having a new lever to pull during my implementations. Kudos to the team!

Why our slide decks are plain text files

Paul Piper — Mon, 03 Aug 2026 15:53:38 +0000

If you have ever tried to code-review a slide deck, you already know the problem this is about. Here is what we did instead, and what it cost.

Slaide keeps a slide deck in one plain-text file, so it diffs in git, reviews like code, and an agent can write it without touching a GUI.

I have written a lot of decks. Every one of them ended up as a binary sitting in a shared drive, and every one of them had the same three problems: I could not diff it, I could not review it, and I could not automate it. The fix turned out to be boring. Make the deck a text file.

What is a .slaide file?

It is Markdown for the words plus a short YAML block for the theme. That is the whole format.

theme:
  palette: ink
  font: IBM Plex Sans

# The problem
Decks are binaries.

- You cannot diff them
- You cannot review them
- You cannot generate them without a GUI

# The fix
Make the deck a text file.

That file renders to a web deck, to a PDF, and to a .pptx that opens and edits normally in PowerPoint. Same source, three outputs, no export dance in between.

Why does the source format matter so much?

Because everything you want to do with a deck downstream depends on it.

A binary deck cannot go through code review. You can attach it to a pull request, but nobody can see what changed between revision four and revision five, so nobody reviews it properly. A text deck shows up as a diff: three lines changed on the pricing slide, and the reviewer reads three lines.

A binary deck also cannot be written by an agent. This is the part that pushed me over. You cannot hand a model a .pptx and say "slide 12 is too wordy, fix it" - the model would have to drive a GUI or rewrite OOXML, and neither of those is a thing you want happening unattended. Hand it a text file and the job is ordinary text editing, which models are good at.

Slaide comes with an MCP server and an Agent Skill for exactly this. The agent reads the file, edits the file, and the renderer does the rest.

What about the PowerPoint problem?

This is the objection I get first, and it is a fair one. Nobody in a company runs on Markdown. "Send me the slides" means "send me something I can open and change".

So .pptx export is not a screenshot dump. The exported file has real text boxes, real shapes and real editable content, and someone who has never heard of Slaide can open it and move a box around. Import works the other way too: give Slaide an existing .pptx and you get the text form back.

The round-trip was the hardest part of the project by a wide margin. OOXML is not a format that wants to be written by hand, and getting a slide to survive the trip out to PowerPoint and back without drifting took far longer than the renderer did.

Here is the honest limitation: a heavily designed deck does not survive a round trip perfectly. If your slides are full of hand-placed decorative elements and bespoke animations, importing them will flatten some of that. Slaide is best when the deck is mostly content, which in practice covers most working decks and not most conference keynotes.

What is open source and what is not?

Being specific about this matters more than being generous about it.

The core is Apache-2.0 and lives at github.com/aivorynet/slaide. That includes the renderer, the CLI, the .pptx import and export, the MCP server and the Agent Skill. If you want to render decks in CI, or generate them from a script, or build something on top of the format, that is the licence you are working under and there is no lock-in: the file is text, and the exporter is open.

The WYSIWYG editor is closed source. It is free once you sign in - that changed on 28 July 2026, and it changed because charging for the editor was getting me a number on a dashboard rather than users with a deck already in the thing.

The desktop viewer is Rust with a WebView, and it spawns the renderer as a separate binary.

Who is this actually for?

Three groups, in the order they show up:

Developers who already keep everything else in git and find it strange that the deck is the one artefact that cannot be reviewed. Teams who generate decks programmatically - weekly metrics, customer reports, anything where a human assembling slides by hand is a waste of a human. And people building with agents, who want a deck as an output format that a model can actually produce.

If you make a living designing beautiful bespoke presentations, this is not aimed at you and I would not try to convince you.

How do you start?

Install the core, write a file, render it.

npm install -g slaide
slaide render deck.slaide --out deck.pptx

That is the whole loop. The web deck and the PDF come out of the same command with a different --out.

How a Spreadsheet Turned Into an LLM Inference Router

Paul Piper — Tue, 09 Jun 2026 13:29:02 +0000

Like any founder these days, my AI computing bill was horrendous. I was running open-weight models for several of my own products, and I started looking for cheaper options. Every few weeks I'd find a provider with better rates, migrate over, and then discover the prices had shifted again.

So I did what any developer would do when faced with a repetitive task: I built a spreadsheet.

It Started as a Database

The spreadsheet turned into a SQLite database pretty quickly. I started polling pricing APIs from the providers I was already using (Together, DeepInfra, Fireworks, a few others) and logging the results every few minutes. Just for my own reference, so I could see trends and decide when to switch.

A few weeks in, the data showed something I hadn't expected. The price for the exact same model, same weights, same architecture, varied wildly across providers. Not by 10-20%. By 2x, sometimes more. And the cheapest provider wasn't always the same one. It changed multiple times per day. Off-peak hours (US night, EU morning) were consistently cheaper. Some providers had stable pricing; others fluctuated hourly, creating windows where they'd drop well below their usual rates.

I was looking at this data every morning over coffee, manually deciding which provider to point my services at. That got old fast.

From Tracking to Routing

If I already had a database of live prices, why not just route requests automatically?

I wrote a proxy that sat between my applications and the inference providers. When a request came in, it looked up the current cheapest provider for that model and forwarded the request there. If that provider failed, it tried the next cheapest. My apps didn't need to know or care which backend was serving them.

I kept it OpenAI-compatible from the start because all my code already used the OpenAI SDK. Switching meant changing one line:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.aivory.net/v1",  # the only change
    api_key="your-aivory-key"
)

response = client.chat.completions.create(
    model="llama-3.3-70b",
    messages=[{"role": "user", "content": "Hello"}],
    stream=True
)

Streaming, function calling, JSON mode, retry logic. All of it works because the API contract is identical.

Then I Started Using It for Everything

Once the router was running, I pointed all my own services at it. I run a few products that use inference heavily, and within the first month my costs dropped by about 60% without changing any application code.

That was when I thought: other people have this problem too. Most teams pick a provider, integrate their SDK, and stay there. Switching means rewriting integration code, handling different auth flows, debugging streaming behavior differences. The friction of switching is what lets providers charge different rates for what is essentially the same commodity.

What the Pricing Data Actually Looks Like

Here are real numbers from our API right now. These change constantly, which is the whole point:

The model pricing dashboard. 133 models across vendors like Anthropic, DeepSeek, Google, Meta, and Qwen, each with live per-token pricing.

DeepSeek V3.2 (13 provider endpoints tracked):

	Input (per 1M tokens)	Output (per 1M tokens)
Cheapest	$0.46	$0.83
Mid-range	$0.49	$1.13
Most expensive	$0.54	$1.38

Llama 3.3 70B (4 provider endpoints):

	Input (per 1M tokens)	Output (per 1M tokens)
Cheapest	$0.38	$0.51
Mid-range	$0.40	$0.56
Most expensive	$0.92	$0.92

Qwen 3 235B (6 provider endpoints):

	Input (per 1M tokens)	Output (per 1M tokens)
Cheapest	$0.35	$0.40
Mid-range	$0.42	$1.68
Most expensive	$0.48	$3.15

That last one is wild. The output price for Qwen 3 235B varies almost 8x across providers. And these are all serving the same model weights.

The Same Problem, but for GPUs

The entire endavour got me thinking about the other costs at large. Inference points aren't that common, still, but GPUs can be booked anywhere. So I checked if I could do the same manual price comparison there and upgraded my layer for GPU spot pricing.

The GPU spot marketplace. 37 GPU types across 9 providers, sorted by price. Top picks: H200 at $0.60/hr, H100 at $1.30/hr. Biggest savings: V100 at $0.07/hr.

The spreads are just as big as with inference pricing - if not even larger. An A100 80GB ranges from $0.71/hr to $2.48/hr right now, a 3.5x spread. H100s go from $1.30/hr to $7.38/hr. V100s range from $0.07/hr to $0.95/hr, a 13x spread.

Each GPU shows the price range across providers, availability status, and number of competing offers. Deploy in one click.

The marketplace tracks various gpu types across a growing list of providers right now. Per-second billing, auto-shutdown on idle, and you can set a max price so you don't get surprised.

So where's the downside?

Well, I can only think of one: Routing adds latency. Not much, but perhaps not something for everybody. However, for most interactive sessions it is probably negligible.

Also: We're open-weight only. No GPT, Claude, or Gemini. But probably okay - realistically, it is what you probably rely on for most of your actual applications anyway.

But apart from that, there is another upside - provider outages work differently with a router. If your single provider goes down, you're down. With a router, you're only down if all providers go down at the same time, which is much rarer. That turned out to be a nice side effect.

Why This Market Looks Like Early Cloud Computing

What I find genuinely interesting about all of this is that inference pricing in 2026 looks a lot like cloud computing did in 2010. Dozens of providers, no price transparency, wildly different rates for identical hardware. The only reason providers can charge 2-8x more than their competitors is because nobody is comparing in real-time.

Spot pricing for GPUs follows the same dynamics as spot instances on AWS. Providers would rather sell unused capacity at a discount than let it sit idle. But unlike AWS, where everyone knows the spot market exists, most people renting GPUs for ML workloads are still paying on-demand rates from a single provider they picked months ago.

I keep expecting the spreads to compress as the market matures, but so far the opposite has happened. New providers enter, existing ones experiment with pricing, and the range just gets wider. Maybe it'll consolidate eventually. But as long as providers are competing for utilization on hardware that depreciates fast, there's going to be a gap between whoever's desperate to fill capacity right now and whoever isn't.

If you want to check out what I built from all of this, give it a go at aivory.net/smart-inference and reach out to me for feedback.