DEV Community: Paul Piper

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.