Routing Profiles

Routing profiles let a Radius organization expose named model defaults as model IDs. Instead of selecting a fixed model, select a profile such as cheap, balanced, or precise. Each profile has one default model, an optional maximum thinking level, and optional request transformations. An uploaded Auto Model policy may override the default with any other eligible model.

For compatibility, requests using model: "auto" resolve to balanced; auto is not advertised separately in model discovery.

Install the management skill

Auto Model policy management is provided by the radius-api skill in the core Radius extension package:

pi install npm:@earendil-works/pi-radius

Restart Pi or run /reload, then authenticate with /login radius. The policy belongs to the organization selected during that login.

You do not need to edit or upload policy code by hand. Ask Pi what behavior you want, for example:

Configure my Radius Auto Model policy so code reviews use a fast model and implementation work uses the strongest coding model.

The installed skill discovers the current Radius API, reads the organization's active policy, validates changes in the Radius sandbox, and uploads the new version.

How profile routing works

For each profile request, Radius:

1. Caps a requested thinking level when the profile sets a maximum.
2. Runs the organization's uploaded message rewriter, when present.
3. Runs the built-in transformations enabled by the profile.
4. Builds the normal set of available, request-compatible automatic-routing candidates.
5. Uses the profile's configured model directly when no Auto Model policy is uploaded.
6. Otherwise gives the policy the effective profile, request summary, sanitized conversation, and all eligible candidates. The configured model is input.defaultCandidateId when available; otherwise the policy receives a fallback candidate and can inspect input.profile.defaultModelId.
7. Sends the request to the selected model.

The built-in defaults are deepseek-v4-flash for cheap, kimi-k3 for balanced, and gpt-5.6-sol for precise. None has a thinking cap by default. If a configured default is unavailable and there is no routing policy, the request fails clearly rather than silently selecting an unrelated model.

A policy can consider estimated input size, tools, image or reasoning requirements, conversation text, and the effective profile:

export default {
  route(input) {
    if (input.profile?.id === "cheap" && input.request.estimatedInputTokens > 100_000) {
      const alternative = input.candidates.find(
        (candidate) => candidate.routeId === "gpt-5-nano",
      );
      if (alternative) return { candidateId: alternative.id, reason: "large cheap request" };
    }
    return { candidateId: input.defaultCandidateId };
  },
};

Profile selections are automatically pinned for an active session and renewed on each request. A profile-default or router change therefore affects new sessions but does not move an active one; a pin expires after one hour without activity or when its model becomes unavailable. Sticky state is scoped by effective profile, so the same conversation can make independent choices under different profiles. auto and balanced share the same effective profile identity.

Profile configuration

Open the organization's Profiles page to:

• enable or disable profiles;
• select one default model;
• optionally cap the requested thinking level;
• enable built-in Git diff, Git status, and grep compaction; and
• reset a shadowed built-in profile to its current service default.

All three built-in profiles enable Git diff, Git status, and grep compaction by default. Organization admins can disable the transformations individually; new custom profiles start with them disabled.

The uploaded router and rewriter remain organization-wide. Both receive the selected profile as input.profile, allowing one script to customize behavior by profile without duplicating source or policy history.

The built-in transformations run after the organization rewriter. Selecting the legacy auto alias uses the effective balanced profile and its configured transformations.

Scope and overrides

Profiles and uploaded policies are shared by everyone using the selected organization. Fixed model requests continue to use the fixed route and do not receive input.profile. The /radius prefer and /radius force provider controls do not override automatic profile routing.

Profile IDs share the model namespace. An enabled profile shadows a concrete model with the same ID. Disabled profiles are not selectable. Organization overrides can shadow built-in profiles; resetting an override removes the row and immediately restores the current built-in definition.

Open the organization's Policies page to inspect the active Auto Model source, view previous versions, or compare versions.