<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Privacy on API Coding</title>
    <link>https://apicoding.com/tags/privacy/</link>
    <description>Recent content in Privacy on API Coding</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 05 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://apicoding.com/tags/privacy/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Routing LLM Requests by Token Count, Privacy Tag and Cost Ceiling From One Config File</title>
      <link>https://apicoding.com/routing-llm-requests-by-token-count-privacy-tag-and-cost-ceiling-from-one-config-file/</link>
      <pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/routing-llm-requests-by-token-count-privacy-tag-and-cost-ceiling-from-one-config-file/</guid>
      <description>&lt;p&gt;LLM routing usually starts as &lt;code&gt;if&lt;/code&gt; statements. One service picks the cheap model for ticket summaries. Another hardcodes the strong model because it needs tool calling. A third has a comment reading &amp;ldquo;never send this to the cloud&amp;rdquo; directly above a fallback that sends it to the cloud when the local server times out. Changing a model, a price or a provider means editing all three.&lt;/p&gt;&#xA;&lt;p&gt;The router worth building is a small one: ordered rules over properties you can compute before the request leaves, written like an nginx config in a single file, with no database and no UI. Input size, whether tools or images are present, a data classification tag, a cost ceiling for the single request, which upstreams are healthy. One binary on a cheap VPS reads the file, accepts the OpenAI request shape and picks where each request goes. The rule that justifies the exercise is that privacy routing fails closed.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
