An AI runtime built for reliability
Every AI request runs against a real, multi-provider fallback chain — Anthropic Claude as the primary provider, with Groq, Google Gemini, and OpenRouter as automatic free-tier fallbacks. If one provider fails, the next is tried immediately, in the same request. Real token usage is tracked on every call. Here is how it actually works, described plainly.
A real, priority-ordered provider chain
Four real providers, tried in this exact order on every request — not a wishlist of integrations we plan to add someday.
Primary provider
Free-tier fallback
Free-tier fallback
Free-tier fallback
This is the real fallback order used on every request: if the primary provider fails, the next provider in the list is tried automatically, within the same request. These four are the only AI providers this runtime has — nothing else is wired in.
What actually happens on every AI request
From authentication to the response reaching you — the real sequence, in order.
- 1
Authentication
The request is authenticated before anything else runs.
- 2
Validation
Inputs are validated before being sent to any provider.
- 3
Routing
The fallback engine selects the next eligible provider in priority order.
- 4
Execution
The request runs against the selected provider.
- 5
Response Validation
Structured responses are checked against an expected schema, with one automatic repair attempt on a malformed response.
- 6
Cost Tracking
Real token usage from the provider's own response is recorded against the organization's AI credit balance.
- 7
Client Response
The result is returned to the caller.
Real fallback, honestly described
No idealized health-monitoring pipeline — just a working mechanism, described as it actually runs.
Automatic fallback, not idealized health-monitoring
If a provider fails, the next provider in priority order is tried immediately — synchronously, within the same request, not via a separate background health-check process.
A provider that fails is skipped for 60 seconds afterward, so a request doesn't repeatedly retry a provider that's currently down — it becomes eligible again automatically once the cooldown passes. This is a real, working mechanism — a simple cooldown, not a formal multi-state circuit breaker.
A real cooldown, not a textbook circuit breaker
We describe what's actually built, not the idealized version of it.
A real cooldown mechanism — simpler than a formal circuit breaker
Each AI provider that fails is temporarily skipped for 60 seconds before being retried again. This prevents wasted time repeatedly calling a provider that just failed.
We're not going to claim a textbook closed/open/half-open state machine we haven't built. What's real: a per-provider cooldown timer, checked before every attempt. We're honest about the difference because we'd rather you trust what we say elsewhere on this page.
7 real background queues
Every queue below is a working BullMQ worker in this codebase — not a mock.
All 7 queues run as real BullMQ workers today, in the same process as the application. Failed-job review and manual retry is available for the Scheduler queue; the others report aggregate health (active/waiting/failed counts) but don't yet have a dedicated retry UI of their own.
Real limits, honestly described
No live quota dashboard — just the real limiting that's actually enforced today.
Real rate limiting on sensitive endpoints; provider quotas are respected, not internally dashboarded
Authentication and abuse-prone endpoints are protected by a real, Redis-backed distributed rate limiter. Free-tier AI providers each enforce their own request/token quotas — when one is hit, the fallback chain moves to the next provider automatically.
We don't yet expose a live 'quota remaining per provider' dashboard internally — that's on our roadmap, not built yet.
Real workers, honestly scoped
Seven background workers run today — described as they actually run, not as they might scale.
7 real background workers, running today
Seven independent BullMQ workers process jobs concurrently, each with its own concurrency limit.
Today these run in-process alongside the application on a single instance. Kubernetes autoscaling manifests (2–10 replicas) and a PM2 cluster-mode config both exist in this codebase for a future multi-instance deployment — real files, but not what's actively running in production yet. We're not going to claim horizontal scaling that isn't live.
Built to recover, not just built to run
Backups, a real disaster-recovery process, and incident tracking — described honestly, with an estimate instead of a guarantee where a guarantee wouldn't be true.
A verified, SHA-256 checksummed database backup runs automatically every night — a real scheduled job, not a manual or occasional task.
A concrete, runnable runbook with real backup and restore commands, and an honestly-stated estimated recovery time — not a guaranteed SLA, and not a vague promise.
Incidents are logged, tracked to resolution, and reviewed — not handled ad hoc — with customer-facing incidents disclosed publicly on our status page.
Real historical uptime, publicly visible
Live health checks and incident history — not a marketing claim.
Every AI request runs inside the same real controls
AI features don't get a separate, weaker security model — they run through the same code-verified controls as the rest of the platform.
Connected integration credentials and platform secrets are encrypted at rest with AES-256-GCM.
Every AI request's input is schema-validated before it's sent to a provider.
Sensitive actions are recorded in a tamper-evident audit trail.
AI features respect the same tenant-isolated, role-based permission model as the rest of the platform.
Sensitive endpoints are protected by a real, Redis-backed distributed rate limiter.
Every AI operation is scoped to its own organization — no cross-tenant data access.
Real cost tracking, honestly described
No public cost preview here — your real usage lives in your account once you're signed in.
Real, per-request token and cost tracking
Every AI call records real token usage from the provider's own response — not an estimate — against your organization's AI credit balance.
See your own usage in Billing → AI Credits once you're signed in.
Build on top of the platform
Some developer surfaces are live today; others are on the roadmap and honestly labeled as such.
A real, authenticated API for programmatic access.
Real outbound webhook delivery with automatic retry.
Token-by-token streaming responses.
Official client libraries.
Interactive in-browser API explorer.
A machine-readable API spec.
What isn't real yet
These aren't ready yet — we'd rather tell you honestly than fake it.
AI Health Dashboard
Coming soonA live, per-provider latency and success-rate view is on our roadmap.
This isn't built yet — check back in a future release.
Live Observability & Tracing
Coming soonDistributed tracing infrastructure exists in code but isn't turned on yet.
This isn't built yet — check back in a future release.
AI Response Caching
Coming soonNo response, prompt, or embedding cache exists yet — every request currently reaches a real provider.
This isn't built yet — check back in a future release.
What's next
None of this is built yet — it's where we're headed, told to you honestly instead of dressed up as already live.
Per-Provider Health Dashboard
Real-time latency and success-rate tracking, broken down by provider.
AI Response Caching
A caching layer for repeated prompts and embeddings, to cut cost and latency.
Distributed Tracing
Turning on the OpenTelemetry scaffolding already in the codebase for full request tracing.
Multi-Instance Worker Scaling
Activating the Kubernetes/PM2 configs already in the codebase for horizontal scaling.
Full Dead-Letter-Queue Management
Extending failed-job review and retry to all 7 background queues, not just one.
Put your growth engine on autopilot
Start qualifying, engaging, and converting pipeline with AI agents today. No credit card required, and your first workflow can be live in under fifteen minutes.