Token Router Enterprise · Prototype acceptance

Token Router Enterprise

Connect enterprise tools to one model-service entry point. Token Router Enterprise runs on your own machines, issuing individual Keys to authorized employees and applications, assigning model permissions and internal quotas, and connecting to model services through TBuy enterprise channels or your own channels. Employees keep using existing tools that have been adapted, while IT centrally manages access and usage boundaries. Call records are stored locally in Token Audit.

Explore the Router demo Acceptance progress

INTERACTIVE SCHEMATICInteractive illustration · Not live data

Employee token / DEMO KEYSimulated authorization

Employee tools→Enterprise gateway→Authorized upstream

Internal quota · Synthetic example3 / 3

Run the simulation to see available quota and the over-quota rejection path.

Quotas are for this interactive example only and do not represent product pricing, performance, or actual billing.

Domainrouter.24test.com

StatusPrototype review

ForEnterprise IT · Application developers · Enterprise AI users

DeliveryDocker Compose stack; N100 mini PC or enterprise Linux VM

What it includes

Two independent services. One machine.

The HTTPS edge routes traffic by two hostnames. The gateway and audit cores retain their separate source repositories and are integrated at pinned versions. Each can be restarted, upgraded, backed up, and resource-limited independently. Cloud-model inference is performed by the selected upstream service; the device handles forwarding, management, and auditing only.

Local gateway

Identity, model permissions, quotas, protocol forwarding, and collection mirroring. Employees use individual Keys; supplier keys remain only in the gateway or upstream platform.

Local auditing

Token Audit Enterprise mode on the same machine: collection intake, content parsing, rule checks, queries, and logged access. The enterprise retains PostgreSQL data and encrypted content.

Upstream options

TBuy restricted enterprise credentials allow only specified models and quotas; raw platform channel keys are never distributed. Alternatively, enterprise-owned channels (BYOK) can be stored locally under controlled access.

Connection test page

The browser page is for connection testing and demonstrations. Production integration is subject to approved clients, application APIs, and the support list.

How employees use it

One Key per employee. Individual quotas and revocation.

Issue Keys: Administrators create a separate Key for each employee, with a name label, finite quota, model allowlist, expiration, and channel group. Employees receive neither the administrator password nor supplier keys.
Connect tools: Tools that support custom API addresses point their service URL to the enterprise gateway. Claude Code has been validated with a separate configuration package and restricted launcher: inherited personal credentials and proxy variables are cleared, while TLS verification remains enabled.
Quotas and costs: Local quotas support internal allocation, while upstream bills verify actual procurement costs. Keeping them separate makes permissions and budgets easier to reconcile by employee and application.
Auditing: Each call’s model, usage, and content are recorded against the employee Key’s identity. Content views create access records. Calls are rejected when the quota reaches zero or the Key is disabled.

Acceptance progress

Accepted capabilities, and those still awaiting acceptance

Capabilities that have not passed acceptance are not marketed as ready-made features. The following is the actual status as of 2026-10-19 on our own N100 mini-PC prototype (PVE virtual machine). It has not yet been deployed in any enterprise customer environment.

Claude Code access with employee Keys, quotas, revocation, and local auditingTwo test employees completed Read tool calls and model responses, totaling 5 successful requests. Calls were rejected both after quota depletion and after Key disablement. Audit identity, usage, content, and content-access logs matched. The acceptance model was qwen-flash; this does not demonstrate official Claude model capabilities.

Accepted

Real calls through TBuy enterprise channels and enterprise-owned channelsThe prototype completed real requests through a restricted SaaS channel and an enterprise-owned channel.

Accepted

Synthetic-prototype software tests8 Python tests and 29 Node protocol tests passed. These tests do not connect to production, call paid models, or operate hardware keys.

Passed

Other clients, including Codex CLI, Cursor, Claude Desktop, and ZeworkInstalled, but actual acceptance of custom endpoints, authentication, and auditing is incomplete. Cursor requests using your own Key still pass through Cursor’s servers; the connection method must be verified first.

Awaiting acceptance

Real employee devices, bulk distribution (MDM), and enterprise SSOThis distribution round was tested only in two directories on the same Mac. It is not real-name verification: anyone holding an employee Key can still make calls as that employee.

Awaiting acceptance

Authentication-rejection events in the audit trailAuthentication rejections currently occur before content auditing. Failed sign-ins and invalid-Key events do not yet have a local audit path.

Known limitation

Manual unlock required after audit restartAfter a restart or container recreation, an administrator must manually unlock the audit service before it becomes available. The design calls for the device UI to distinguish “Gateway available / Audit awaiting unlock / Audit healthy / Audit gap.” The current prototype does not yet have this status page (planned); unattended recovery will be assessed separately.

Known limitation

First-use wizard, device discovery and claiming, audit status page, official release package, and cloud device managementCurrently delivered as command-line scripts and build artifacts at pinned versions. Cloud management is planned; no code exists yet.

Planned

Hardware specifications and capacityN100 / 16GB / 512GB describes the current prototype. Memory, SSD capacity, and concurrency headroom must be assessed against actual request volumes, content sizes, and retention periods. A device model is not a guarantee of supported user count or concurrency.

To be assessed

Frequently asked questions

What to clarify before deployment

Does local deployment mean no content leaves the network?

Local deployment keeps audit records and encrypted content in the environment designated by the enterprise. When calling cloud models, request content is still sent to the selected SaaS or model provider. If inference must also stay on the internal network, choose an internal enterprise model upstream.

Can it audit every AI website employees open directly?

It cannot automatically cover arbitrary HTTPS websites or all official clients. Tools and applications must explicitly connect to the enterprise gateway, and their protocol and feature coverage must be confirmed. Enterprise egress and endpoint policies should be assessed as separate project requirements.

Do we need to replace the existing enterprise router?

No. The device connects alongside the existing enterprise network without running DHCP, changing employees’ default gateway, or modifying enterprise DNS. The current prototype requires an administrator to assign a fixed LAN address (static or DHCP reservation) and two hostnames, and configure internal name resolution and endpoint certificate trust. Automatic address acquisition and device discovery are planned. Using the device as the enterprise’s primary router requires separate validation.

What about pricing, trials, and service levels?

No product pricing, free trial duration, service levels, or formal after-sales commitments are currently set. Licensing, installation packages, and bundled deliverables must each be confirmed by the product owner.

What is the gateway core’s open-source license?

The gateway core is derived from new-api, licensed under AGPL-3.0, and ships with the license file. Corresponding source, dependency source, and licenses for the current synthetic demo are available in the demo site’s source archive .

Book a scenario demo

Bring the tools, model services, and audit requirements you plan to connect. We will confirm product selection and delivery scope together. Products can be evaluated separately or in combination with Token Audit.

Business and contact details will be added here after confirmation by the product owner. TBuy restricted enterprise credentials are requested through a tbuy.ai enterprise account and are currently issued manually. A self-service issuance interface is planned.

How the products connect

Before integration: use 24Test Model Check to verify upstream channels. Protocol checks against an internal enterprise gateway require a local runner (planned).
After integration: call records enter local Token Audit; the gateway console can be configured with a link to the enterprise’s audit service.
Procurement: models and tokens are purchased through TBuy, with restricted credentials serving as one of the gateway’s upstream options.