Rust SDK overview
brain-db-sdk is the Rust client for Brain — a full-surface native wire client plus a lightweight HTTP client, both async on Tokio.
Package facts
| Field | Value |
|---|---|
| Crate name | brain-db-sdk |
| Library name | brain_db_sdk |
| Latest version | 0.1.0 |
| Edition | 2021 |
| MSRV | 1.75 |
| Async runtime | Tokio |
| License | Apache 2.0 |
Add it with:
cargo add brain-db-sdkEverything in this section imports from the brain_db_sdk crate root or its http / wire submodules:
use brain_db_sdk::{Auth, BrainClient, BrainHttpClient};Two clients
Brain has no single canonical transport for the SDK — it depends on what you need.
BrainHttpClient (HTTP)
JSON over the hosted edge (brain-edge self-hosted, or the Arc cloud gateway). A strict subset of the surface: encode, recall, forget, link, unlink, plan, reason, whoami, capabilities. No typed graph, transactions, or subscriptions. Simplest to reach for when you only read and write memories.
BrainClient (wire)
The native BRN0 protocol over TCP. The full surface: everything the HTTP client does, plus typed entities/statements/relations, schema upload, transactions, and long-lived SUBSCRIBE change feeds. One multiplexed connection serves many concurrent requests — every verb takes &self.
Which one to use
- Use
BrainHttpClientwhen you are calling the hosted edge or gateway and only need the memory verbs (encode/recall/forgetand the graph reasoning helpers). It is a thinreqwestclient with built-in retry. - Use
BrainClientwhen you self-host and need the typed graph, transactions, subscriptions, or the streaming list/traverse verbs — or when you want a single connection multiplexing many in-flight requests.
Quickstart
Connect to the hosted edge, write a memory, and recall it:
use brain_db_sdk::BrainHttpClient;
use brain_db_sdk::http::{EncodeInput, RecallInput};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// base_url first, then the API key.
let client = BrainHttpClient::new("https://api.arc-labs.ai", "my-api-key");
let stored = client
.encode(&EncodeInput {
text: "Ada prefers dark mode and lives in Berlin.".to_string(),
..Default::default()
})
.await?;
println!("stored memory {} (deduped: {})", stored.memory_id, stored.was_deduplicated);
let answer = client
.recall(&RecallInput {
query: "where does Ada live?".to_string(),
max_results: Some(5),
..Default::default()
})
.await?;
println!("{}: {} memories", answer.answer_kind, answer.memories.len());
Ok(())
}Brain owns the embedding model — you send text, never vectors. encode takes a plain string; the server embeds it with its bundled BGE-small model.
Recall is not top-k
recall answers the way a memory does, not the way a search index does. The result carries an answer_kind reporting the shape of the answer:
- None — nothing matched. Brain returns an explicit empty answer rather than fabricating one.
- Single — one memory answers the cue.
- Many — several memories are relevant.
Over HTTP answer_kind is a string; over the wire it is the AnswerKindWire enum. See Recall for how to branch on it.
Section map
| Page | What it covers |
|---|---|
| Installation | cargo add, Cargo.toml, Tokio runtime, MSRV |
| HTTP client | BrainHttpClient — construction, builders, auth, the subset it supports |
| Wire client | BrainClient — connect, handshake, Auth, ClientConfig, accessors |
| encode | Writing memories on both clients |
| recall | Reading memories, the answer_kind membership shape |
| forget | Soft tombstone vs. hard erase |
| Typed graph | Wire-only entities, statements, relations, schema, transactions, subscribe |
| Errors | The error types, retry policies, retryability |
Was this page helpful?