The evolution of the AI ecosystem has radically transformed the way we work. Not long ago, interaction was linear: you opened a single assistant and entrusted every request to it. Today, especially for those working in technology, it is normal to use a mix of local models, advanced cloud services, and autonomous agents (such as Codex or Claude Code) every day, capable of reading the file system, modifying code, and running commands.
With this fragmentation, deciding which tool to use has become complex. Choosing the model is only one part of the problem. A request may be simple yet contain confidential information; a complex task may require reading proprietary code. The model's capabilities, the destination of the data, and the powers of the invoked program must be considered together, while keeping the respective decisions distinct.
It is to address this architectural need that I am developing PA Router. The first environment of use is the developer's, on their own machine, through the terminal (CLI/REPL).
The acronym stands for Policy Aware, but it carries a second meaning that is just as crucial to me: Pubblica Amministrazione (public administration). Anyone who manages IT and digital transition in structured contexts knows well that compliance and data security are not "add-on features". PA Router was born as a control layer to place in front of tools: not to replace them, but to define the perimeter of what is admissible according to strict rules, even before evaluating their performance.
The Perimeter Before Optimization
Model routing is often approached as an optimization problem: choosing the service that offers the best trade-off between quality, cost, and latency. Excellent systems such as RouteLLM represent this approach well.
PA Router introduces a prior decision, inverting the logic. The policy determines the set of admissible targets; the routing chooses within that set. This separation is hardwired into the code: the routing module receives only candidates that have already been admitted. It cannot turn a denial into a low score and then compensate for it because a cloud model turns out to be much smarter or cheaper. Before selection, availability, required capabilities, data class, permitted destination, context window, and spending limits are checked. A forbidden path stays excluded.
Structural Privacy and Local Classification
The technical difficulty of a task and the sensitivity of the data are independent quantities. Relying exclusively on optimization to decide the routing means tackling the problem in the wrong order.
In PA Router, the request and its context are analyzed locally before being sent. The system uses deterministic detectors for contact details, tax codes, and credentials, supported by an optional ONNX model to recognize entities (names, addresses) and a term-based detector for special categories (e.g., health).
Data is operationally labeled into classes: public, internal, personal, sensitive, secret and unknown. The destination is governed by well-defined trust zones: the same machine (LAN), proprietary infrastructure within the European Union (private_eu), providers with a data processing agreement (third_party_dpa), and generic third parties.
The router avoids improper equivalences: a data processing agreement (DPA) does not automatically prove that processing takes place within the EU. PA Router applies configured technical constraints and makes its decisions verifiable, without claiming to replace the legal assessment of GDPR compliance.
Uncertainty is part of the logical model: when a detector fails to complete its analysis, only one retry is allowed. If the incompleteness persists, the state becomes unknown and the turn may be denied. The absence of a successful classification is never interpreted as the absence of risk.
Models, Programs, and the Execution Environment
From an architectural standpoint, PA Router is a modular monolith. CLI, text interface, workers, and API share the same engine. State, memory, and history are stored locally in an embedded SQLite database (with encrypted vectors and an in-RAM lexical index), without relying on external database servers.
The system has adapters for Ollama, OpenAI-compatible services, Anthropic, and interfaces to agentic CLIs such as Codex, Claude Code, and OpenCode. It is precisely with agents that a crucial game is played. An agent requires different attention than a simple chat API: it can read the workspace and run commands. PA Router treats it as a program to be strictly supervised. Agents are launched in a controlled environment (via Job Object/cgroup, without intermediate shells), and the granted capabilities derive from the session's profile and fence (fence).
In this hybrid architecture, operational continuity (handover) goes through the router's sessions. A handover to another service creates a new session and subjects the context to the privacy checks again, ensuring security even when moving from a local LLM to a cloud agent.
Where It Stands Relative to What Already Exists
It would not be correct to present the inclusion of privacy and policy in routing as an invention of PA Router. OpenRouter already applies restrictions on providers; LiteLLM acts as an excellent gateway, handling pre-call guardrails; vLLM Semantic Router includes local PII detection to route or block traffic.
However, these tools are primarily designed as serving infrastructure between an application and the backends. Even in agentic scenarios, they leave state management to the client.
What sets PA Router apart is the combination: local classification, explicit admissibility, supervision of agentic CLIs, structured sessions, local memory, and a reusable engine, all gathered into a personal execution environment. It is not a proxy, but a governance layer that moves decisions from the "user's head" to configurable, repeatable policies.
Project Status and Release Outlook
I'm not interested in describing abstract architectures. PA Router is a working application, with a local candidate (0.2.0-beta.2) that has been snapshotted and stress-tested.
The project has been publicly released, having reached a satisfactory level of stability in its main components, the routing mechanism, and the packaging. Some aspects still need refinement, however, particularly the semantic reliability of the retrieval systems. For example, tests on the original corpus revealed limitations in memory injection, with recall values that can still be improved. I chose to go ahead with the release anyway, distinguishing the maturity of the core features from the areas that are still evolving. The work will continue with targeted efforts to progressively improve the system's precision, retrieval capability, and overall robustness.
What I want to make available is not another way to switch from one model to another, but a tool in which the choice of LLM is only the last decision in a security chain that begins with the data.