Questions

No. Prompt and completion bodies are not persisted. They are processed to serve the request and are not written to any store. What we keep is metadata about the request: which model served it, why the router chose it, input and output token counts, cost, latency and error state. Support staff cannot retrieve the text of a request, because it does not exist to retrieve.

ModelBeat trains no model on customer content, and our inference sub-processors are contractually barred from training on what we send them. We name every one of them at /subprocessors, so you can check that rather than take our word for it.

Our own infrastructure runs in one United States region today. Each workspace carries a region pin set at creation and immutable afterwards, so a workspace cannot silently drift across a border. Further regions, including the European Union, are designed and not yet deployed; when one goes live it is listed on /security with its date. Note that our inference sub-processor operates its own onward sub-processors, which process in Japan, Iceland, the United Kingdom and Germany. Those are disclosed at /subprocessors.

Prompt and completion content is not stored at all. Request metadata and routing decisions are kept for 13 months. The audit log and the credit ledger are kept for seven years and are append-only, so entries are added and never edited. Security and error logs are kept 90 days, backups roll on 35 days, and support conversations are kept 24 months. Account and user records last the life of the account plus 30 days.

Content you can see in the console, you can delete there. For account closure and full erasure, write to hello@neuralarc.ai. Financial records and audit events are retained where law requires it, and we will tell you which ones rather than quietly keeping everything. Erasure is handled manually today; that limitation is listed on /security.

No. We share with the sub-processors listed at /subprocessors, for the purposes stated against each one, and nowhere else. There is no data broker, no advertising network, and no revenue we earn from your traffic other than the published markup on inference.

Always, on every request and on every plan. Served-model identity is not a premium feature and never will be. If you cannot see what answered, you cannot audit it.

Only the models in the catalogue for your workspace, which is visible in the console. OpenAI, Google and Anthropic models are not in the production catalogue, and no request can route to them.

No. The router optimises against your constraint, taking the cheapest model that clears the quality bar for the work. Our margin is a markup on cost that is uniform across models, so routing you upward gains us nothing, and the per-request receipt showing the model, the tokens and the cost makes that checkable rather than merely stated.

The router absorbs it and re-routes within the set you are eligible for. Providers you have made ineligible stay unreachable, including as a fallback: a disabled provider is disabled, not a hidden safety net.

On cloud, request content goes to the inference sub-processor serving it and metadata comes to us. On bring-your-own-cloud, content still goes to the inference sub-processor but never to a ModelBeat account, and metadata is optional. On premises, nothing leaves at all unless you point the router at an external provider.

Provider eligibility is configurable per workspace, and an ineligible provider is unreachable rather than merely deprioritised. Per-request and per-key enforcement flags are on the roadmap and are not built yet.

Operator access is role-limited and requires a separate identity pool with multi-factor and step-up authentication. Every operator action against a customer tenant is written to a separate, hash-chained audit log that you can request. Our access to your workspace is audited the same way yours is.

We buy inference at cost and sell it at a published markup. There is no hidden spread, no rebate from a provider for sending you their way, and no reason for the router to prefer an expensive model, because the markup is uniform across them. Every request shows the model that served it, its input and output tokens, and what it cost, with prompt and completion split so you can see which half you are paying for.

Every workspace carries a per-request spend ceiling, and every key carries its own budget and rate cap. A request that would breach the ceiling is stopped rather than served, and the stop is written to your audit log.

No. Checkout is hosted by Stripe and no card number reaches ModelBeat. That is a deliberate scope choice, and it is why our PCI obligation is the minimal SAQ-A tier.

The request errors with a reason rather than silently downgrading to a model you did not approve. Failing closed is the default, and a failed attempt costs you nothing.

No. Every privileged mutation writes an immutable audit entry in the same database transaction as the action itself, so a failed audit write fails the action. The credit ledger is append-only, enforced by database triggers and revoked privileges rather than by application convention. Corrections are new entries, never edits.

None yet, and we will not imply otherwise. SOC 2 Type 2 is not held and no attestation exists; ISO/IEC 42001 alignment is in progress and not certified. Our GDPR position, our control set and the things we have not built are all written out on /security, including the parts that do not flatter us.

Yes. It is published in full at /dpa rather than held back for a sales call, and it is incorporated into the terms you accept. It carries our processing instructions, the Article 32 security measures, breach notification, deletion, audit rights and the transfer mechanism.

There is not one to see. No penetration test has been commissioned, so there is no report to request, and we would rather answer the question than leave it hanging. It is listed as a known limitation on /security and that row will change when it changes.

Write to hello@neuralarc.ai with "security" in the subject line and enough detail to reproduce it. The same address is published at /.well-known/security.txt. Good faith research is welcome, the boundaries are set out under Harm to systems in the Acceptable Use Policy, and we will not pursue anyone who reports a genuine finding and gives us a reasonable chance to fix it first.