Skip to main content
AIDiveForge AIDiveForge

AgentRecall vs burnban

AgentRecall and burnban are both inference engines & infra tracked by AIDiveForge. Below is a side-by-side comparison of pricing, capabilities, platforms, and ownership — sourced from each tool's live website and verified before publishing.

AgentRecall

AgentRecall

AgentRecall is a memory layer that gives AI agents persistent context across sessions — so a support agent recalls a customer's past issue, a sales agent remembers where a deal stalled, and a coding assistant doesn't ask you to re-explain your architecture for the third time. The vendor describes a retrieval-and-storage infrastructure that indexes memories and surfaces relevant ones at query time, rather than stuffing the full conversation history into every prompt. The cloud tier caps at 1,000 stored memories, which is adequate for prototyping but a ceiling teams hit in production. Self-hosting under the MIT license removes that ceiling and keeps data inside your own infrastructure — the tradeoff is that you own the ops. API access covers JavaScript and Python environments.

burnban

burnban

Burnban reads supported agent log files already sitting on disk, prices the recorded usage against public API list rates, and lets you set daily, weekly, monthly, or per-agent spend caps enforced in the request path — all from a local dashboard at localhost:4141. The ledger is SQLite on your machine. No keys leave to a Burnban server, no prompts hit a control plane, no account is required. The sharp edge is the word 'supported': log format and provider coverage are scoped, and anything outside that scope remains invisible to the meter. Teams tracking unsupported agents or providers find Burnban shows them a partial picture.

AttributeAgentRecallburnban
PricingPaidFree
Price$9/month for Pro (cloud); self-hosted is free
Free trialNoNo
Open sourceNoYes
Has APIYesNo
Self-hosted optionYesYes
PlatformsCloud (hosted API), Self-hosted (Docker/bare metal on user infrastructure)macOS, Linux, Windows
Pros
  • Persistent memory across sessions, so a support or sales agent can reference a customer's prior context without the user having to repeat themselves — which is the difference between an agent that feels useful and one that feels like a fresh chatbot every time.
  • Self-hosted MIT-licensed deployment, so teams with data residency requirements can keep every stored memory inside their own infrastructure without negotiating a custom data agreement.
  • API-first design with JavaScript and Python SDKs, which means the memory layer drops into an existing agent stack without a rewrite — teams avoid building and maintaining a bespoke retrieval system from scratch.
  • Retrieval-at-query-time architecture, so only relevant memories surface per session rather than inflating every prompt with full history — which keeps token costs and latency from compounding as memory volume grows.
  • Claude Desktop integration documented by the vendor, so teams already in that environment get memory persistence without standing up separate infrastructure.
  • Zero-telemetry local enforcement, so your API keys, prompts, and responses never touch a Burnban server — eliminating the trust risk that comes with cloud-based spend gateways.
  • Daily, weekly, monthly, and per-agent spend caps enforced in the request path, so a runaway agent gets blocked before it runs up the bill rather than flagged after the invoice arrives.
  • The subsidy repricing command converts historical log data into a qualified, shareable cost estimate against any supported model's public rates, so you can surface the real cost of local agent activity to stakeholders without needing provider-side billing access.
  • MIT licensed single binary with checksum verification and published SBOMs, so teams with strict supply-chain policies can audit exactly what sits in their provider request path.
  • Local SQLite ledger requires no account, signup, or cloud dependency, which means the tool keeps working when a vendor changes pricing, shuts down, or decides to monetize the data flowing through their gateway.
Cons
  • The cloud tier caps at 1,000 stored memories — a solo developer's prototype fits, but a customer support deployment with hundreds of users hits that ceiling within days. Teams either move to the paid-only cloud tier or take on self-hosting, neither of which is free in time or money.
  • Self-hosting transfers all ops responsibility to your team: infrastructure provisioning, uptime, upgrades, and any debugging when retrieval quality degrades. Teams without dedicated DevOps capacity discover this is not a one-afternoon setup.
  • The scraped page content does not confirm a native vector database or specify retrieval ranking logic, which means teams with precision recall requirements — where surfacing the wrong memory is worse than surfacing none — have no documented way to audit or tune retrieval quality before they hit that problem in production.
  • Teams that need memory scoped by user, tenant, or access role in a multi-tenant SaaS product will find no documented isolation model in available sources. When that requirement surfaces mid-build, the path forward is custom middleware or a competitor that ships tenant-aware memory out of the box.
  • Enforcement only applies to traffic routed through the local meter — agents or apps that call providers directly bypass all caps entirely, so a team with more than one or two agents faces a partial blind spot from day one.
  • Log reading and traffic enforcement are scoped to 'supported' agents and providers; the docs do not enumerate a complete compatibility list on the landing page, so teams discover unsupported tools by finding gaps in the dashboard rather than a checklist upfront.
  • Because Burnban is a V0.4 single-maintainer project with no API surface and no integrations layer, teams that outgrow personal spend monitoring and need org-level cost allocation, multi-seat dashboards, or CI budget gates will find nothing here to extend — at that scale they migrate to a platform with an admin layer, and Burnban becomes a retrospective curiosity.
  • The model repricing and subsidy features produce estimates explicitly qualified as 'API-equivalent' against list rates, not actual billed amounts — teams using negotiated pricing or credits will find the numbers systematically off, making the output useful for illustration but unreliable for finance reconciliation.
Bottom line

AgentRecall is paid while burnban is free; burnban is open source; only AgentRecall exposes a public API. Choose based on which difference matters most for your workflow.

Frequently asked questions

What is the difference between AgentRecall and burnban?

AgentRecall is Paid, while burnban is Free and open source. Compare pricing, free trial, API, platforms, and pros/cons in the table above on AIDiveForge.

Is AgentRecall better than burnban?

It depends on your workflow. Use the side-by-side attributes (pricing, open source, API, self-hosted, platforms) to decide. AIDiveForge does not rank a universal winner — we publish verified facts so you can choose.

AgentRecall vs burnban: which should I pick?

Pick AgentRecall if its pricing model, openness, or platform fit matches your constraints; pick burnban otherwise. Check free-trial availability on each listing if you want to test before committing.

Comparison data is sourced and verified by the AIDiveForge data pipeline. AIDiveForge is editorially independent.