anonrouterdocs

RisuAI Setup with AnonRouter

Install the AnonRouter preview provider plugin for RisuAI and use the native single-use ticket API for character chats.

RisuAI's plugin API can register a custom AI provider and make arbitrary HTTP requests. The AnonRouter plugin uses that capability to perform the native two-step ticket flow instead of sending a stable key beside your character prompt.

Native tickets, not compatibility mode

The plugin sends your ar_... key to AnonRouter's control plane to mint a short-lived ticket. It then sends the prompt to the relay with only that ticket. A normal ticket-only inference key works; OpenAI-compatible access is not required.

Risu Web adds another trust boundary

RisuAI's web build normally sends plugin network traffic through Risu's /proxy2 service. That intermediary can observe and correlate the ticket and completion calls. The desktop runtime sends directly. The plugin preserves AnonRouter's control-plane/relay split, but it cannot promise end-to-end unlinkability through every RisuAI runtime.

Download the RisuAI plugin

Download anonrouter-native.js

This is an AnonRouter preview integration, not a plugin reviewed or endorsed by the RisuAI project. The downloadable source uses plugin API v3.0 and is readable JavaScript. Review it before importing it, especially because it handles an inference key and sends character-chat content to a remote model.

Install and configure

  1. Download the plugin file above.
  2. In RisuAI, open Plugin Settings → Import Plugin.
  3. Select anonrouter-native.js.
  4. Open the imported plugin's settings.
  5. Set api_key to a normal AnonRouter inference key beginning with ar_.
  6. Set model to an exact id from the AnonRouter model catalog.
  7. In RisuAI's provider/model settings, choose AnonRouter (Private Ticket Flow).
  8. Start with a short character-chat message and confirm the full reply appears.
Create an API key

For roleplay, browse current uncensored models. One example is venice/venice-role-play-uncensored, but availability and model metadata can change. Copy the live API id instead of guessing from a display name.

Already running 0.1.0? Reimport

`0.1.0` cannot generate at all

Version 0.1.0 sent the ticket request to the wrong origin. It called POST https://api.anonrouter.ai/v1/inference/tickets, which the content edge does not route, so every generation failed at the first call with AnonRouter: ticket request failed: HTTP 404 and the completion never ran. Version 0.1.1 mints against https://control.anonrouter.ai/v1 and is the first version that works.

The plugin header carries an //@update-url pointing back at this site, and RisuAI checks it by reading the first bytes of the file and comparing //@version against the copy you have installed. 0.1.1 is greater than 0.1.0, so the check has something to offer.

Reimporting by hand is the path that always works, and it is the one to use if you are not sure:

  1. Download anonrouter-native.js from the link above again.
  2. In RisuAI, open Plugin Settings, remove the existing AnonRouter (Private Ticket Flow) plugin, and import the downloaded file.
  3. Re-enter api_key and model; plugin arguments do not survive a reimport.
  4. Reselect the provider and send one short message to confirm a reply arrives.

Two things worth knowing about the automatic check, so a silent result is not mistaken for "there is no update":

  • RisuAI's web build makes this check from browser script, which means it is subject to the update URL's cross-origin headers. If the check appears to do nothing on Risu Web, reimport by hand.
  • RisuAI only offers an update when the published version is strictly greater than the installed one. Two installs of the same version number never prompt, whatever the file contains — which is why the corrected plugin ships as a new version rather than as a quiet replacement of 0.1.0.

What the plugin does

For every generation, the provider handler receives RisuAI's OpenAI-format prompt_chat array and generation settings. It then:

  1. Calls POST https://control.anonrouter.ai/v1/inference/tickets with the inference key, model id, and output-token limit—but no prompt.
  2. Reads the short-lived, single-use ticket from the response.
  3. Calls POST https://api.anonrouter.ai/v1/chat/completions with the prompt, model id, matching token limit, and x-anonrouter-ticket header—but no key.
  4. Returns the assistant's text to RisuAI.

This is the same trust separation documented in AnonRouter authentication: the control plane sees key identity without content, while the relay sees content with an opaque one-use ticket.

The plugin sends the bearer header only on the ticket request and passes RisuAI's cancellation signal to both calls. RisuAI's declared saveSecretHeader API is not implemented in the current runtime, so this version cannot use it as write-only credential storage.

Current plugin scope

Version 0.1.1 deliberately keeps the smallest dependable provider surface:

CapabilityStatus
Current plugin version0.1.1
RisuAI plugin APIv3.0
AnonRouter authenticationNative ticket flow
Text character chatSupported
Temperature and maximum output tokensSupported
CancellationSupported
Streaming displayNot yet; the full reply is returned at once
Vision/inlay attachmentsNot forwarded
Tool callsNot exposed by this provider version
Automatic model discoveryNot included; enter one exact model id

Keeping the model as a plugin argument makes the privacy binding explicit: the same id is sent during ticket issuance and completion. Change the argument when you want to switch models.

Key and content handling

The plugin itself runs in RisuAI's sandboxed plugin environment. The api_key argument is currently an ordinary visible text input stored in RisuAI's plugin configuration—not a secure, write-only secret field. The plugin can read it to request a ticket. Protect the device, RisuAI data, and plugin settings as you would any client that holds an API credential.

RisuAI asks for periodic permission before a plugin provider runs. That consent dialog does not encrypt the saved key and does not change the network path.

The key is not attached to the completion request. RisuAI's generated prompt can still include character definitions, persona details, lorebook entries, memory, chat history, and your latest message. That content reaches AnonRouter's relay and the selected provider.

AnonRouter does not intentionally retain prompts or responses. Review the selected model's privacy label before sending sensitive material.

Why this is not AnonRouter compatibility mode

RisuAI can also call ordinary OpenAI-compatible endpoints. That setup would require a compatibility-enabled key and would put key identity and plaintext together at AnonRouter's compatibility broker. The plugin exists so RisuAI can use the stronger native ticket separation its custom-provider API makes possible.

Troubleshooting

The provider does not appear

Confirm the file was imported through Plugin Settings, the plugin is enabled, and its metadata begins with //@api 3.0. Reload plugins or restart RisuAI after upgrading from an older plugin API.

“Add a valid ar_ inference key”

Paste the complete inference key into the plugin's api_key argument. A management key beginning with arm_ cannot run inference.

“Ticket request failed: HTTP 404”

You are running 0.1.0, which mints against the wrong origin. No key, model or setting can fix it. Reimport the plugin as described in Already running 0.1.0?.

Ticket request returns 401 or 402

The key may be malformed, revoked, out of credits, or at its credit limit. A compatibility permission is not needed for this plugin.

Ticket model mismatch

Enter an exact current model id. The plugin binds the same id and output limit to both requests; a stale or unavailable route can still be rejected.

The reply is delayed and appears all at once

That is expected in version 0.1.1. RisuAI's provider API can accept a ReadableStream, but this plugin uses a non-streaming completion to keep ticket handling and error reporting straightforward.

RisuAI setup FAQ

Do I need to enable OpenAI-compatible access?

No. The plugin performs the native ticket exchange, so a standard inference key is the preferred credential.

Does this preserve AnonRouter unlinkability?

It preserves the separation inside AnonRouter: the control plane receives the key without the prompt, and the relay receives the prompt with only a single-use ticket. The local client necessarily has both. Risu Web's default network proxy can also see both calls, so use a direct desktop runtime when that additional correlation boundary matters.

Can the plugin contain several models?

This version uses one configurable model id. Change the plugin argument to switch routes. Automatic discovery and a model picker are possible future enhancements, not current behavior.

Sources and further reading

AnonRouter is an independent service and is not affiliated with RisuAI.

Or hand the whole thing to your agent

One prompt carries the entire setup. Give it to your agent, review what it configures, and you are done.

On this page