Sanctum Router / AI infrastructure
Replace separate provider integrations in each application with a shared routing layer. Keep configured model access, selection and request records in one place.
Implemented for Digital Sanctum’s own stack.
Already have access? Sign in ↗
What changes for your firm
Separate integrations mean repeating provider-specific request handling, credentials and failure handling across applications. Router puts that integration work behind a common service, so supported provider changes can be handled there. A new provider still needs an adapter and compatibility checks.
Give applications a shared access boundary to configured models. Every request requires a valid token and invoke scope. Task-based and pinned-model selection check enabled entries and configured providers, with additional model-scope gates for non-admin callers. Administrators can maintain the catalogue.
Make the model choice explicit for each request. Choose a specific model, or let Router select from candidates using task, capability and routing constraints. The model-list API exposes provider, modalities, context limits and pricing metadata. Its default active list excludes disabled, deprecated and unconfigured provider entries.
Review the selected route and the pricing basis behind its calculated cost. Request records include the selected provider and model, fallback use, status, latency and available token and cost fields. Catalogue pricing makes the basis of cost estimates visible when you review a model or update its price. These are catalogue-based calculations, not invoice reconciliation or a live price-change alert.
Our own stack
In Sanctum Chat’s released model client, provider requests go through Router’s shared /v1/route endpoint. The client can pin a model and disable fallback, or send routing constraints. Provider-specific dispatch lives in Router.
For a buyer, this architecture puts supported connection changes behind one application-facing route. It is implementation evidence, not a measured saving or a completed provider-substitution trial.
Source-backed example
Chat’s authenticated client, Router’s dispatch code and the added TypeSafe/Jev adapter show the two sides of that boundary. The adapter scores a fixed Jev test/use question; it is not a general conversational model.
Read the version-bound implementation and acceptance notes ↗
A pilot would still need to test your application’s request format and a supported provider substitution. The separate Jev decision-service acceptance is documented in the notes; it does not prove that substitution or judgment accuracy.
Start with one application
Bring one AI workflow and the providers you want it to use. Request a written scope and quote for a pilot before committing to a wider integration.
One application, its request format, permitted providers and models, credential ownership and data handling. Identify any adapter work before the pilot starts.
Agree checks for model selection, a supported provider substitution, failure handling and request-record visibility. Use those results to decide whether to expand.
Define configuration documentation, deployment responsibilities, support boundaries and rollback steps. Include the work needed to run the integration after the pilot.
Pricing: request a scoped quote covering integration work, hosting and support responsibilities, and provider charges. No standard pilot price is published here; the application, providers and operating scope need to be defined first.
Router pilot enquiry
Email Digital Sanctum with the subject “Sanctum Router pilot quote”. Describe the application, its AI workflow, the providers and models you want to use, and who would operate the integration.
Ask for a written scope and quote covering connection work, acceptance checks and operating responsibilities. Agree that scope and price before commissioning the pilot. Keep credentials and private business data out of the enquiry.
Already have access? Sign in ↗