<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: skedaddle</title>
    <description>The latest articles on Forem by skedaddle (@skedaddle).</description>
    <link>https://forem.com/skedaddle</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3930342%2F3433155f-16b2-4cb1-ab3c-f02c087b8a1b.png</url>
      <title>Forem: skedaddle</title>
      <link>https://forem.com/skedaddle</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/skedaddle"/>
    <language>en</language>
    <item>
      <title>I Built an AI API Directory Because OpenAI-Compatible Is Not Enough</title>
      <dc:creator>skedaddle</dc:creator>
      <pubDate>Thu, 14 May 2026 03:19:13 +0000</pubDate>
      <link>https://forem.com/skedaddle/i-built-an-ai-api-directory-because-openai-compatible-is-not-enough-37l7</link>
      <guid>https://forem.com/skedaddle/i-built-an-ai-api-directory-because-openai-compatible-is-not-enough-37l7</guid>
      <description>&lt;p&gt;Developers do not need another “best AI API provider” list.&lt;/p&gt;

&lt;p&gt;Most lists collapse into the same problem: a few affiliate links, some vague pricing claims, and no clear way to verify whether a provider actually supports the model, Base URL pattern, payment method, or billing behavior a real project needs.&lt;/p&gt;

&lt;p&gt;So I built a more boring thing: an AI API directory.&lt;/p&gt;

&lt;p&gt;Not a leaderboard.&lt;br&gt;&lt;br&gt;
Not a recommendation engine.&lt;br&gt;&lt;br&gt;
A structured directory of observed facts.&lt;/p&gt;

&lt;p&gt;The idea is simple: before wiring a third-party AI API provider into Codex, Cursor, Claude Code, or your own app, you should be able to compare a few concrete fields:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;supported providers and models&lt;/li&gt;
&lt;li&gt;OpenAI-compatible or Anthropic-compatible API behavior&lt;/li&gt;
&lt;li&gt;custom Base URL support&lt;/li&gt;
&lt;li&gt;pricing notes&lt;/li&gt;
&lt;li&gt;payment methods&lt;/li&gt;
&lt;li&gt;invoice support&lt;/li&gt;
&lt;li&gt;referral or recharge rules&lt;/li&gt;
&lt;li&gt;public verification sources&lt;/li&gt;
&lt;li&gt;traffic and domain signals when available&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The important shift is this:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;“Compatible with OpenAI” describes an API shape. It does not describe trust, uptime, pricing, ownership, or support quality.&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;That distinction matters.&lt;/p&gt;

&lt;p&gt;A provider can expose an OpenAI-style endpoint and still differ wildly in model names, streaming behavior, rate limits, credit expiration, recharge rules, error formats, and whether pricing is even visible before login.&lt;/p&gt;

&lt;p&gt;For small experiments, that might be fine.&lt;/p&gt;

&lt;p&gt;For developer tools, internal agents, or production workflows, those details are the product.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why a Directory Instead of a Ranking?
&lt;/h2&gt;

&lt;p&gt;Ranking sounds useful, but it hides too much judgment.&lt;/p&gt;

&lt;p&gt;If I say “Provider A is better than Provider B,” that may be true for one person who needs Claude access, Alipay recharge, and a cheap test balance. It may be wrong for someone who needs invoices, stable OpenAI-compatible endpoints, or multi-model routing.&lt;/p&gt;

&lt;p&gt;So the directory takes a different approach:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Collect providers.&lt;/li&gt;
&lt;li&gt;Normalize the fields.&lt;/li&gt;
&lt;li&gt;Show what can be verified.&lt;/li&gt;
&lt;li&gt;Let people filter by their actual use case.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;This is closer to documentation than marketing.&lt;/p&gt;

&lt;p&gt;The page currently groups providers around search intents such as:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;AI API directory&lt;/li&gt;
&lt;li&gt;OpenAI API proxy&lt;/li&gt;
&lt;li&gt;Claude API proxy&lt;/li&gt;
&lt;li&gt;cheap OpenAI API&lt;/li&gt;
&lt;li&gt;OpenRouter alternatives&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Each intent becomes a landing page, but the underlying data stays structured.&lt;/p&gt;

&lt;p&gt;That means the same provider can appear in different contexts without duplicating the source of truth.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Engineering Lesson
&lt;/h2&gt;

&lt;p&gt;The surprisingly hard part was not building the UI.&lt;/p&gt;

&lt;p&gt;The hard part was deciding what counts as a useful fact.&lt;/p&gt;

&lt;p&gt;“Supports GPT-4” is less useful than:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;what exact model names are exposed?&lt;/li&gt;
&lt;li&gt;is the endpoint OpenAI-compatible?&lt;/li&gt;
&lt;li&gt;does it require a custom Base URL?&lt;/li&gt;
&lt;li&gt;does streaming work?&lt;/li&gt;
&lt;li&gt;is pricing public or login-gated?&lt;/li&gt;
&lt;li&gt;what payment methods are listed?&lt;/li&gt;
&lt;li&gt;when was the information last checked?&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Once those fields exist, the frontend becomes straightforward: search, filter, compare, and link to deeper provider profiles.&lt;/p&gt;

&lt;p&gt;The stack is intentionally simple:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Astro&lt;/li&gt;
&lt;li&gt;TypeScript&lt;/li&gt;
&lt;li&gt;Content Collections&lt;/li&gt;
&lt;li&gt;React only for interactive islands&lt;/li&gt;
&lt;li&gt;structured JSON content for provider profiles&lt;/li&gt;
&lt;li&gt;static output deployed to Cloudflare Workers&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This works well because the data is mostly content, but the user experience needs interactivity.&lt;/p&gt;

&lt;p&gt;Astro handles the content pages.&lt;br&gt;&lt;br&gt;
React handles the searchable directory UI.&lt;br&gt;&lt;br&gt;
The content collection schema keeps the provider data from drifting into chaos.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Bigger Point
&lt;/h2&gt;

&lt;p&gt;AI infrastructure is moving fast, but developer decisions still need boring verification.&lt;/p&gt;

&lt;p&gt;A nice homepage is not enough.&lt;br&gt;&lt;br&gt;
A low price is not enough.&lt;br&gt;&lt;br&gt;
“OpenAI-compatible” is not enough.&lt;/p&gt;

&lt;p&gt;The real question is:&lt;/p&gt;

&lt;p&gt;Can this provider be understood, compared, tested, and replaced without turning the whole project into glue code?&lt;/p&gt;

&lt;p&gt;That is what the directory is trying to answer.&lt;/p&gt;

&lt;p&gt;Here is the page: &lt;a href="https://ccnavx.com/directory/ai-api-directory/" rel="noopener noreferrer"&gt;https://ccnavx.com/directory/ai-api-directory/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Next, I am thinking about adding more explicit test result fields: streaming behavior, error format, model alias mapping, and minimum viable curl examples for each provider.&lt;/p&gt;

&lt;p&gt;Because at the end of the day, the best AI API provider is not the one with the loudest claim.&lt;/p&gt;

&lt;p&gt;It is the one whose behavior can be verified before it touches production.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>api</category>
      <category>opensource</category>
      <category>webdev</category>
    </item>
  </channel>
</rss>
