Token Router Enterprise
Assign authorized employees and applications individual keys, model permissions, internal quotas, and expiration limits. Connect to TBuy enterprise channels or your own authorized channels.
Explore enterprise accessLOCAL INFRASTRUCTURE / ON-PREMISES
Deploy locally.
Built for your environment.
Two independent software products run on infrastructure chosen by your enterprise. The device handles access and auditing; your selected upstream performs cloud model inference.
Combined local deployment · Prototype validation
24T / ENTERPRISE DEPLOYMENT
HARDWARE + SOFTWARE
Device and delivery configuration confirmed per project
HARDWARE + SOFTWAREDevice and delivery configuration confirmed per project
Device images come from product materials and illustrate appearance only. They do not establish mass-production availability or fixed performance specifications.
01 / TWO PRODUCTS, CLEAR ROLES
Access and auditing.
Two clearly defined roles.
Choose either product independently or deploy both on the same device. Separate services can be upgraded, restarted, backed up, and assigned resource limits independently.
Token Audit
Receive call metadata or content within the authorized scope, encrypt it per tenant, and run basic rule checks. Viewing content requires the appropriate role and creates an access record.
Explore call auditing02 / DEPLOYMENT OPTIONS
Deployment that fits your business.
Infrastructure that fits your needs.
Compact device
Evaluate combined access and auditing on a mini PC such as an N100. Start by validating the end-to-end workflow with authorized test data.
Current prototype: N100 / 16GB / 512GB
Rack-mount reference
A reference for discussing form factor and rack installation in your enterprise environment. Model, port functions, and hardware configuration must be confirmed for each project.
Appearance reference only; not a supported-hardware list
YOUR EXISTING
INFRASTRUCTURE
03 / LINUX & VM
INFRASTRUCTURE
Enterprise server / VM
Run Docker services on an existing enterprise Linux server or a dedicated Linux virtual machine. Evaluate resources, networking, and operational requirements.
AI access does not require replacing your main router03 / DELIVERY CHECKLIST
Before delivery,
confirm four essentials.
A hardware model does not guarantee a user count or concurrency level. Assess suitability against a defined test scope and acceptance checklist.
Tools & models
List authorized clients, business applications, model services, and authorizing parties. Validate custom endpoints, protocols, streaming, and specialized capabilities individually.
Workload & budget
Confirm peak requests, streaming connections, batch jobs, and the total budget. Application queues manage concurrency and retries; upstream bills are reconciled separately.
Collection & retention
Decide whether to record metadata or content, how long to retain it, who may view it, and how to handle backup locations, resource isolation, and permissions.
Networking & recovery
Define domains, certificates, maintenance windows, and responsible owners. Local auditing requires manual unlocking after a restart; verify the recovery process against the acceptance checklist.
Local records. The same model request destination.
When using a cloud model, content is sent to the selected upstream. If inference must also stay on your internal network, choose an internal model upstream first. Side-channel auditing records activity and identifies issues; it does not automatically block requests before they are sent.
BEFORE DEPLOYMENT
Start with validated capabilities.
Plan your next step.
Currently in prototype validation; not yet deployed in enterprise customer environments.
Which tools have completed acceptance testing?
On October 19, 2026, employee-key access, quota limits, key deactivation, and local auditing for Claude Code passed acceptance testing on our own N100 prototype using qwen-flash. Codex CLI, Cursor, Claude Desktop, Zework, and other tools still require individual integration acceptance tests.
Do I need to replace my existing router?
No. The deployment connects alongside your existing network through a defined application endpoint. The current prototype requires an administrator to assign a fixed LAN address and two hostnames, and configure name resolution and certificate trust on client devices. Automatic discovery, device claiming, and cloud device management are still planned.
Does auditing recover automatically after a restart?
An administrator must currently unlock the audit service manually before it becomes available. Unattended recovery and hardware-backed keys require separate evaluation. Unfinished capabilities are not included as delivery commitments.
How are configuration and pricing determined?
Device configuration is determined by actual workload, content retention, and recovery requirements. Hardware, software licensing, model procurement, implementation, and operations are discussed separately. No fixed price, trial period, or SLA is currently specified.
START WITH YOUR ENVIRONMENT
Understand your environment.
Then define the delivery.
Begin a practical deployment assessment with your tool list, workload, and retention requirements.