# AI use cases for Intent Route AI (Vincent-Xi08/IntentRoute-AI) Repo: [Vincent-Xi08/IntentRoute-AI](https://github.com/Vincent-Xi08/IntentRoute-AI) | Use cases: 5 | Page: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/ IntentRoute AI is an open-source Windows app that turns plain-language network intent into reviewed sing-box TUN routing rules, with optional OpenAI or local Ollama drafting. This file holds every use case of this repo. Each one starts with a "## " heading and ends with its URL. - Draft per-app proxy rules from plain language: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/draft-app-routing-rules-from-plain-language/ - Draft routing rules with a loopback-only model: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/draft-routing-rules-with-local-ollama/ - Audit saved routing rules for conflicts and shadowing: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/audit-routing-policy-for-conflicts/ - Predict which rule handles one app and destination: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/predict-which-rule-handles-one-connection/ - Create a routing rule from a running process: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/create-rule-from-running-process/ ## How to draft per-app proxy rules from plain language with Intent Route AI Repo: [Vincent-Xi08/IntentRoute-AI](https://github.com/Vincent-Xi08/IntentRoute-AI) | Difficulty: Intermediate | Time: 1 hour | Basis: From the README Describe the traffic you want routed and get a validated, disabled rule draft to review. **Who it is for:** A Windows user who wants Chrome or Cursor traffic for specific sites sent through a proxy, but finds hand-writing process, domain, and port rules error-prone. **The problem:** Many Windows applications do not expose useful proxy controls, and writing routing rules by hand is slow and easy to get wrong. **The outcome:** A reviewed set of disabled routing rules that you edit as needed and then enable yourself, with everything else staying direct. ### Steps 1. Get the IntentRoute AI release from its GitHub Releases page and start the app on Windows. 2. Run `[Environment]::SetEnvironmentVariable('OPENAI_API_KEY', 'your-api-key', 'User')` in PowerShell, then restart IntentRoute AI. 3. Select OpenAI, enter an intent such as the plain-language example in the README, and request a draft. 4. Review the preview and edit any draft field such as process, action, domains, ports, or protocol. 5. Accept the draft as disabled rules, then enable each rule you want as a separate action. ### Prompt to paste into your agent ```text Using the Vincent-Xi08/IntentRoute-AI repo, write a plain-language intent describing the traffic to route for , and walk through the OpenAI draft flow. Expected output: a list of disabled rules with process, host, port, protocol, and action fields. Verify that every rule is disabled until a user enables it. ``` ### Caveat The README calls this a v0.31.0 preview and warns that AI output can be incomplete or wrong, so every generated rule needs your review before it is enabled. Risk, credentials: The OpenAI key is read from the OPENAI_API_KEY environment variable, so keep it out of shared shells, screenshots, and logs. Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/ URL: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/draft-app-routing-rules-from-plain-language/ ## How to draft routing rules with a loopback-only model with Intent Route AI Repo: [Vincent-Xi08/IntentRoute-AI](https://github.com/Vincent-Xi08/IntentRoute-AI) | Difficulty: Intermediate | Time: 1 hour | Basis: From the README Use a locally installed Ollama model so the intent stays on 127.0.0.1 instead of going to OpenAI. **Who it is for:** A privacy-minded Windows user who wants AI-assisted routing drafts but does not want the intent sent to a cloud provider. **The problem:** Cloud drafting sends the typed intent and rule schema to OpenAI, which some users will not accept for their routing setup. **The outcome:** A routing rule draft generated by a local model, validated the same way, and added disabled for your review. ### Steps 1. Install Ollama and start its local service. 2. Run `ollama pull qwen3:8b` to install the model separately. 3. In IntentRoute AI, select Ollama (local) and choose the installed model from the list shown in the app. 4. Enter your intent, request a draft, and review each field before accepting it as disabled rules. 5. Open the Settings page and run the provider health check to confirm the model is reachable and installed. ### Prompt to paste into your agent ```text In the Vincent-Xi08/IntentRoute-AI repo, configure the Ollama provider with the model and generate a draft for the intent . Expected output: a disabled rule draft and a health report showing loopback reachability and that the model is installed. Verify that the app only queries 127.0.0.1 or ::1. ``` ### Caveat The README says the privacy and behavior of the installed model and runtime remain the user's responsibility, even though the app keeps requests on loopback. Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/ URL: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/draft-routing-rules-with-local-ollama/ ## How to audit saved routing rules for conflicts and shadowing with Intent Route AI Repo: [Vincent-Xi08/IntentRoute-AI](https://github.com/Vincent-Xi08/IntentRoute-AI) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README Run the local Policy Intelligence report to find duplicate, shadowed, and conflicting rules without any AI call. **Who it is for:** A user with a growing set of sing-box routing rules who suspects that an older rule is hiding or contradicting a newer one. **The problem:** Rule order matters in the generated route, and overlapping rules are hard to spot by reading the list. **The outcome:** A local report that lists exact duplicates, same-scope different outcomes, proven shadowing, and other findings, with links to the affected rules. ### Steps 1. Open the AI Policy Intelligence page in IntentRoute AI. 2. Wait for the background analysis to finish on the detached configuration snapshot. 3. Read the findings and select a row to navigate to an affected rule. 4. Fix the rules you want to change in the rule editor, then save through the normal configuration transaction. 5. Re-open the report to confirm that the findings you fixed are gone. ### Prompt to paste into your agent ```text Using the Vincent-Xi08/IntentRoute-AI repo, open the local Policy Intelligence report for the saved configuration at . Expected output: a list of findings with codes, categories, severities, and affected-rule counts. Verify that the report made no provider request and wrote no file. ``` ### Caveat The README states that a clean report does not prove that TUN creation, a proxy listener, upstream reachability, or any connection succeeded, because it only describes static configuration. Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/ URL: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/audit-routing-policy-for-conflicts/ ## How to predict which rule handles one app and destination with Intent Route AI Repo: [Vincent-Xi08/IntentRoute-AI](https://github.com/Vincent-Xi08/IntentRoute-AI) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README Enter one process, destination, port, and protocol to see the rule that would match it. **Who it is for:** A user who has several overlapping rules and wants to confirm what happens to one specific application's connection before enabling a change. **The problem:** Rule priority, order, and fallback make it hard to tell by inspection which action a given connection would get. **The outcome:** A three-valued answer (proven match, proven global fallback, or indeterminate) with an evaluation trace showing the rules considered. ### Steps 1. Open the AI Route Simulator page in IntentRoute AI. 2. Enter one exact process name, one concrete domain or literal IP address, one port, and TCP or UDP. 3. Run the simulation and wait for the bounded background evaluation to finish. 4. Read the result and the local evaluation trace, and open the proven matched rule if one is shown. 5. Change the query or the configuration to test another case, noting that the old result is hidden after either changes. ### Prompt to paste into your agent ```text In the Vincent-Xi08/IntentRoute-AI repo, run the Route Decision Simulator for the process , destination , port , and protocol . Expected output: a proven match, a proven fallback, or an indeterminate result with a trace. Verify that the simulator performed no DNS lookup, proxy probe, or configuration change. ``` ### Caveat The README calls the simulator a static what-if tool that does not observe traffic, so its result describes configuration semantics, not what a live connection would actually do. Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/ URL: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/predict-which-rule-handles-one-connection/ ## How to create a routing rule from a running process with Intent Route AI Repo: [Vincent-Xi08/IntentRoute-AI](https://github.com/Vincent-Xi08/IntentRoute-AI) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README Pick a live process in the app and turn it into a routing rule in one step. **Who it is for:** A Windows user who sees an application already running and wants its traffic routed without looking up its executable path. **The problem:** Finding the exact executable path and PID for an application and writing the rule by hand takes time and invites mistakes. **The outcome:** A new rule for the selected process, created through the normal configuration transaction and still subject to the usual enable step. ### Steps 1. Open the process-to-rule view in IntentRoute AI. 2. Search by name or PID to find the running application. 3. Select the process and create a rule from it with one click. 4. Open the rule constraints editor to add any host, IP-CIDR, port, protocol, or note limits. 5. Run Policy Intelligence to check the new rule for conflicts, then enable it if it is correct. ### Prompt to paste into your agent ```text Using the Vincent-Xi08/IntentRoute-AI repo, find the running process named and create a rule for it. Expected output: one new rule that shows the real executable path. Verify that the rule was added disabled and that the configuration was saved through the normal transaction. ``` ### Caveat The README says the rule is created through the normal configuration transaction, but enabling it and starting the sing-box runtime remain separate steps that you control. Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/ URL: https://dedupedai.com/use-cases/vincent-xi08-intentroute-ai/create-rule-from-running-process/