DEV Community: Jonathan Murray

Jev by TypeSafe on Backboard.io

Jonathan Murray — Thu, 17 Sep 2026 22:54:50 +0000

No fancy long posts here, just cold hard facts. The viral model Jev, is now on backboard:

HUGE ANNOUNCEMENT: Backboard.io now supports TypeSafe Jev — System One Models

• Added Jev support for structured decisions: Choice, Score, and Noul (true/false probability).
• Use the existing message API with llm_provider="typesafe" and system_one.questions.
• Evaluate text or structured data, with conversation history included.
• Receive typed answers, probabilities, confidence where supported, and token usage.
• Added Python and TypeScript SDK support; Python SDK v1.5.19 is available on PyPI.
• Published Core Concepts and SDK guides with examples and complete response documentation.
Supported models: jev-latest.

docs
• https://docs.backboard.io/sdk/system-one
• https://docs.backboard.io/concepts/system-one

Make a Runway Clone in one shot, or something else!

Jonathan Murray — Thu, 17 Sep 2026 17:20:20 +0000

i'm jon, i co-founded backboard.io. this is a launch post. it's short and there's code.

video models are live on backboard.

Here is a video of me and my dog rapping if you don't believe me.

ByteDance's Seedance family is in, served through OpenRouter, along with the rest of the OpenRouter video catalog.

that's the news. here's why you should care.

video is the worst part of the stack to glue

text you've figured out. images, mostly. video is where it gets ugly.

every provider has its own job api. submit. get an id. poll. poll again. time out. retry. download the file. store it somewhere. pass a url back to your agent. hope the agent remembers what it made two turns ago.

that's a whole service. for one feature. and it's different for every model.

so we built it once. same way we did memory, rag, routing, voice and image.

what's live

ByteDance Seedance

bytedance/seedance-2.5 (up to 30s, with audio)
bytedance/seedance-2.0
bytedance/seedance-2.0-fast
bytedance/seedance-2.0-mini
the rest of the OpenRouter video catalog
Veo 3.1, Wan 3.0, Kling 3.0, Hailuo 3, Grok Imagine and more
client.list_video_models() shows exactly what's live and what each model supports. client.get_video_model(model_id) gives you one model's limits.
six ways in:
text to video
first frame to video (animate an image)
first and last frame
video to video (edit, extend, upscale)
references (images, audio or video as a guide)
mixed references

the code

it's the add_message call you already make. four extra keys.

import asyncio
import os
from backboard import BackboardClient

settings = {
    "llm_provider": "openai",
    "model_name": "gpt-4.1",
    "video_generation": "auto",
    "video_model_provider": "openrouter",
    "video_model_name": "bytedance/seedance-2.0-fast",
    "video_config": {"duration": 5, "aspect_ratio": "16:9", "resolution": "720p"},
}

async def main():
    client = BackboardClient(api_key=os.environ["BACKBOARD_API_KEY"], timeout=1900)
    assistant = await client.create_assistant(name="video assistant")
    thread = await client.create_thread(assistant.assistant_id)
    thread_id = str(thread.thread_id)

    result = await client.add_message(
        thread_id,
        content="a paper boat drifting down a rainy city gutter, golden hour",
        stream=False,
        **settings,
    )

    for message in result.messages:
        for media in message.get("generated_media") or []:
            print(media["document_id"], media["url"])

asyncio.run(main())

no job queue. no polling loop. we poll for you, for up to 30 minutes, and hand back the clip.

every clip comes back in generated_media with a document_id and a url. it lives in the thread. next to the memory. next to everything else your agent already knows.

want to animate an image instead? add a file.

result = await client.add_message(
    thread_id,
    content="slow push in, steam rising off the coffee",
    files=["start.png"],
    stream=False,
    **settings,
)

two files is first frame plus last frame. an .mp4 is video to video.

the part that matters: it's a thread

the clip isn't a loose file. it's in the conversation. so the next turn can just be:

await client.add_message(
    thread_id,
    content="same shot, but at night. neon reflections in the water.",
    stream=False,
    **settings,
)

no re-uploading. no passing urls around. the agent knows what it made, because it made it in the same thread.

stuff worth knowing

the model decides. video_generation="auto" hands your assistant a generate_video tool. it calls it when the ask needs a video. it won't render one because you said hi.
the chat model and the video model are picked separately. reason with one, render with another.
pass the video settings on every turn, follow-ups included. that's the one gotcha.
video takes minutes. use stream=True and a long client timeout. we use 1900 seconds.
a client timeout doesn't cancel the job upstream. don't auto-retry, or you'll render it twice.
video_config covers duration, resolution, aspect ratio, size, audio, seed, upscale and provider routing. only where the model supports it. check get_video_model() first.
frames have to be images. a last frame needs a first frame. don't mix frames with a source video or references.
you're billed the actual cost the provider returns. not an estimate. job ids and costs sit in thread metadata if you need to audit.
don't need a thread? there's a stateless path too, operation="generate_video". docs here ## the actual point

swap bytedance/seedance-2.0-fast for google/veo-3.1-fast. one string. nothing else moves.

that's the whole backboard thing. the model is a parameter. text, voice, image and now video, behind one key, with memory under all of it. so your agent doesn't forget what it just made.

you were going to write that polling loop this weekend. don't.

get a key: app.backboard.io
video docs: docs.backboard.io/sdk/video-tool

OpenAI can't rule out that it stole its most recent breakthrough

Jonathan Murray — Tue, 08 Sep 2026 20:51:56 +0000

A mathematician spent a year on one of the hardest open problems in math. He asked OpenAI a simple question. Did you train on my sessions? Today they answered. Sort of.

Here is what happened.

The setup

Tristan Buckmaster is a math professor at NYU. He and Levent Alpöge spent most of the past year attacking finite-time blowup for fluid equations, the family of problems that includes the Navier-Stokes Millennium Prize. They worked with LLMs the whole way. Claude, Codex, GPT-5.6 Sol, Astra. By August 15 they had blowup results for Boussinesq and 3D Euler. By August 22 they had a proof verified in Lean.

Every draft of the project went through Codex. His words, from his statement: "our sessions in Codex, into which we had been putting all our drafts for the whole of this project."

The call

September 3. Rumors start moving. Buckmaster emails his contact at OpenAI to ask what's going on. Within days he's on a call with Sébastien Bubeck. He's told an internal OpenAI model has produced a proof of finite-time blowup for forced Navier-Stokes. About 100 pages. Same smooth-forcing setup he and Alpöge had quietly chosen.

He asks when the first prompt was sent. It takes a while to get an answer. Eventually it's agreed: in the past few days, after information about their work had reached OpenAI.

Then he asks the real question. Was the model trained on, or did it have access to, their Codex sessions?

He's told the model did not look up user data.

He asks again. About training specifically.

No answer.

That was the state of things when he went public last night. Alongside it: two proposals to coordinate release, a request to drop Alpöge from authorship because Alpöge works at Anthropic, and a line he quotes directly: "If you don't want me to be nice, then I don't have to be nice." OpenAI's first response called the allegations "false and inflammatory." Bubeck has since called the career remark "ill-chosen" and retracted it.

The answer

Today OpenAI posted a statement. Read this part slowly.

"While unlikely, we cannot rule out that de-identified data derived from their usage of our products helped improve our models."

That is the training question. Answered.

Not "we did not train on it." Not "their sessions were excluded." They cannot rule it out. A year of unpublished work on a Millennium Prize problem, and the company whose model produced the result cannot rule out that the work was in the training set.

Notice how carefully the statement is built. It says no specific user data was "accessed." That's a retrieval claim. It says the researchers and agents did not "see" the work. That's a visibility claim. Training is a third thing, and on training the answer is a shrug.

They also say the proofs differ significantly and the Euler results are different, forced versus unforced. Maybe so. Nobody outside OpenAI has seen their proof yet, including Buckmaster. That part will get sorted out by mathematicians.

Why this matters to you

You don't have a Millennium Prize problem in your Codex history. You have your codebase. Your architecture decisions. The thing you've been building for eight months that isn't public yet.

Consumer Codex sessions are training data by default. That is not a leak. That is the product. Buckmaster's drafts were "de-identified data derived from usage." So are yours.

The lesson isn't that OpenAI did something exotic here. It's that the default did exactly what the default does, and for once it happened to someone whose work was important enough that the question got asked out loud, and answered in writing.

"We cannot rule it out" is the honest answer. It's also the only answer they can give. Think about what that means for everything you've ever pasted in.

Sources: Buckmaster's statement, the OpenAI statement, TechCrunch, Fortune, The Decoder, OpenAI data policy.

There Are Only Two Ways to Make Money in Software.

Jonathan Murray — Sat, 05 Sep 2026 17:09:06 +0000

my team builds AI infrastructure, so yes, i have a horse in this race. the horse shows up at the end, clearly labeled. the history comes first, and the history is free.

jim barksdale, back when he ran netscape, said the only two ways to make money in software are bundling and unbundling.

people quote it like a joke. it's not a joke. it's the whole industry in one sentence, and it explains exactly what happened to your sprint board.

Jim Barksdale TED Talk - The Power of Networks

the cycle, in 90 seconds

microsoft bundled office. google unbundled it into free web apps. then it bundled them back into workspace.

cable bundled channels. netflix unbundled them. now netflix has ads, tiers, and live sports. that's a cable bundle with a different logo.

craigslist was one bundle. airbnb, zillow, indeed, tinder each took one row. then each of them started bundling again: payments, insurance, messaging, verification.

aws unbundled the data center into 200 services. snowflake and databricks bundled the useful ones back together and got carried by the very clouds they sit on top of.

same shape every time. someone unbundles to win on choice and price. the seams between the pieces start costing more than the pieces. someone bundles so nobody has to touch the seams again. repeat.

the part people miss: in every one of those cycles, there's a stretch in the middle where the user is the one holding the seams. that stretch is miserable and it always ends the same way. somebody does the bundling for you.

AI skipped a step

here's what's weird about AI. it unbundled before it ever bundled.

there was never an office moment. no single integrated product everyone used and then got picked apart. the stack arrived pre-shattered.

a model provider. a second model provider for when the first one is down or expensive. a vector database. an embeddings provider. a memory service. a rag framework. an orchestration layer. observability. a gateway to route between all of it.

that's eight or nine vendors for one app. i've counted this before and it still bothers me. nobody designed it. it accreted, one sprint and one free tier at a time.

every one of those vendors is a great unbundler. best vector database. best memory. best router. each one wins its row.

nobody owns the seams. you do. and the seams are where all the work is.

the seams are where your time goes

be honest about what you spent last quarter on.

not on the agent. on the glue. the retry logic between the gateway and the model. the schema translation between the rag framework and the vector db. the memory that's written in one place and read from another and never quite agrees with itself. state living in three systems with three retention policies.

then a better model ships and you do it all again, because the glue was written for the old one.

this is the unbundled tax. it's the same tax people paid stitching an email client, a calendar, a doc editor, and a file store together before workspace existed. everyone paid it, everyone hated it, and it felt normal because everyone was paying it.

and here's the thing about the tax. it's not your job. nobody hired you to integrate vendors. they hired you to ship the agent. the glue is the work you do instead of the work you were hired for.

you are in the miserable middle

look at any of the cycles above. the middle stretch, where users hold the seams, lasts exactly as long as it takes for someone to bundle it back. then it's over and nobody misses it. nobody is nostalgic for configuring imap.

AI is in that stretch right now. the difference is that this time the stretch has been unusually long, because the parts kept changing under everyone's feet and nobody could sit still long enough to assemble them.

we sat still. that's the horse.

the horse, as promised

we built backboard so you don't have to bundle anything. the bundling is done.

one api, one key: memory (first on the LoCoMo and LongMemEval benchmarks, receipts on github), routing across 17,000+ models, agentic hybrid rag, and stateful threads. not four services with one invoice. one system where memory, retrieval, routing, and state already share state, so there's nothing to translate between them and no glue to write.

the model is a parameter you pass. when a better one ships, you change a string. you don't re-platform.

it runs where you already build. native in backboard studio and in R-CLI, our open-source coding harness (MIT, highest publicly reported score on terminal bench 2.1 at 84.3%, above every published result). same key and same memory from cursor, claude code, or vs code if that's your setup. no migration.

pip install backboard-sdk, one key, and the eight-vendor diagram becomes one box. free tier is $5 in memory credits, no card.

and now the half of the bundle nobody talks about.

backboard is available on AWS marketplace. that sentence is boring until you know what it does for you. it means your company buys the bundled stack through the cloud bill it already pays, with committed AWS spend it already negotiated, deployed inside its own AWS account. no new vendor onboarding. no ninth security review. no six-week procurement thread where you defend a vector database to someone in finance. the same reason snowflake and databricks get carried by the clouds applies here: a bundled stack is easier to buy through the cloud than through a procurement process, and it's easier to get approved because there's one thing to approve.

so both seams are gone. the technical one, where you wrote glue. and the purchasing one, where you wrote justifications. we did both so you can go back to shipping the agent.

the objection

"a bundle is lock-in with better marketing."

fair. it was true for cable and it's true for most suites. two answers.

first, the exit is real. memory is exportable through crud endpoints. routing is model-agnostic. byok means we never hold your provider keys. you can leave, which is the only honest answer to lock-in, and it's why people stay.

second, the compute is never ours. you pay your cloud directly. we don't resell it at a markup, which is where most bundles quietly make their margin and where most bundle resentment comes from.

the whole post in four lines

software alternates between bundling and unbundling, and in the middle the user holds the seams.

AI unbundled before it ever bundled. you're holding the seams. that's why your sprint board is glue.

the re-bundle is done. memory, retrieval, routing, and state behind one key, the model as a parameter.

and it's on the cloud bill you already pay, so the last seam, getting it approved, is gone too.

go get a key at backboard.io and delete some glue this week.

Comment if you want a promo code for some dev credits.

I Watched Our Interns Play Valorant for Three Hours. Put Your Rank on the Resume.

Jonathan Murray — Sat, 05 Sep 2026 13:49:09 +0000

Last week of summer with our interns we skipped the goodbye lunch and booked an esports arena. Split them into teams. Valorant. Best of whatever until the room kicked us out.

I run go to market at a startup. I have sat through a lot of team exercises. Trust falls. Escape rooms. A guy with a flip chart. None of them came close to what I watched for three hours in that room.

The quiet ones were calling rotations. The loud ones shut up and listened. Someone who had never touched the game was getting coached mid round by someone who was clearly very good and clearly not making a thing of it. Lose a round, thirty seconds of "ok what happened," next round. Nobody sulked. Nobody quit. The room got louder every map.

Then I went home and thought about which of those people ship the thing at 2am and fix the demo at 8am. Same people. And almost none of them had ever mentioned they played. Not in the interview. Not on the resume. Not once.

So this one is for you. The one who peaked Diamond, or Immortal, or Radiant, and wrote "strong communicator" on the resume instead.

You are underselling the most relevant thing you have ever done.

the ladder does not care about your story

A resume is a story you tell about yourself. Your rank is a number the world assigned to you.

You could not network your way there. You could not talk your way through a placement match. Every game was a fresh evaluation against people trying to end you, and the rating moved whether you liked the result or not.

That is what working at a startup is. The market does not read the pitch. It uses the product or it does not. You already know how to live inside a number you cannot argue with. Most people your age have never had to.

you lose four out of ten and queue again

A 60% win rate at high rank is elite. Read that again. You lost four games out of ten, closed the scoreboard, and queued.

Do you know how rare that is? Most people lose twice, tilt, blame the team, and go do something else with their evening. You built a loop instead. Lose. Watch it back. Fix one thing. Next one at full intensity. No sulking. No speech.

That is a startup week. Demo breaks. Deal slips. Benchmark run dies at 3am. Queue again. You have done this loop ten thousand times. You just did it with a crosshair.

your comms are already better than the senior dev's

"Two A short. One low. Rotating." Nobody gives a TED talk in a clutch round. Nobody goes quiet either.

Now think about the worst standup you have ever sat in. Someone spends eleven minutes explaining why the thing broke. Someone else says nothing and then it turns out they were blocked all week.

An eighteen person company is a five stack in a clutch round every day. Short, precise, useful updates are the whole job. You have years of reps on this. You got them for free. You just never thought of it as a skill.

you fill

What do you main? Now what do you play when the comp needs something else?

If you are any good, you fill. You controller when the duelist instalocks. You IGL when the IGL is missing. You hate it a little and you do it anyway, because the point is winning, not your slot.

At a startup "not my job" is a firing offence. The person who goes backend to demo prep to support tickets in one afternoon is the person the company gets built around. You have been that person since Silver. Fillers build companies. Instalockers build politics.

you already watch your own tape

You watch your losses. Not the highlights. The losses. Where was my crosshair. Why did I peek that. What did I know in that moment and what did I ignore.

Postmortems are a religion in esports and a suggestion in most companies. An engineer who reviews their own failures without a manager standing over them gets better with zero supervision. There is no supervision at a startup. That is the entire game. You have been playing it for years.

the grind is the resume

Silver to Immortal is not talent. It is a thousand hours of deliberate discomfort. Two hundred dry runs of the same lineup. Deathmatch at midnight because your flick was off.

That is the exact texture of building something from nothing. Boring, repetitive, unglamorous, at full intensity, because you believe the number goes up eventually.

You have done it once. So you know you can do it again. The person next to you in the interview with the nicer school and the cleaner resume does not know that about themselves yet. That is the gap. That is your edge. And you left it off the page.

what to actually do

Put it on. Peak rank, game, how long it took. One line.

When they ask about it, and they will, do not get sheepish. Tell them what it cost. Tell them where you plateaued and why. Tell them what role you ended up playing versus the one you wanted. That answer is worth more than any project on your GitHub, and it is the one answer nobody else in the pile can fake.

Some hiring managers will screen you out for it. Good. You did not want to work there. The ones who light up are the ones who will actually let you play.

so we are running a league

Backboard Valorant League. University teams, the whole school year, two games a week on Twitch, finals in Toronto in the spring.

Partly because three hours in that arena did more for our team than any offsite I have run. Mostly because the people who show up for something like this are exactly the people every startup should be fighting over, and I would like to meet you before someone else does.

If you are on a university team, comment below. Rank is not a requirement. Showing up is.

I co-founded Backboard. A lot of the team plays. It shows. We're going to start a Valorant league.

The Matrix Wasn't A Battery Farm. It Was A GPU Cluster Made Of Human Brains.

Jonathan Murray — Fri, 28 Aug 2026 15:25:20 +0000

Nvidia is worth more than most countries because we cannot figure out how to do cheap inference.

There are eight billion units walking around that do it on 20 watts.

I rewatched The Matrix recently and got stuck on the same thing everyone gets stuck on. Batteries.

Morpheus holds up a Duracell and tells Neo the machines are farming humans for electricity. Bio-electricity, body heat, 25,000 BTUs, the whole speech. It's a great scene. It's also thermodynamic nonsense. You are feeding these people liquefied protein slurry. If you want energy out of the slurry, burn the slurry. Skip the human. The human is a lossy middleman with opinions.

So the machines built a planet-sized data center, wired up billions of pods, wrote an entire simulated 1999 with weather and taxes and dial-up internet, all to run a power plant that loses money on every unit.

No. They were not running a power plant.

They were running inference.

The 20 watt problem

Your brain runs on about 20 watts. That is a dim light bulb. That is less than the charger for the laptop I am typing this on.

For 20 watts you get real-time vision, real-time audio, language, motor control, a continuously updated physics model of your surroundings, and a persistent world model that predicts what happens next well enough that you can catch a set of keys someone throws at you without thinking about it.

Now price that in silicon. Go look at what a rack costs to do a worse version of any one of those things. We are building gigawatt campuses and negotiating with power utilities like nation states. Meanwhile the reference implementation has been running on leftover sandwich for two hundred thousand years.

So here is what I was thinking about on my drive in, and I am not the first person to land on it, but it fixes the movie completely:

The machines were not harvesting energy. They were harvesting compute.

Why this makes the plot better

If you want electricity, you want the human sedated. Flat. Minimal metabolic overhead. You do not need to simulate an office job for a battery.

But if you want compute, you need the opposite. You need the brain engaged. Loaded. Running a rich model of a coherent world with stakes and consequences and other agents in it.

Which is exactly what the Matrix is.

The simulation stops being a pacifier and becomes the workload. Every human in a pod is a node processing an unimaginably detailed world model, and the machines are skimming the output. The reason the first version of the Matrix failed, the one Agent Smith says was a perfect world, is not that humans need suffering to feel real. It is that a frictionless world is a trivial workload. Nobody's brain does anything interesting in paradise. They cranked the difficulty up to keep utilization high.

They were not keeping us asleep. They were keeping us busy.

The machines built the world's largest GPU cluster and the cooling solution was a lie about 1999.

And then I looked up whether anyone was doing this

Full disclosure on how this post came to exist, because I think the process is half the story.

I did not sit down already knowing any of this. I started with a dumb question about a 27 year old movie, said it out loud to an AI, and then spent forty minutes arguing with it. I floated the compute idea. It pushed back on the parts that were wrong and handed me the parts I did not know existed. I asked follow-ups I would never have known to ask a search engine, because I did not have the vocabulary yet. Organoid intelligence. Neuromorphic. Dendritic computation. I did not walk in with those words.

We landed on the compute theory together. I cannot cleanly tell you which half was mine.

That is a genuinely new way to learn a subject and I am not sure we have all noticed. Anyway, verify everything below yourself, because I did, and you should.

This is where it stopped being a fun shower thought and got a little weird.

There is a Swiss outfit called FinalSpark that runs lab-grown human brain organoids as a cloud platform. You can rent time on them. Over the internet. Actual living neural tissue, sitting on electrodes, available as a service.

There is Cortical Labs in Melbourne, who taught a dish of neurons to play Pong and then productized it. You can buy the unit.

The pitch in both cases is the pitch I just made. Orders of magnitude less power than silicon for certain kinds of learning.

The catches are real. The organoids live weeks, maybe months. Nobody has figured out how to program them in any way you would recognize as programming. And neurons are slow, milliseconds per spike against nanoseconds for a transistor, so this was never going to be a drop-in replacement for an H100. Different machine, different job.

There is also the question everyone in the field is politely circling, which is at what point a dish of neurons doing useful work starts to matter morally. FinalSpark's own scientists have said out loud that they think about this. I do not have an answer and I am suspicious of anyone who says they do.

To be clear, I am not advocating for any of this. I want to be on record before someone quotes me in a deposition in 2041.

The version that probably actually happens

The boring answer is neuromorphic silicon. Loihi, NorthPole, SpiNNaker. Steal the architecture from biology, spiking neurons, memory sitting next to compute instead of across a bus, absurd parallelism. Then implement it in silicon so you get nanoseconds instead of milliseconds. Copy the design, drop the latency, skip the ethics review.

We are already using AI to help design those chips, which is its own recursive little snake eating its tail.

The open question is whether the architecture is the secret or whether the secret is somewhere in the wet chemistry. The neuromodulators, the dendritic computation, all the analog mess that does not draw cleanly on a whiteboard. It is possible we are copying the blueprint and missing the trick.

Anyway. Next time someone tells you AI is a power problem, remember there is a 20 watt reference design walking around inside your skull, and it has never once needed a substation.

Sleep well, and have a nice weekend.

I Counted the Attack Vectors in Our AI Stack and Now I Can't Sleep

Jonathan Murray — Wed, 26 Aug 2026 17:29:30 +0000

so a while back i did something i do not recommend before bed.

i counted the vendors in a normal production AI stack. not a weird stack. not a bad team's stack. the stack everyone builds, the one in every architecture diagram on this site.

model gateway. vector database. memory service. rag framework. embeddings provider. orchestration. observability. two or three model providers.

that's eight. for one app.

and here's the first thing that got me: nobody approved that stack. not one person at any company, ever, sat down and said "yes, eight vendors, sounds right." it got approved one sprint at a time. a ticket here, a free tier there, a "we'll swap it later" that became load-bearing.

your architecture wasn't designed. it accreted. like a reef. or plaque.

the fun part: what each one actually is

security people have a phrase, "attack surface," and it sounds abstract until you translate each vendor into what it really is:

a model gateway is a standing API key in your CI. a vector database is a second copy of your data. a memory vendor is your prompts in someone else's logs. a rag framework is somebody's SDK running inside your process. observability is prompt logs leaving your network as the product working correctly.

read that last one again. the exfiltration is the feature. you pay for it monthly.

quick quiz you will fail

open two lists. one: every AI line item in your billing. two: every AI-related package in your lockfiles.

do they match?

they never match. i've asked a lot of teams. the answer is always no, and everyone laughs, and it's the nervous kind of laugh, because the gap between those two lists is software that touches your customer data and appears in exactly zero of your security reviews.

the gap is the attack surface. congratulations, you just did a security audit with grep.

"embeddings are just numbers though"

this is my favorite myth in all of AI, because it's so comforting and so wrong.

the theory: we embedded the text, so now it's a vector, vectors are anonymous math, we're fine.

the practice: embedding inversion is published research. morris et al. (2023, "text embeddings reveal (almost) as much as text") reconstructed the exact input text from its embedding 92% of the time for short inputs. not "similar vibes." the actual text.

so your vector database is not a bag of anonymous numbers. it's a second, queryable database of your source data, with its own API key, sitting in someone else's cloud.

now the aha that hurts: go ask whoever maintains your data inventory whether the vector store is on it.

it's not on it. it's never on it. you have a database of customer data that your own compliance team doesn't know exists, and you built it on purpose, with a jira ticket.

deletion theater

follow one user message through the stack. it hits the gateway (logged). gets embedded (copy two, the vector db). the memory service persists it (copy three). observability captures the full trace (copy four).

one message. four systems. four retention policies you've never read.

now legal walks over: "customer invoked their right to erasure, delete their data."

you cannot do that. what you can do is file four vendor tickets and hope. under gdpr this is the difference between "we called the delete endpoint and logged the result" and "we asked four companies nicely." one of those survives an audit. guess which one you have.

i call this deletion theater. everyone has a retention policy. almost nobody has a delete button that actually reaches all four copies.

deletion you can't prove is deletion you don't have. put it on a poster.

meanwhile, your dependencies

your rag framework is not one dependency. it's a tree. hundreds of packages, written by strangers, pinned loosely, executing in the same process that holds your database credentials.

this isn't hypothetical doom. langchain shipped a remote code execution bug in its math chain (CVE-2023-29374). pytorch's nightly build got hit by dependency confusion in 2022. owasp made supply chain a whole category in its LLM top 10 because this keeps happening.

the framework's security posture is your security posture. you married it. you just didn't have a ceremony.

and the stack you didn't even choose

everything above is the stack you deployed on purpose. there's another one.

it's your employees pasting contracts, code, and customer records into whatever consumer chatbot they like, on their personal accounts, right now, while you read this.

your company probably "banned" this. here's the aha: the ban is working as a compliance document and failing as a control. people don't stop using tools that make them faster. they stop telling you.

the only fix i've seen work is replacement, not prohibition. one sanctioned surface, the models people actually want, behind sso, logged. you can't firewall your way out of shadow AI. you can only out-compete it.

so what do you actually do

the counterintuitive answer, and the whole point: the fix is not more security. it's less stack.

every security tool you bolt onto an eight-vendor sprawl is a ninth vendor. the arithmetic only moves in one direction: fewer systems holding data, fewer standing keys, fewer egress paths. concretely, in priority order:

fewer copies. every system holding prompts or embeddings is a copy. count them, then make the number smaller.
one egress door. all model traffic through one brokered path where policy lives. no SDK in app code dialing providers directly.
one control plane, your keys. one place to rotate, one audit trail that answers "which model saw which data." byok, so consolidating the plane never means handing over the keys.
deletion as an api call. if you can't prove deletion programmatically across every copy, see poster above. you can build all of this yourself with enough glue code and discipline. some teams genuinely do. it's a lot of glue.

the horse, as promised

this counting exercise is roughly why backboard exists. routing across 17,000+ models, memory (first on the LoCoMo and LongMemEval benchmarks, receipts on github), embeddings, rag, and stateful threads behind one api and one key. for enterprises it ships as a signed container inside your own cloud, behind the IAM and SOC and audit trail you already trust. egress to outside models is opt-in per workload, never standing. deletion is an endpoint, not a ticket.

the objection i get, and it's a fair one: "congrats, you built a single point of compromise." three answers. byok means the platform never holds your keys, so consolidating the control plane isn't consolidating the credentials. in the enterprise deployment the one door is your door, inside your perimeter. and memory is exportable and routing is model-agnostic, so the exit is always open, which is the only honest answer to lock-in.

also, you'll notice zero certification badges in this post. on purpose. we publish nothing we haven't earned. ask for the architecture, not the badge.

the whole post in four lines

eight vendors is eight keys, eight egress paths, eight retention policies, and eight reviews your security team owes.

your embeddings are your data. your vector db is a database. put it on the map.

deletion you can't prove is deletion you don't have.

and the fix is not more security. it's less stack.

if you want to tear this apart, the code is at github.com/Backboard-io and my dms are open. i counted. your turn.

Every Layer of Your AI Stack Is an Attack Vector. Count Them.

Jonathan Murray — Wed, 26 Aug 2026 17:17:03 +0000

From the team at Backboard.io. We build AI infrastructure, so we have a position here. We state it at the end, clearly labeled. Everything before that is just counting.

TL;DR

A typical production AI application runs on 6 to 9 separate vendors: a model gateway, a vector database, a memory service, a RAG framework, an embedding provider, an orchestration layer, an observability tool, and 2 to 3 model providers. Each vendor adds at least five things to your attack surface: a standing API key, an egress path out of your network, an SDK executing inside your runtime, a log store that fills up with prompts, and a subprocessor on your data processing agreement. Most teams never approved this stack as a whole. They approved it one sprint at a time. This post is about how to count what you have actually deployed, and what reducing it looks like.

What is an AI attack surface?

An AI attack surface is the sum of every point where an attacker could reach the data, credentials, or compute involved in your AI workloads. For a modern LLM application it has three parts: the model layer (the providers your prompts travel to), the data layer (every system that stores prompts, embeddings, memories, or retrieved documents), and the integration layer (every SDK, framework, and glue service with credentials to the other two).

The mistake most teams make is measuring only the first part. The model provider gets a security review. The seven services wrapped around it usually do not.

The stack you actually deployed

Here is the stack a typical team assembles for one production agent, and what each layer costs you in security terms.

Layer	What it does	What it adds to your attack surface
Model gateway	Routes requests to providers	A standing key in CI, often with org-wide scope
Vector database	Stores embeddings for retrieval	A second queryable copy of your source data
Memory service	Persists user and agent state	Your prompts in someone else's logs, under their retention policy
RAG framework	Chunking, retrieval, prompt assembly	A large SDK and its dependency tree executing in your runtime
Embedding provider	Turns text into vectors	Separate billing, separate breach notification clock
Orchestration	Chains tools and agents	Glue code holding credentials for everything else
Observability	Traces and evaluates LLM calls	Prompt and completion logs leaving your boundary by design
Model providers (2 to 3)	Inference	Standing egress to each, each with its own retention terms

Now multiply. Eight vendors means roughly eight API keys with their own rotation stories, eight egress destinations your firewall must allow, eight vendor security reviews (or eight reviews skipped), eight subprocessors added to your DPA, eight breach notification clocks that can start ticking independently, and eight dependency trees whose CVE feeds someone on your team should be watching.

None of these vendors is careless. That is not the point. The point is arithmetic: every additional system that holds a copy of your data or a credential to your systems is surface, no matter how well run it is.

Why vector databases are the layer nobody reviews

Vector databases deserve their own section because they carry the most misunderstood risk in the stack.

The common assumption is that embeddings are safe because they are "just numbers." The vector is treated as a one-way hash of the text. It is not. Embedding inversion is a published, reproducible attack class: Morris et al. (2023, "Text Embeddings Reveal (Almost) As Much As Text") demonstrated iterative reconstruction that exactly recovers 92% of short text inputs from their embeddings, and Song and Raghunathan (2020) showed embeddings leak both content and authorship. If your source text was sensitive, treat the vectors as sensitive. Full stop.

That reframes what a vector database is: a second, queryable copy of your source data, sitting in a different trust boundary, usually with its own API key, and frequently excluded from the data inventory your compliance team maintains.

Three questions to ask about yours today:

Access: does the vector DB key in your app config have read access to every namespace, or is it scoped per workload?
Inventory: does your data map list the vector store as a location where customer data lives? (If a regulator asks, "just numbers" is not an answer.)
Deletion: when a customer invokes their right to erasure, does your pipeline delete the embeddings, or only the source rows? That third question is where most stacks fail, which brings us to the multiplication problem.

The deletion problem: one prompt, four retention policies

Follow one user message through a stitched stack. It lands in the gateway's request log. It is embedded, so a derivative lands in the vector database. The memory service persists a version of it. The observability tool captures the full trace, prompt and completion included.

That is one piece of customer data in four systems, under four retention policies, behind four vendor APIs with four different deletion semantics. When legal asks you to delete a specific user's data, you cannot execute that. You can file four tickets and ask nicely. Under GDPR Article 17 and similar regimes, "we asked our subprocessors" is a much weaker position than "we called the delete endpoint and logged the result."

Deletion you cannot prove is deletion you do not have.

The supply chain you inherited

The integration layer has its own history. LangChain shipped a remote code execution vulnerability in its math chain (CVE-2023-29374). The PyTorch nightly build was compromised through dependency confusion in December 2022. The OWASP Top 10 for LLM Applications lists supply chain vulnerabilities as a category precisely because the AI ecosystem moves fast and pins loosely.

Every framework you add is not one dependency. It is a tree. When your RAG framework has hundreds of transitive dependencies and executes in the same process that holds your database credentials, the framework's security posture is your security posture.

Shadow AI: the surface you did not approve at all

Everything above covers the stack you chose. There is also the stack you did not: employees pasting source code, contracts, and customer records into whatever consumer chatbot they prefer. Bans do not work; the incentive to use these tools is too strong. The pattern that does work is replacement: give people one sanctioned surface with access to the models they want, behind SSO, governed and logged. You cannot firewall your way out of shadow AI. You can only out-compete it.

How do you actually reduce an AI attack surface?

Vendor-neutral answer first. Four principles, in priority order:

Minimize copies. Every system that holds prompts, embeddings, or memories is a copy. Fewer systems holding data beats more systems holding it well.
Broker all egress. Model traffic should leave through one controlled point where you can enforce policy per workload, not through N SDKs each dialing their own provider.
Consolidate the control plane, keep the keys. One place to rotate credentials, one audit trail answering "which model saw which data," with keys that remain yours (BYOK).
Make deletion an API call. If you cannot demonstrate deletion across every copy programmatically, your retention policy is a hope, not a control. You can implement all four yourself with enough glue code and discipline. Some teams do.

Where we stand (the disclosed bias)

Backboard is the consolidated version of that stack: routing across 17,000+ models, memory (ranked first on the LoCoMo and LongMemEval benchmarks, receipts on GitHub), embeddings, agentic hybrid RAG, and stateful threads behind one API and one key. Enterprise deployments run as a signed container inside the customer's own cloud, behind the IAM, SOC, and audit infrastructure that already passed review. Egress to external models is opt-in per workload, never standing. Memory has full CRUD endpoints, so export and deletion are API calls you can put in a runbook.

The fair objection: "you just built a single point of compromise." Three answers. Consolidating the control plane is not consolidating the keys; BYOK means compromise of the platform does not hand over your credentials. In the enterprise deployment the one door is a door you already own, inside your own perimeter. And memory is exportable and the platform is model-agnostic, so consolidation does not mean lock-in.

You will also notice no certification badges in this post. That is deliberate. We publish no certification we have not earned. Ask for the architecture, not the badge.

FAQ

Are embeddings personal data under GDPR?
Treat them as if they are. Embedding inversion research shows vectors derived from personal data can be reconstructed into close approximations of the source text, which makes "anonymized because it is numeric" a hard position to defend.

Is a unified AI platform a single point of failure?
It concentrates the control plane, which is exactly what makes it auditable. The security question is where keys live and where data can go. With BYOK and deployment inside your own perimeter, the failure domain is one you already operate, instead of eight you do not.

How many vendors are in a typical production LLM stack?
Six to nine: gateway, vector database, memory, RAG framework, embeddings, orchestration, observability, and two to three model providers. Count yours by listing every AI-related line item in billing and every AI-related SDK in your lockfiles. The two lists rarely match, and the gap is unreviewed surface.

What is the fastest single improvement?
Egress. Route all model traffic through one brokered, policy-enforced path and turn off direct provider access from application code. It is the change with the highest ratio of risk removed to engineering effort.

Does consolidation hurt model choice?
It should not, and that is a test to apply to any platform: consolidation of the data plane and control plane is valuable, consolidation that locks you to one model is a different product. Insist on model-agnostic routing and exportable state.

Anyone ever go back to their notetaker outputs and summaries?

Jonathan Murray — Fri, 21 Aug 2026 21:12:59 +0000

Nash Is Now Open Source; Meet Your New AI Workspace

Jonathan Murray — Fri, 21 Aug 2026 14:48:59 +0000

Nash Is Now Open Source 🎉

Big news: Nash is now open source.

You can find the repo here 👉 github.com/Backboard-io/nash

Nash started as an internal tool to make AI actually usable day-to-day — not a chat window bolted onto a model, but a real workspace. As of this release, it's open for anyone to use, fork, self-host, contribute to, or build on top of.

Alongside open-sourcing the project, we're also shipping a major release that pulls Nash's features into a single, connected experience. Here's what's new.

🎨 Image Generation, End-to-End

Image generation is now integrated end-to-end inside Nash.

Go from a rough idea → a first draft → iterations → a finished image without ever leaving the conversation. No context switching, no copying prompts between tools, no losing your thread.

Create, iterate, and keep working from the same experience.

📄 Reliable Document Creation

Whether you're turning an idea into a draft or generating a document as part of a larger workflow, Nash can now carry that process through from request to finished output.

Ask for a PDF, a spec doc, a Word file, a code file — and Nash treats it as a first-class output rather than a side effect of chat.

🔌 MCP Connectivity (Including Google MCP)

This release adds support for MCP (Model Context Protocol), including Google MCP, expanding what Nash can access and work with as part of your workflows.

Instead of keeping your AI isolated from the rest of your work, MCP gives Nash a way to connect with the systems around it — the tools, data, and services you already use every day.

If you've been waiting for an assistant that actually plugs into your stack instead of living beside it, this is the update for you. And since Nash is open source, you can wire up your own MCP servers, extend the integrations, or contribute new ones back to the project.

🖼️ A Library for Your Generated Images

Ever generated the perfect image and then lost it three conversations later? Same.

Nash now has a Library where your generated images are stored automatically, giving you one place to browse and access previous creations directly. Nothing to configure — it just works.

The Bigger Picture

This release is about making Nash feel less like a collection of AI features and more like one connected workspace:

End-to-end image and document generation means outputs feel first-class.
MCP means Nash lives inside your ecosystem, not next to it.
The Library means your work sticks around.

And now, all of it is open source. You can read the code, self-host it, extend it, or ship a fork of your own.

Get Involved

We'd love your help shaping where Nash goes next:

⭐ Star the repo: github.com/Backboard-io/nash
🐛 Open issues for bugs, ideas, or feature requests
🔧 Send PRs — integrations, MCP servers, UI improvements, all welcome
💬 Try it live at hellonash.ai

Ask for something. Create it. Connect the tools you already use. Come back to your work later.

Say hello to your new AI workspace. 👋

Benchmarks Don't Build Great Products. Engineers Do.

Jonathan Murray — Fri, 21 Aug 2026 14:26:26 +0000

The AI industry has a benchmark problem. Not because we have too many benchmarks. Because too many companies treat them like trophies instead of tools.

A benchmark's primary job is to make your product better. Publishing the score is secondary. The test I use: a benchmark should challenge your engineers before it impresses your marketing team.

If it isn't making your product better, it probably isn't serving its most important purpose.

Why does the AI industry have a benchmark problem?

If you've followed AI over the past year, you've seen an endless stream of benchmark announcements. Every week another model reaches the top of another leaderboard. Every release claims a new state of the art. Every company seems to have a chart proving they're the best.

It's easy to become cynical.

The problem isn't that benchmarks exist. Benchmarks are one of the most valuable engineering practices we have.

The problem is that we've started confusing the measurement with the mission.

At Backboard, we don't benchmark because we believe benchmarks are perfect. We benchmark because imperfect, transparent measurements are better than subjective claims.

That idea shapes how we think about engineering.

What are benchmarks actually for?

Benchmarks are feedback loops. That's the whole point.

A benchmark tells us where we're strong, where we're weak, and whether the changes we made actually improved something meaningful. Sometimes an optimization delivers exactly what we hoped for. Other times it exposes a regression we never expected.

Without objective evaluation, it's remarkably easy to convince yourself your product is getting better simply because you've spent weeks working on it.

Benchmarks have a way of keeping engineers honest.

They also create a common language. Our customers shouldn't have to rely solely on our opinion of our own products. Public evaluations give everyone a shared point of reference. No benchmark captures every aspect of an AI system, but transparent measurements let different products be compared using the same criteria.

That's healthier than a world where every company simply declares itself the best.

How do benchmarks get abused?

Like any measurement, they can be gamed. Four ways, all common:

Optimizing specifically for the benchmark rather than the capability it's supposed to measure
Leaking evaluation data into training
Cherry-picking configurations until one produces a good number
Publishing only the results that make for impressive headlines None of those things improve the product.

They improve the marketing.

What's the difference between benchmarking what you built and building for benchmarks?

This is the distinction that matters, and the two can produce similar-looking leaderboard results while being fundamentally different engineering philosophies.

	Building for benchmarks	Benchmarking what you built
Starts with	The test	The customer
Goal	Maximize a score	Validate real improvement
Optimizes	The evaluation set	The capability
When the score improves	Ship the announcement	Check whether customers feel it
When the score drops	Find a better configuration	Find the regression
Failure mode	A number that never translates to value	A slower news cycle

Building for benchmarks starts with the test. The goal becomes maximizing a score, even if that improvement never translates into real world value.

Benchmarking what you've built starts with the customer. You solve real problems first, then use independent evaluations to validate you're moving in the right direction.

Build first. Benchmark second.

What does benchmark transparency actually look like?

Transparency matters as much as performance. Whenever possible we publish our methodology, open source our evaluation frameworks, and share the logs, configurations, and results so others can reproduce our findings.

If someone discovers we've made a mistake, that's not a failure of the process. It's evidence the process is working.

Science advances because results can be challenged. Engineering improves because assumptions are tested.

Here's what that means concretely.

In July 2026 we published an R-CLI result of 84.3% (75 of 89 tasks) on Terminal Bench 2.1, running Claude Opus 4.8 via Bedrock. That's above every published result we're aware of, including Codex CLI at 83.4% and Claude Code at 83.1%. On the same underlying model, R-CLI scored 5.4 points higher than Claude Code.

We also published 72% with GLM 5.2, an open source model. That number is less flattering and we published it anyway, because a company that only shows you its best configuration is showing you marketing.

We did not claim a ranking. Terminal Bench isn't currently accepting submissions, so "highest published result" is accurate and "number one on the leaderboard" would not be. That distinction is small, and getting it right is the entire job.

The per-task verifier logs are public: github.com/Backboard-io/Backboard-R-CLI-Terminal-Bench-2.1-Results

Our memory results, which lead LoCoMo and LongMemEval, are published the same way: github.com/backboard-io

We want people to inspect the work, reproduce it, challenge it, and improve on it. That creates far more confidence than posting a screenshot of a leaderboard ever could.

What don't benchmarks measure?

No benchmark will ever tell the entire story.

They don't measure customer trust. They don't measure usability. They don't capture every workflow or every edge case that matters to an enterprise.

Public benchmarks should always be complemented by real customer evaluations, production deployments, and continuous feedback.

Benchmarks are one input. Not the only input.

Is it wrong to benefit from benchmark reach?

No, and I'm happy to acknowledge it.

Benchmarks create reach. Strong benchmark performance helps people discover what we're building. It starts conversations with engineers, customers, investors, and partners who otherwise might never have found us.

There's nothing wrong with that.

What's important is the sequence:

Benchmark to build a better product
Be transparent about the methodology
Share the results
Learn from the feedback
Repeat Reach is the byproduct. Not the objective.

FAQ

What is the purpose of an AI benchmark?
To create a feedback loop that tells engineers whether a change actually improved the product, and to give customers a shared point of reference instead of a vendor's opinion of itself.

How can you tell if a company is gaming a benchmark?
Look for published methodology, open evaluation frameworks, raw logs, and per-task results. Look for whether they publish their weaker configurations too. A single screenshot of a score is not evidence.

What's the difference between building for benchmarks and benchmarking what you built?
Building for benchmarks starts with the test and optimizes the score. Benchmarking what you built starts with the customer and uses evaluations to validate that real improvements happened.

Are benchmark scores enough to evaluate an AI system?
No. Benchmarks don't measure trust, usability, or enterprise edge cases. They should be one input alongside customer evaluations and production feedback.

Why publish evaluation logs and not just scores?
Because a score you can't reproduce is a claim, not a result. Logs let other people verify the work, and being corrected is how the process is supposed to function.

What has Backboard published?
R-CLI at 84.3% on Terminal Bench 2.1 with Claude Opus 4.8, and 72% with the open source GLM 5.2, both with per-task verifier logs on GitHub. Backboard's memory system leads LoCoMo and LongMemEval, published the same way.

The leaderboard is a byproduct, not the objective

We hope our products perform well on public evaluations. Of course we do.

But that's never been the goal.

The goal is to build software that genuinely helps people solve difficult problems. If we ever stop learning from benchmarks and start treating them as trophies, we'll have missed the point entirely.

Because in the end, benchmarks don't build great products.

Engineers do.

How to Let OpenRouter Pick Your Model, and Choose Who Serves It

Jonathan Murray — Fri, 21 Aug 2026 14:06:54 +0000

Backboard now supports OpenRouter automatic model selection (openrouter/auto) and per request provider selection. Here is how both work, with JSON examples for the Backboard API.

Short answer

Backboard now gives you two independent routing controls for OpenRouter requests:

Automatic model selection. Set llm_provider to openrouter and model_name to openrouter/auto. OpenRouter classifies the prompt and picks the model. You pay the standard rate of the model it chooses, with no additional router fee.
Provider selection. Pin a specific model to a specific upstream provider with the openrouter.providers array, and keep allow_fallbacks on so the request still completes when that provider is unavailable. Both are live now in the Backboard API and in the Python and TypeScript SDKs from v1.5.16 onward.

Why model routing is now two decisions, not one

Most LLM routing writeups treat "which model" as the whole question. It is not.

OpenRouter aggregates 17,000+ models, and many of those models are served by more than one upstream provider. The same model weights can sit behind different pricing, different throughput, different context handling, and different uptime depending on who is running them. So there are two decisions in every request:

Which model should answer this prompt?
Who should run that model? Until this release you answered the first question and inherited an answer to the second. Now you can set both, or delegate both, per request.

How do you let OpenRouter choose the model automatically?

Set the model name to openrouter/auto. OpenRouter classifies the incoming prompt and routes it to a model it judges appropriate for that class of work.

{
  "llm_provider": "openrouter",
  "model_name": "openrouter/auto",
  "openrouter": {
    "cost_tier": "low"
  }
}

This is useful when your traffic is mixed. A support inbox that receives one line acknowledgements and multi page technical escalations does not need the same model for both. Automatic selection sizes the model to the prompt instead of forcing you to build that classifier yourself.

Does openrouter/auto cost extra?

No. You pay the standard rate of whichever model OpenRouter selects. There is no additional router fee layered on top.

How do you constrain automatic model selection?

Automatic does not have to mean unbounded. Three fields inside the openrouter object narrow the candidate set before selection happens.

Field	What it does	Example
`allowed_models`	Restricts selection to a list or pattern of models	`["anthropic/*"]`
`excluded_models`	Removes specific models from consideration	`["some-vendor/experimental-model"]`
`cost_tier`	Caps how expensive a model the router may reach for, from `low` to `max`	`"low"`

allowed_models: ["anthropic/*"] limits automatic selection to that vendor family. That pattern matters for teams with a procurement, residency, or vendor approval constraint. You get automatic selection inside a boundary you defined, rather than automatic selection across everything.

cost_tier is the blunt lever. Set it to low for high volume, low stakes traffic. Raise it for work where an extra few cents per call is irrelevant next to the cost of a wrong answer.

How do you choose which provider serves a model?

Pass a providers array inside the openrouter object. The request is routed to that provider for the model you named.

{
  "llm_provider": "openrouter",
  "model_name": "moonshotai/kimi-k3",
  "openrouter": {
    "providers": ["together"],
    "allow_fallbacks": true
  }
}

Here the model is fixed and the provider is fixed. You chose moonshotai/kimi-k3, and you chose who runs it.

This matters when you have benchmarked providers against each other and found a real difference, when one provider's pricing for a given model is materially better, or when you have an existing commercial relationship with one of them.

What happens when your chosen provider is unavailable?

That is what allow_fallbacks is for. With allow_fallbacks: true, the request can fall back to another provider serving the same model when your selected provider is unavailable. Your preference is honored when it can be, and the request still completes when it cannot.

Set it to false when the provider choice is a hard requirement rather than a preference, and you would rather see the request fail than silently run somewhere else.

Which option should you use?

Your situation	Use
Mixed prompt complexity, no strong model preference	`openrouter/auto` with a `cost_tier`
Vendor family is constrained but model choice is not	`openrouter/auto` with `allowed_models`
You know exactly which model you want	Pin `model_name`, leave provider unset
You know the model and the provider you want	Pin `model_name` plus `openrouter.providers`
Provider choice is a hard requirement	`providers` with `allow_fallbacks: false`

These are per request settings, not account level settings. Different endpoints in the same application can make different choices.

How do you know which model actually ran?

The response tells you. Backboard returns the provider and model that handled the request alongside token counts, so automatic selection does not become a visibility gap. You can log what ran, attribute cost to it, and audit routing behavior after the fact.

That is the practical objection to automatic routing, and it is the reason the response carries the answer rather than leaving you to infer it.

Where can you see which providers serve a given model?

The Backboard Model Library now surfaces provider options for OpenRouter models, alongside pricing, context limits, uptime, and other model information.

Browse it here: https://app.backboard.io/dashboard/model-library

Check the library before you hardcode a provider name. Provider availability for a given model changes.

What do you need to use this?

A Backboard API key from https://app.backboard.io
llm_provider set to openrouter
Backboard API, or the Python or TypeScript SDK at v1.5.16 or later Backboard's free tier includes $5 in memory credits and requires no credit card. Inference is billed separately.

Full parameter reference: https://docs.backboard.io/concepts/messages

FAQ

What is openrouter/auto?
It is a model identifier that hands model selection to OpenRouter. Instead of naming a specific model, you name openrouter/auto, and OpenRouter classifies the prompt and selects a model for it.

Does automatic model selection add a fee?
No. You pay the standard rate of the model that gets selected.

Can I limit automatic selection to certain models?
Yes. Use allowed_models to restrict the candidate set, excluded_models to remove specific models, and cost_tier to cap price, on a scale from low to max.

Can I choose which provider serves a model on OpenRouter?
Yes. Pass a providers array inside the openrouter object in your Backboard request body.

Does provider selection work with automatic model selection?
Provider selection applies to a model you have named. If you delegate model choice to openrouter/auto, you are also delegating the provider that serves it.

What does allow_fallbacks do?
With allow_fallbacks: true, a request can move to another provider serving the same model when your selected provider is unavailable. With it off, the provider choice is strict.

Which SDK versions support this?
Python and TypeScript SDK v1.5.16 and later, plus the Backboard API directly.

How do I find out which model handled my request?
The API response reports the provider and model that ran, so automatic selection stays auditable.

Summary

model_name: "openrouter/auto" delegates model choice to OpenRouter at no extra fee.
allowed_models, excluded_models, and cost_tier keep that delegation inside boundaries you set.
openrouter.providers picks who serves a named model, and allow_fallbacks decides whether that pick is a preference or a rule.
The response reports what actually ran.
Available now in the Backboard API and in the Python and TypeScript SDKs from v1.5.16. Choose the model. Choose who runs it. Backboard handles the rest.

DEV Community: Jonathan Murray

Jev by TypeSafe on Backboard.io

Make a Runway Clone in one shot, or something else!

video is the worst part of the stack to glue

what's live

the code

the part that matters: it's a thread

stuff worth knowing

OpenAI can't rule out that it stole its most recent breakthrough

The setup

The call

The answer

Why this matters to you

There Are Only Two Ways to Make Money in Software.

I Watched Our Interns Play Valorant for Three Hours. Put Your Rank on the Resume.

the ladder does not care about your story

you lose four out of ten and queue again

your comms are already better than the senior dev's

you fill

you already watch your own tape

the grind is the resume

what to actually do

so we are running a league

The Matrix Wasn't A Battery Farm. It Was A GPU Cluster Made Of Human Brains.

The 20 watt problem

Why this makes the plot better

And then I looked up whether anyone was doing this

The version that probably actually happens

I Counted the Attack Vectors in Our AI Stack and Now I Can't Sleep

the fun part: what each one actually is

quick quiz you will fail

"embeddings are just numbers though"

deletion theater

meanwhile, your dependencies

and the stack you didn't even choose

so what do you actually do

the horse, as promised

the whole post in four lines

Every Layer of Your AI Stack Is an Attack Vector. Count Them.

TL;DR

What is an AI attack surface?

The stack you actually deployed

Why vector databases are the layer nobody reviews

The deletion problem: one prompt, four retention policies

The supply chain you inherited

Shadow AI: the surface you did not approve at all

How do you actually reduce an AI attack surface?

Where we stand (the disclosed bias)

FAQ

Further reading

Anyone ever go back to their notetaker outputs and summaries?

Nash Is Now Open Source; Meet Your New AI Workspace

Nash Is Now Open Source 🎉

🎨 Image Generation, End-to-End

📄 Reliable Document Creation

🔌 MCP Connectivity (Including Google MCP)

🖼️ A Library for Your Generated Images

The Bigger Picture

Get Involved

Benchmarks Don't Build Great Products. Engineers Do.

Why does the AI industry have a benchmark problem?

What are benchmarks actually for?

How do benchmarks get abused?

What's the difference between benchmarking what you built and building for benchmarks?

What does benchmark transparency actually look like?

What don't benchmarks measure?

Is it wrong to benefit from benchmark reach?

FAQ

The leaderboard is a byproduct, not the objective

How to Let OpenRouter Pick Your Model, and Choose Who Serves It

Short answer

Why model routing is now two decisions, not one

How do you let OpenRouter choose the model automatically?

Does openrouter/auto cost extra?

How do you constrain automatic model selection?

How do you choose which provider serves a model?

What happens when your chosen provider is unavailable?

Which option should you use?

How do you know which model actually ran?

Where can you see which providers serve a given model?