DEV Community: Backboard.io

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.

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.

Coding agents got boring the moment we built a really good one.

Jonathan Murray — Mon, 17 Aug 2026 20:12:46 +0000

MESSAGE FROM BACKBOARD.IO Co-Founder Rob Imbeault:

Coding agents got boring the moment we built a really good one.

That sounds dismissive. I’m ok with that.

Cursor is worth tens of billions. Coding agents are attracting enormous amounts of capital. The category is clearly valuable.

But building R-CLI changed how I think about where the value actually sits.

We built one of the best coding harnesses in the world in a matter of months. On Terminal-Bench 2.1, it performs at the frontier.

Then we open sourced the entire thing.

Not because it wasn't valuable.

Because building it convinced us that the value is moving somewhere else.

Frontier agent performance is becoming accessible much faster than I expected. Small teams can now build systems that compete with products coming out of organizations with vastly more capital, people and compute.

That should make anyone building in this space ask an uncomfortable question:

If a small team can build a frontier coding agent in a few months, how durable is the agent itself as a technical moat?

I don't think the answer is very.

There will still be enormous companies built around coding agents.
Distribution is hard. Product is hard. Workflow ownership is hard.
Brand is hard. Building a great company is very hard.

But the agent?

Increasingly, I think that's becoming the easy part.

The problems that still feel genuinely hard are underneath it.

Making models dramatically cheaper to run.

Giving them persistent organizational context.

Improving them with proprietary data.

Running them privately, locally and securely.

Making open models perform closer to frontier models.

Controlling how intelligence moves across an organization.

Those are the problems we want to work on.

We didn't build R-CLI because we want to win the coding agent market.

We built it and accidentally discovered why we don't.

So rather than build the 1,001st proprietary coding agent and protect the harness like it is the moat, we open sourced ours.

Because our bet is that the next great AI infrastructure companies will not own one agent.

They will make thousands of agents better.

Backboard-io / Backboard-R-CLI

Backboard R-CLI

Backboard R-CLI is an AI coding agent that runs in your terminal. Open it in a project and describe what you want to accomplish. It can inspect and edit files run commands, search the web, use MCP servers and skills, and keep its work reviewable through permissions and checkpoints.

This directory contains the TypeScript implementation of the CLI. End users should install the precompiled backboard binary. Contributors can run or compile it from source with Bun.

Documentation

This README covers installation, authentication, first use, and development. The maintained product guides contain the complete feature reference:

Install the CLI

The production installer downloads a native binary for your operating system. You do not need Bun, Node.js, or Python to use an installed binary.

macOS and Linux

curl

…

View on GitHub

Backboard CLI: 85.4% on Terminal-Bench 2.1, submitted to the official leaderboard

Jonathan Murray — Wed, 12 Aug 2026 02:02:37 +0000

The result

We submitted the Backboard CLI to the official Terminal-Bench 2.1 leaderboard this week. The numbers:

Accuracy: 85.4% ± 0.8%
Pass@5: 0.888
Coverage: 89 tasks × 5 attempts = 445 trials, all included
Model: Claude Opus 4.8 via AWS Bedrock
Total cost of the full run: $280.72 The submission is above every published entry on the leaderboard. The current top published results are Claude Code with Fable 5 at 83.8% ± 1.2% and Codex with GPT-5.5 at 83.1% ± 1.1%. Our PR is open and pending review, and every trial log is public.

Why this matters

Terminal-Bench 2.1 measures what developers actually do: real multi-step tasks in a real terminal. Build failures, dependency messes, debugging under constraints. It's one of the most credible agentic coding benchmarks running.

The leaderboard's top entries are agents built by the same labs that built the underlying models. Claude Code is Anthropic's agent on Anthropic's model. Codex is OpenAI's agent on OpenAI's model.

The Backboard CLI outscored both. On a model we don't make.

That's the point. The harness does the work. How an agent decomposes tasks, delegates to bounded child contexts, and manages what enters the context window determines how much capability you get out of a model. Our CLI is built on a recursive coding engine designed around exactly that, which means performance isn't chained to any single frontier model. Same harness, different model, and it still performs. We've run the same harness on GLM 5.2, a fully open-source model, and scored 72% on this benchmark. That matters if you care about cost, or about running coding agents on infrastructure you control.

How we ran it

No cherry-picking, no re-minting, no overrides:

Five sequential jobs under one identical agent config
Pinned dataset (SHA-256 verified), default settings
All 445 trials included in the reported number
Errored trials counted as zero reward
Full logs uploaded and public Benchmarks only mean something if you can check them. Check ours: PR #200.

We're open-sourcing the CLI

The Backboard CLI is going open source. Soon.

We build model-agnostic infrastructure. The whole thesis is that you shouldn't be locked into one lab, one model, or one vendor's agent. Open-sourcing the CLI is that thesis in practice: take the harness, point it at the model you want, run it where you want.

Watch this space, or follow us for the release announcement.

Try it today

You don't have to wait for the repo. The CLI is available now at backboard.io/cli.

Backboard is a Canadian company building full-stack, model-agnostic AI infrastructure: memory ranked #1 on LoCoMo and LongMemEval, routing across 17,000+ models, agentic hybrid RAG, and stateful threads behind one API key. The CLI is one surface of that platform.

Use any model. Keep your options open. Ship faster.

Sources: Terminal-Bench 2.1 leaderboard | Leaderboard submission PR #200

We bet against the GPU arms race. Here's what shipped.

Jonathan Murray — Thu, 02 Jul 2026 13:15:25 +0000

On July 1 we announced four things at once. The press release version is here. This is the version for people who actually build things.

The short story: while the industry spends hundreds of billions on new hardware, we took the opposite bet. Get more out of the GPUs that already exist, and keep everything inside the customer's own environment.

Here's what came out of it.

BackboardQuant: compression that doesn't lobotomize the model

Everyone who has quantized a model knows the trade: smaller and faster, but dumber. The interesting engineering problem was making that trade disappear.

BackboardQuant (yes, we call it BBQ) compresses models by up to 70% with functionally no quality loss. In our testing, compressed models retained full-precision performance while running up to 2.7x faster.

What that means in practice: one GPU doing the work of two or three. If you're serving models at scale, that's your inference bill cut by more than half without touching your architecture. It ships built into our enterprise deployments.

Backboard Studio: the benchmark result we didn't expect

We built Studio because frontier-lab coding tools are excellent and priced like it. The goal was matching them at a fraction of the cost.

The result on Terminal-Bench 2.1, the neutral public harness for agentic coding:

Backboard Studio running Claude Opus 4.8: 79.8%
Opus 4.8 on its own harness result: 74.6% The harness matters more than people think. Same model, better scaffolding, five points better.

The part I care most about: running GLM 5.2, an open-source model, Studio clears 72%. That's frontier-class agentic coding with no proprietary model in the loop. Pair that with a built-in token optimizer that cuts frontier model usage by up to 30%, and "up to 90% cheaper" stops sounding like marketing.

Studio runs in the cloud or fully self-hosted, so proprietary code never leaves your infrastructure. It's available now.

Nash: one app instead of shadow AI

Every enterprise we talk to has the same problem: employees are pasting company data into whatever chat app they found. The fix isn't a ban, it's a sanctioned option that's better than what they'd find on their own.

Nash gives users thousands of models across text and image in one chat app, with memory that stays out of the model providers' hands. Consumer and enterprise, live at hellonash.ai.

Memory: still #1, and you can check

Backboard ranks first on LoCoMo and LongMemEval, the two leading independent AI memory benchmarks. We published the results and the harnesses so you can reproduce them yourself:

LoCoMo results
LongMemEval results If you find a problem with our methodology, open an issue. We mean that.

The throughline: sovereign by design

None of these are separate products bolted together. The whole stack, API, application layer, and models, can run inside a customer's own cloud. Data never leaves. For governments, hospitals, and banks, that's the difference between "we'd love to use AI" and actually using it.

One more thing, because it matters to us: all of this was built in Nepean, Ontario, by a team made up entirely of graduates of Canadian universities, colleges, and CEGEPs. The default assumption is that this kind of work only happens in San Francisco. It doesn't.

Try it

If you write code, Backboard Studio is the fastest way to see whether any of this holds up. Run it against whatever you're using now and compare the bill.

Questions about the benchmarks, the compression numbers, or the harness? Ask in the comments. I'll answer.

R-CLI: an open-source model harness that beats Claude Code

Jonathan Murray — Tue, 09 Jun 2026 13:56:17 +0000

R-CLI by Backboard.io hit 92% on Terminal-Bench 2.1, the standard benchmark for autonomous coding agents, placing it on top of the global leaderboard using Codex 5.5. Yes, we beat OpenAI using their own model. That's great, but we're more excited about the next point.

Try it - use the DEVTOCLI promo code in your Backboard.io account.

Inside R-CLI, Backboard.io's coding harness, an open-source model just beat Claude Code at coding.

Not matched. Beat. On Terminal-Bench 2.1, Backboard.io's R-CLI running GLM 5.1 (fully open source) scores 70%. Claude Code running Opus 4.7 scores 69.7%. The open model is in front, and it costs a fraction of what Claude Code costs to run.

R-CLI is the coding surface of Backboard.io, the full-stack, model-agnostic AI platform. If you have been looking for an open source Claude Code alternative, this is the one that does not ask you to trade away performance to get it.

The numbers

Setup	Model	Open source?	Terminal-Bench 2.1
Backboard.io R-CLI	GLM 5.1	Yes	70%
Backboard.io R-CLI	Codex 5.5	No	92%
Anthropic Claude Code	Opus 4.7	No	69.7%

Two results worth sitting with:

With an open-source model, R-CLI beats Claude Code. No proprietary model required to get past the best closed coding agent.
With a frontier model (Codex 5.5), R-CLI hits 92%. The same harness scales up when you want maximum capability.

The harness is the product, not the model

Here is the part most people get backwards. A coding agent's score is not mostly about the model. It is about the harness around it: how it plans, how it manages context, how it recovers from mistakes, how it delegates work.

R-CLI is built on Backboard.io's RLM, our recursive coding engine. Instead of stuffing one giant context window and hoping the model keeps track, the RLM breaks work into bounded child contexts and delegates off the main model. The orchestration does the heavy lifting. That is why a 70% open-source result is even possible: the harness closes the gap that the model alone would leave open.

Swap the model, keep the harness. Run GLM 5.1 to beat Claude Code on open source. Run Codex 5.5 to hit 92%. Same R-CLI underneath.

We destroy them on cost

Performance parity would already be a story. Cost is where it stops being close.

Run R-CLI on an open-source model and you are not paying a per-token premium to a frontier lab at all. Self-host it and the marginal cost of a coding run approaches your own compute. Even when you choose to run R-CLI on a top closed model like Codex, the recursive engine does the same work for meaningfully less than the raw harness, because it is not burning tokens on a bloated single context.

Better score. Open model. A fraction of the cost. Pick all three.

Your code never leaves your VPC

Every closed coding tool, Claude Code, Codex, Copilot, Cursor, ships your source to a vendor's API to function. For a lot of teams that is a hard stop: defence, intelligence, regulated health and finance, anyone with real IP to protect.

Because R-CLI can run entirely on an open-source model, it can also run fully on-prem and air-gapped. Frontier-level coding with zero code leaving your infrastructure. The GLM 5.1 result is the proof that on-prem is not a downgrade. You are not choosing between privacy and performance anymore.

Frontier coding, air-gapped. That combination did not exist until now.

Run it yourself

R-CLI is in alpha right now. We are bringing developers in to run it on their own repos, on the model of their choice, and report back with real numbers, not scripted praise.

Request alpha access: backboard.io

Once you are in, the flow is simple:

Install R-CLI and drop in your Backboard.io API key.
Point it at a model. Choose GLM 5.1 (open source) to reproduce the 70%, Codex 5.5 for 92%, or your own on-prem deployment.
Run it on your codebase and check the result against your own tasks.

We are not asking you to trust the leaderboard. We are asking you to run it and see.

One key, the whole stack

Here is what that Backboard.io API key actually unlocks. It does not just run R-CLI.

The same key gives R-CLI native access to the top coding models, Codex, Opus, and the rest, with nothing else to wire up. And the moment you want to build the software around your code, the same key already reaches the entire Backboard.io platform:

17,000+ models for agents, chatbots, and anything else you are building, routed behind one key.
Memory and stateful threads, so what you build remembers users across conversations.
Agentic RAG over your own documents.
Voice (text-to-speech and speech-to-text), image, web search, and parallel tool calls, all on the same key.

You are not standing up a coding tool here, then a model gateway, then a memory service, then a voice provider. You add one API key and you can build software, ship agentic AI, add voice and image, and run tool calls, all from the same place. R-CLI writes the code. Backboard.io is the stack the code runs on.

Why we built it

Backboard.io's thesis is simple: the best AI infrastructure should be the most open and the most accessible, not the most locked down. R-CLI is that thesis applied to coding, the same one key platform that gives you memory, model routing, and RAG, now pointed at your codebase. The best score on Terminal-Bench 2.1 with an open model, runnable on your own hardware, at a cost that makes closed tools hard to justify.

The open source Claude Code alternative is not a compromise version. It is the better one.

Request alpha access: backboard.io

We're still the only one to hit #1 on both LoCoMo and LongMemEval. Here is how to use it.

Jonathan Murray — Sat, 06 Jun 2026 20:32:52 +0000

Backboard is #1 on LoCoMo and LongMemEval, the two academic benchmarks for long-term AI memory without changing the original guidelines. Other companies have gamed by using newer models with bigger context windows. This post explains why the result matters anyway, what it actually measures, and how to use the memory that earned it.

What these benchmarks test

These are not "find a fact in a wall of text" tests. They measure whether a system can build, maintain, and reason over memory across many conversations.

LoCoMo (Long-term Conversational Memory) evaluates very long-term memory over multi-session dialogues that span weeks. It tests single-session recall, cross-session reasoning, temporal reasoning, outside knowledge, and adversarial questions.

LongMemEval scores five distinct abilities: information extraction, multi-session reasoning, temporal reasoning, knowledge updates (noticing when a fact about the user changes), and abstention (knowing when it does not know). Its own paper reports that commercial assistants and long-context models lose around 30% accuracy on sustained memory.

That last point is the whole story.

Why we do not advertise the score much anymore

A few honest notes about the result.

We are still #1 on the original academic benchmarks. Other systems have since posted high numbers too, but they got there by pointing a stronger model at the problem and leaning on ever-larger context windows. At the top, everyone is near the ceiling of what these tests can even measure, so the raw number stops being interesting. What is interesting is how you got there.

The difference is where the work happens. We solve memory at the message level. Memory is built as the conversation happens, fact by fact, then retrieved when relevant. We do not stuff a giant context window to paper over a memory architecture that cannot actually remember. A bigger context window is brute force, and the benchmarks already show brute force degrades on long horizons. Message-level memory is the thing the test is supposed to reward. Fixing problems with brute force isn't scalable over months or years, and it guides users to inflated token usage and higher spend. No thanks.

We did not run these benchmarks ourselves. Third-party organizations did. We do not build for benchmarks and we do not tune to a leaderboard. We build the best memory product for our customers. It just happens to be the best.

One more thing, and we will not name names: several of the top open-source memory projects on GitHub run on Backboard for their paid cloud offering. The thing people benchmark against us is, in some cases, us. We think that is funny.

So we let the score sit quietly and we ship the product. Here is how to use it.

How to use it

The memory that tops these benchmarks is one parameter. Store it on the assistant with memory="Auto", reuse the same assistant_id, and facts carry across every conversation.

Python

pip install backboard-sdk

import asyncio
from backboard import BackboardClient

async def main():
    client = BackboardClient(api_key="YOUR_API_KEY")

    # Conversation 1: a fact is extracted and stored at the message level
    await client.send_message(
        "My name is Sarah. I just moved from Chicago to Toronto.",
        assistant_id="your-assistant-id",
        memory="Auto",
    )

    # Conversation 2: new thread, same assistant, memory recalled
    reply = await client.send_message(
        "Where do I live now?",
        assistant_id="your-assistant-id",
        memory="Auto",
    )
    print(reply.content)  # Toronto

asyncio.run(main())

JavaScript (Node 18+)

const send = (body) =>
  fetch("https://app.backboard.io/api/threads/messages", {
    method: "POST",
    headers: {
      "X-API-Key": "YOUR_API_KEY",
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  }).then((r) => r.json());

await send({
  content: "My name is Sarah. I just moved from Chicago to Toronto.",
  assistant_id: "your-assistant-id",
  memory: "Auto",
});

const reply = await send({
  content: "Where do I live now?",
  assistant_id: "your-assistant-id",
  memory: "Auto",
});

console.log(reply.content);

cURL

curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "My name is Sarah. I just moved from Chicago to Toronto.", "assistant_id": "your-assistant-id", "memory": "Auto"}'

curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "Where do I live now?", "assistant_id": "your-assistant-id", "memory": "Auto"}'

This maps directly to what the benchmarks reward

Each benchmark ability is just a memory mode in practice:

Knowledge updates (Sarah moved cities): memory="Auto" saves the new fact and supersedes the old one, no code from you.
Multi-session reasoning: facts live on the assistant, so they cross threads automatically. Reuse the assistant_id.
Higher-accuracy retrieval: switch memory="Auto" to memory_pro="Auto" when precision matters more than cost.
Abstention: with memory in Readonly, the assistant recalls what it has and does not invent what it does not.

# Precision retrieval over everything the assistant knows
response = await client.send_message(
    "What were my project deadlines?",
    assistant_id="your-assistant-id",
    memory_pro="Auto",
)

The point

The benchmark number says we are first. The architecture says why it will hold: memory at the message level, not a context window stretched to hide a weaker design. You do not have to take the leaderboard's word for it. Set memory="Auto" and feel the difference in your own app.

Grab a key and try it: app.backboard.io

Memory docs: docs.backboard.io/concepts/memory

Chat with your documents: agentic RAG in a few lines

Jonathan Murray — Sat, 06 Jun 2026 11:44:18 +0000

RAG is not new. Chunk a document, embed the chunks, store them in a vector database, run a retrieval step on each query, then feed the results to the model. Every team building with AI has wired this up at least once. It works, and it is also a stack of moving parts you have to assemble and keep running: a parser, an embedding model, a vector store, a retriever, and the glue between them.

Backboard does nothing novel here. It just puts the whole thing behind one API. Upload a file, wait for it to index, ask a question. Retrieval happens automatically inside the same send_message call you already use. The point is not a new idea, it is that it is all unified and easy.

Three steps

Upload a document to an assistant.
Wait for it to reach indexed status.
Ask a question. RAG runs on its own.

Python

pip install backboard-sdk

import asyncio
from backboard import BackboardClient

async def main():
    client = BackboardClient(api_key="YOUR_API_KEY")

    # 1. Create an assistant and upload a file to it
    assistant = await client.create_assistant(
        name="Docs Assistant",
        system_prompt="Answer questions using the uploaded documents.",
    )
    document = await client.upload_document_to_assistant(
        assistant.assistant_id,
        "knowledge-base.pdf",
    )

    # 2. Wait until the document is indexed
    while True:
        status = await client.get_document_status(document.document_id)
        if status.status == "indexed":
            break
        if status.status == "error":
            raise RuntimeError(status.status_message)
        await asyncio.sleep(2)

    # 3. Ask. Retrieval happens inside send_message
    reply = await client.send_message(
        "What are the key points in the document?",
        assistant_id=assistant.assistant_id,
    )
    print(reply.content)
    print(f"Files used: {reply.retrieved_files_count}")

asyncio.run(main())

JavaScript (Node 18+)

import { readFileSync } from "node:fs";

const KEY = "YOUR_API_KEY";
const base = "https://app.backboard.io/api";

// 1. Create an assistant
const assistant = await fetch(`${base}/assistants`, {
  method: "POST",
  headers: { "X-API-Key": KEY, "Content-Type": "application/json" },
  body: JSON.stringify({
    name: "Docs Assistant",
    system_prompt: "Answer questions using the uploaded documents.",
  }),
}).then((r) => r.json());

// Upload a file (multipart, no Content-Type header so fetch sets the boundary)
const form = new FormData();
form.append("file", new Blob([readFileSync("knowledge-base.pdf")]), "knowledge-base.pdf");

const document = await fetch(
  `${base}/assistants/${assistant.assistant_id}/documents`,
  { method: "POST", headers: { "X-API-Key": KEY }, body: form }
).then((r) => r.json());

// 2. Poll until indexed
let status;
do {
  await new Promise((r) => setTimeout(r, 2000));
  status = await fetch(`${base}/documents/${document.document_id}/status`, {
    headers: { "X-API-Key": KEY },
  }).then((r) => r.json());
} while (status.status !== "indexed" && status.status !== "error");

// 3. Ask
const reply = await fetch(`${base}/threads/messages`, {
  method: "POST",
  headers: { "X-API-Key": KEY, "Content-Type": "application/json" },
  body: JSON.stringify({
    content: "What are the key points in the document?",
    assistant_id: assistant.assistant_id,
  }),
}).then((r) => r.json());

console.log(reply.content);
console.log(`Files used: ${reply.retrieved_files_count}`);

cURL

# 1. Create an assistant
curl -X POST "https://app.backboard.io/api/assistants" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Docs Assistant", "system_prompt": "Answer questions using the uploaded documents."}'

# Upload a file (use the assistant_id from above)
curl -X POST "https://app.backboard.io/api/assistants/ASSISTANT_ID/documents" \
  -H "X-API-Key: YOUR_API_KEY" \
  -F "file=@knowledge-base.pdf"

# 2. Check status until it returns "indexed"
curl "https://app.backboard.io/api/documents/DOCUMENT_ID/status" \
  -H "X-API-Key: YOUR_API_KEY"

# 3. Ask a question
curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "What are the key points in the document?", "assistant_id": "ASSISTANT_ID"}'

That is the whole RAG pipeline. No vector database to provision, no embedding service to call, no retriever to write. You uploaded a file and asked a question.

What "agentic" means here

You never call a retrieval endpoint. When you send a message to an assistant that has documents, Backboard decides what to fetch and pulls the relevant chunks with hybrid search (keyword and vector together), then answers. The response tells you what it used:

reply = await client.send_message(
    "Summarize section 3.",
    assistant_id=assistant.assistant_id,
)
print(reply.retrieved_files)        # filenames used as context
print(reply.retrieved_files_count)  # how many

Want deeper or shallower retrieval? Set tok_k on the assistant. It is the number of chunks pulled per query (default 10).

assistant = await client.create_assistant(
    name="Docs Assistant",
    system_prompt="Answer using the documents.",
    tok_k=20,  # retrieve more context per query
)

Two scopes

Where you upload decides who can see the document:

Assistant scope (upload_document_to_assistant): shared across every thread under that assistant. Use it for a knowledge base, product docs, or policies that all users should query.
Thread scope (upload_document_to_thread): visible only in that one conversation. Use it for a file a single user drops into a single chat.

# This file is only visible in one conversation
await client.upload_document_to_thread(thread_id, "meeting-notes.pdf")

Same upload, same query, different reach. No extra config.

Supported files

PDFs, Office files (.docx, .pptx, .xlsx), text and data (.txt, .csv, .md, .json, .xml), source code in most languages, and images. Upload it, and it is searchable once indexed.

The point

Agentic RAG is not a new trick. The win is that you do not build it. One upload, one status check, one message, and your assistant answers from your documents with retrieval handled inside the call. It is all in the same API, and that is the entire feature.

Grab a key and try it: app.backboard.io

Documents docs: docs.backboard.io/concepts/documents

Your memory, your data: read, edit, export, delete

Jonathan Murray — Fri, 05 Jun 2026 10:47:11 +0000

Most AI memory features are a black box. The assistant remembers things about your users, but you cannot see what it stored, you cannot fix a wrong fact, and you definitely cannot take the data with you if you leave. Your users' information lives in someone else's system on someone else's terms.

We want you to be here by choice, not by force.

Backboard treats memory as your data. Every memory an assistant holds is readable, editable, exportable, and deletable through the API. No black box. If you want to inspect it, you can. If you want to leave, you take it with you.

Here is the full lifecycle.

Read: see everything the assistant knows

List every memory on an assistant. Results are paginated, and omitting the page fetches all of them.

Python

pip install backboard-sdk

import asyncio
from backboard import BackboardClient

async def main():
    client = BackboardClient(api_key="YOUR_API_KEY")
    assistant_id = "your-assistant-id"

    memories = await client.get_memories(assistant_id, page=1, page_size=25)
    for m in memories.memories:
        print(f"[{m.id}] {m.content}")
    print(f"Total: {memories.total_count}")

asyncio.run(main())

JavaScript (Node 18+)

const assistantId = "your-assistant-id";

const res = await fetch(
  `https://app.backboard.io/api/assistants/${assistantId}/memories?page=1&page_size=25`,
  { headers: { "X-API-Key": "YOUR_API_KEY" } }
);
const data = await res.json();

for (const m of data.memories) {
  console.log(`[${m.id}] ${m.content}`);
}
console.log(`Total: ${data.total_count}`);

cURL

curl "https://app.backboard.io/api/assistants/your-assistant-id/memories?page=1&page_size=25" \
  -H "X-API-Key: YOUR_API_KEY"

You can also search semantically instead of listing everything:

results = await client.search_memories(
    assistant_id,
    query="user interface preferences",
    limit=5,
)
for m in results["memories"]:
    print(f"[{m.get('score', 0):.2f}] {m['content']}")

Edit: fix what is wrong

A user gets promoted, changes a preference, corrects a detail. Update the memory in place. You can also add a fact manually.

Python

# Add a fact yourself
await client.add_memory(
    assistant_id,
    content="User prefers dark mode in all applications",
    metadata={"source": "manual", "confidence": "high"},
)

# Update an existing memory
await client.update_memory(
    assistant_id,
    memory_id,
    content="Updated preference: user prefers system theme",
)

JavaScript (Node 18+)

// Add a fact
await fetch(`https://app.backboard.io/api/assistants/${assistantId}/memories`, {
  method: "POST",
  headers: { "X-API-Key": "YOUR_API_KEY", "Content-Type": "application/json" },
  body: JSON.stringify({
    content: "User prefers dark mode in all applications",
    metadata: { source: "manual", confidence: "high" },
  }),
});

// Update a memory
await fetch(
  `https://app.backboard.io/api/assistants/${assistantId}/memories/${memoryId}`,
  {
    method: "PUT",
    headers: { "X-API-Key": "YOUR_API_KEY", "Content-Type": "application/json" },
    body: JSON.stringify({ content: "Updated preference: user prefers system theme" }),
  }
);

cURL

# Add
curl -X POST "https://app.backboard.io/api/assistants/your-assistant-id/memories" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "User prefers dark mode in all applications", "metadata": {"source": "manual"}}'

# Update
curl -X PUT "https://app.backboard.io/api/assistants/your-assistant-id/memories/MEMORY_ID" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "Updated preference: user prefers system theme"}'

Export: take it with you

There is no special export format to learn. List every memory and write it to a file. Because the list endpoint returns all memories when you omit the page, a full export is a few lines.

Python

import json

# Fetch all memories (omit page to get everything)
all_memories = await client.get_memories(assistant_id)

export = [{"id": m.id, "content": m.content} for m in all_memories.memories]

with open("memory_export.json", "w") as f:
    json.dump(export, f, indent=2)

print(f"Exported {len(export)} memories")

JavaScript (Node 18+)

import { writeFileSync } from "node:fs";

const res = await fetch(
  `https://app.backboard.io/api/assistants/${assistantId}/memories`,
  { headers: { "X-API-Key": "YOUR_API_KEY" } }
);
const data = await res.json();

const exportData = data.memories.map((m) => ({ id: m.id, content: m.content }));
writeFileSync("memory_export.json", JSON.stringify(exportData, null, 2));

console.log(`Exported ${exportData.length} memories`);

cURL

curl "https://app.backboard.io/api/assistants/your-assistant-id/memories" \
  -H "X-API-Key: YOUR_API_KEY" \
  -o memory_export.json

Plain JSON, your fields, on your disk. That is the export.

Delete: remove one or wipe the slate

Delete a single memory, or reset every memory on an assistant. Reset removes them from both the database and the vector store and is irreversible.

Python

# Delete one memory
await client.delete_memory(assistant_id, memory_id)

# Delete all memories for an assistant (irreversible)
result = await client.reset_memories(assistant_id)
print(result["message"])

JavaScript (Node 18+)

// Delete one memory
await fetch(
  `https://app.backboard.io/api/assistants/${assistantId}/memories/${memoryId}`,
  { method: "DELETE", headers: { "X-API-Key": "YOUR_API_KEY" } }
);

cURL

# Delete one memory
curl -X DELETE "https://app.backboard.io/api/assistants/your-assistant-id/memories/MEMORY_ID" \
  -H "X-API-Key: YOUR_API_KEY"

For users exercising a delete request, that one call removes their data for good.

The point

Memory is only useful if you trust it, and you trust it when you can see it, fix it, take it, and remove it. Backboard exposes the whole lifecycle through the API: read every fact, edit the wrong ones, export the lot as plain JSON, delete on demand. The data the assistant stores about your users is yours, and you are never locked in.

Grab a key and try it: app.backboard.io

Memory API: docs.backboard.io/sdk/memory

Give your AI memory in one parameter

Jonathan Murray — Thu, 04 Jun 2026 10:39:59 +0000

By default, an LLM forgets you the moment a conversation ends. Start a new chat and it has no idea who you are, what you told it last week, or what you prefer. For a real product, that is a dealbreaker. Users expect the app to remember.

The standard fix is a memory pipeline you build yourself. Extract the important facts from each conversation. Turn them into embeddings. Store the vectors in a database. On every new message, run a similarity search, pull the relevant facts, and inject them into the prompt. That is a meaningful chunk of engineering, and you maintain it forever.

Backboard collapses that into one parameter: memory. Set it to "Auto" and your assistant remembers.

The one parameter

Memory is stored on the assistant, so pass the same assistant_id and memory="Auto". Facts the user shares in one conversation are recalled in the next.

Python

pip install backboard-sdk

import asyncio
from backboard import BackboardClient

async def main():
    client = BackboardClient(api_key="YOUR_API_KEY")

    # Conversation 1: tell it something
    await client.send_message(
        "My name is Sarah. I work at Google as a software engineer.",
        assistant_id="your-assistant-id",
        memory="Auto",
    )

    # Conversation 2: new thread, same assistant, it remembers
    reply = await client.send_message(
        "What do you remember about me?",
        assistant_id="your-assistant-id",
        memory="Auto",
    )
    print(reply.content)  # name, employer, and role

asyncio.run(main())

JavaScript (Node 18+)

const send = (body) =>
  fetch("https://app.backboard.io/api/threads/messages", {
    method: "POST",
    headers: {
      "X-API-Key": "YOUR_API_KEY",
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  }).then((r) => r.json());

await send({
  content: "My name is Sarah. I work at Google as a software engineer.",
  assistant_id: "your-assistant-id",
  memory: "Auto",
});

const reply = await send({
  content: "What do you remember about me?",
  assistant_id: "your-assistant-id",
  memory: "Auto",
});

console.log(reply.content);

cURL

# Save: memory="Auto" extracts and stores facts
curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "My name is Sarah. I work at Google as a software engineer.", "assistant_id": "your-assistant-id", "memory": "Auto"}'

# Recall: same assistant, new conversation
curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "What do you remember about me?", "assistant_id": "your-assistant-id", "memory": "Auto"}'

No embedding step. No vector database. No retrieval code. One parameter, and the assistant extracts the facts, stores them, and recalls them when they are relevant.

What `"Auto"` actually does

Behind that single value, Backboard runs the full loop:

Extraction pulls key facts from the conversation, like "works at Google" or "prefers dark mode."
Storage saves them to a semantic knowledge base tied to the assistant.
Retrieval finds the relevant facts on future messages and feeds them to the model.

It works across every thread under the same assistant, which is exactly the behavior you want: the user is remembered no matter which conversation they are in.

The modes

memory is a per-turn parameter. Pass it on each call where you want memory active. Pick one value:

Parameter	Value	Saves?	Retrieves?	Use it when
`memory`	`"Auto"`	Yes	Yes	The recommended default for most apps
`memory`	`"Readonly"`	No	Yes	Recall facts without writing new ones
`memory`	`"off"`	No	No	One-off requests that should not be remembered
`memory_pro`	`"Auto"`	Yes	Yes	You need higher-accuracy recall and accept higher cost
`memory_pro`	`"Readonly"`	No	Yes	High-accuracy recall only

memory and memory_pro cannot be used together in the same message. Use memory for everyday recall and memory_pro when accuracy matters more than cost.

# Higher-accuracy retrieval
response = await client.send_message(
    "What were my project deadlines?",
    assistant_id="your-assistant-id",
    memory_pro="Auto",
)

When you want manual control

"Auto" covers most apps. When you need to manage memory directly, the assistant exposes full CRUD: list, add, search, update, and delete. You own the data and can export it whenever you want.

# Add a fact yourself
await client.add_memory(
    assistant_id,
    content="User prefers dark mode in all applications",
)

# Semantic search over what the assistant knows
results = await client.search_memories(
    assistant_id,
    query="user interface preferences",
    limit=5,
)
for m in results["memories"]:
    print(m["content"])

The point

Persistent memory is usually a project: an extraction pipeline, a vector store, retrieval code, and ongoing upkeep. Backboard makes it a parameter. Set memory="Auto", reuse the assistant, and your AI remembers your users across every conversation. When you need precision or control, switch to memory_pro or manage memories directly. No database required.

Grab a key and try it: app.backboard.io

Memory docs: docs.backboard.io/concepts/memory

Stop letting your hackathon API keys rot

Jonathan Murray — Wed, 03 Jun 2026 22:12:15 +0000

You've got OpenAI, Anthropic, Gemini, and xAI credits sitting in five dashboards. Plug them all into one API and get free state management, courtesy of Dev.to and MLH.

If you've done a hackathon or run a startup, you have API credits scattered everywhere. OpenAI from one event. Anthropic from another. Gemini and xAI from your last sprint. All sitting in separate dashboards, half-used, slowly expiring.

Backboard fixes that. One API, your keys, every model.

Bring your own key

Drop in keys from any of these providers and route across all of them behind a single Backboard API:

OpenAI
Anthropic
OpenRouter
Google Gemini
xAI
Cohere
ElevenLabs

You keep your credits. You keep your rates. You stop stitching seven SDKs together. One key in front of all of them, with memory, routing, and stateful threads built in.

Free state management, on the house

Memory is the part everyone skips at a hackathon because it's a pain to build. Not here. State management on Backboard is free, brought to you by Dev.to and MLH.

Stateful threads at the message level. No vector DB to spin up, no session glue code. Your agent remembers across the whole build.

Add your keys in 30 seconds

Sign in at app.backboard.io
Go to Dashboard → API Keys
Paste your provider keys
Ship

pip install backboard-sdk
# or
npm install backboard-sdk

from backboard import Backboard

bb = Backboard(api_key="your_backboard_key")

# Your OpenAI, Anthropic, Gemini keys are already wired in.
# Memory and state come free.
thread = bb.threads.create(assistant_id="your_assistant")
bb.messages.create(thread_id=thread.id, content="Remember this for later.")

Got tokens from a hackathon? Credits your startup was granted? Put them to work instead of letting them expire.

Add your keys: app.backboard.io/dashboard/api-keys

Stateful AI without a database: threads and assistants

Jonathan Murray — Wed, 03 Jun 2026 10:17:28 +0000

LLMs are stateless. Every API call to a raw model is a blank slate. The model has no idea what was said two messages ago. So the moment you want a chatbot that remembers the conversation, you are on the hook for state.

The usual answer is infrastructure. Spin up Postgres to store message history. Add Redis to cache sessions. Stand up a vector database for long-term memory. Write the code that loads history, trims it to fit the context window, stitches it into every prompt, and saves the new turn. That is a lot of plumbing before the bot says hello.

Backboard handles state for you. Two ideas replace the whole stack: threads and assistants. You never run a database.

The model

Three things, nested:

Message is one turn. A user message in, an assistant reply out.
Thread is one conversation. An ordered list of messages. Pass its thread_id on the next call and the model sees the full history.
Assistant is the profile above the thread. It holds the name, default instructions, tools, and memory. One assistant can own many threads, for example one thread per end-user.

Memory lives on the assistant, so it is shared across every thread under it. History lives on the thread. Both persist on Backboard's side. Nothing to provision.

Threads: state within one conversation

Send a first message and a thread is created automatically. The response hands you a thread_id. Pass it back on the next call and the conversation continues with full context.

Python

pip install backboard-sdk

import asyncio
from backboard import BackboardClient

async def main():
    client = BackboardClient(api_key="YOUR_API_KEY")

    first = await client.send_message("My favorite color is blue.")

    # Same thread: the model remembers the previous turn
    second = await client.send_message(
        "What did I just tell you?",
        thread_id=first.thread_id,
    )
    print(second.content)  # "You told me your favorite color is blue."

asyncio.run(main())

JavaScript (Node 18+)

const send = (body) =>
  fetch("https://app.backboard.io/api/threads/messages", {
    method: "POST",
    headers: {
      "X-API-Key": "YOUR_API_KEY",
      "Content-Type": "application/json",
    },
    body: JSON.stringify(body),
  }).then((r) => r.json());

const first = await send({ content: "My favorite color is blue." });

// Same thread: pass the thread_id back
const second = await send({
  content: "What did I just tell you?",
  thread_id: first.thread_id,
});

console.log(second.content);

cURL

# First message, thread auto-created
curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "My favorite color is blue."}'

# Continue: pass the thread_id from the first response
curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "What did I just tell you?", "thread_id": "THREAD_ID_FROM_FIRST_RESPONSE"}'

No history table. No prompt-stitching code. The thread_id is your conversation state, and Backboard stores it. When a thread gets long enough to crowd the context window, Backboard summarizes older messages automatically so you do not have to manage trimming.

Assistants: state across conversations

A thread remembers one chat. An assistant remembers the user across many chats. Memory is stored per assistant, so to carry facts into a brand new conversation you reuse the same assistant_id and start a fresh thread.

Python

# Conversation 1
await client.send_message(
    "I'm allergic to peanuts.",
    assistant_id="your-assistant-id",
    memory="Auto",
)

# Conversation 2: new thread, same assistant, memory carries over
reply = await client.send_message(
    "Any dietary restrictions you remember?",
    assistant_id="your-assistant-id",
    memory="Auto",
)
print(reply.content)  # "You mentioned you're allergic to peanuts."

JavaScript (Node 18+)

await send({
  content: "I'm allergic to peanuts.",
  assistant_id: "your-assistant-id",
  memory: "Auto",
});

const reply = await send({
  content: "Any dietary restrictions you remember?",
  assistant_id: "your-assistant-id",
  memory: "Auto",
});

console.log(reply.content);

cURL

curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "I am allergic to peanuts.", "assistant_id": "your-assistant-id", "memory": "Auto"}'

curl -X POST "https://app.backboard.io/api/threads/messages" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "Any dietary restrictions you remember?", "assistant_id": "your-assistant-id", "memory": "Auto"}'

This is the part that normally requires a vector database: embedding facts, storing vectors, running similarity search on every request. Here it is one parameter, memory="Auto", and the assistant owns it.

When to pass what

Goal	Pass
Keep talking in the same chat	The same `thread_id` every call
New chat, but remember the user	Omit `thread_id`, reuse the same `assistant_id` with `memory="Auto"`
One assistant, many users	One `assistant_id`, a separate `thread_id` per user

That last row is the whole pattern for a multi-user app. One assistant defines your AI. Each user gets their own thread. State stays separated without a schema you designed, a migration you ran, or a database you babysit.

The point

Stateless models force you to build a state layer. Backboard makes that layer part of the API. Threads hold the conversation. Assistants hold the profile and the memory. Both persist server-side. You ship a stateful, multi-user AI app and never write a line of database code.

Grab a key and try it: app.backboard.io

Architecture in full: docs.backboard.io/concepts/architecture

DEV Community: Backboard.io

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

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?

What do you need to use this?

FAQ

Summary

Coding agents got boring the moment we built a really good one.

Backboard-io / Backboard-R-CLI

Backboard R-CLI

Documentation

Install the CLI

macOS and Linux

Backboard CLI: 85.4% on Terminal-Bench 2.1, submitted to the official leaderboard

The result

Why this matters

How we ran it

We're open-sourcing the CLI

Try it today

We bet against the GPU arms race. Here's what shipped.

BackboardQuant: compression that doesn't lobotomize the model

Backboard Studio: the benchmark result we didn't expect

Nash: one app instead of shadow AI

Memory: still #1, and you can check

The throughline: sovereign by design

Try it

R-CLI: an open-source model harness that beats Claude Code

The numbers

The harness is the product, not the model

We destroy them on cost

Your code never leaves your VPC

Run it yourself

One key, the whole stack

Why we built it

We're still the only one to hit #1 on both LoCoMo and LongMemEval. Here is how to use it.

What these benchmarks test

Why we do not advertise the score much anymore

How to use it

Python

JavaScript (Node 18+)

cURL

This maps directly to what the benchmarks reward

The point

Chat with your documents: agentic RAG in a few lines

Three steps

Python

JavaScript (Node 18+)

cURL

What "agentic" means here

Two scopes

Supported files

The point

Your memory, your data: read, edit, export, delete

Read: see everything the assistant knows

Python

JavaScript (Node 18+)

cURL

Edit: fix what is wrong

Python

JavaScript (Node 18+)

What `"Auto"` actually does