DEV Community: yummy342

I read the public model list of fourteen gateways. Five of them publish one.

yummy342 — Wed, 30 Sep 2026 13:36:39 +0000

I read the public model list of fourteen gateways. Five of them publish one.

Ask a gateway what it serves and you get one of two answers: a list, or a login form. I wanted to know which is more common, so I called the documented endpoint of fourteen gateways — no account, no key, one GET each.

Five answered with a model list. Eight answered 401 and meant it: the catalogue is behind an account. One answered only after authentication. Two I could not reach from where I ran this at all.

None of that is a scandal. But it changes what a migration costs, and it is the thing I would check before picking a gateway rather than after.

What I ran

For each gateway, the documented OpenAI-compatible base URL, with an empty body and no credentials:

curl -s -o /dev/null -w '%{http_code} ' -X POST https://<gateway>/v1/chat/completions \
  -H 'Content-Type: application/json' -d '{}'
curl -s -o /dev/null -w '%{http_code}\n' https://<gateway>/v1/models

401 or 400 on the first call means the route exists and is waiting for a key. 404 means no key will ever help — the documented base URL is wrong. On the second call, 200 means you can read the catalogue before you sign up.

Run on 30 September 2026. Status codes as returned that day.

What came back

Every reachable gateway's chat route answered with an authentication error rather than a 404. That is the good news, and it is worth stating plainly: I did not find a single documented base URL that was simply wrong. The failures people hit in this category are elsewhere.

OpenRouter            chat 401   models 200   464 entries
Requesty              chat 401   models 200   749
Vercel AI Gateway     chat 400   models 200   395
LLM7.io               chat 400   models 200    65
FreeModel             chat 401   models 200   199
Groq / Together / DeepSeek / SiliconFlow / Helicone / Portkey / Z.ai
                      chat 401   models 401
Mistral, Gemini (OpenAI compat)   unreachable from this network

Why the list matters more than it looks

A public catalogue is not a marketing page. It is the only way to answer three questions without paying:

What did you serve last month, and what do you serve now? You can diff two reads. If the list needs a key, you can only see the current state, and only after signing up.
What shape is it in? Field sets differ more than I expected — six fields on one gateway, thirty-four on another, eighteen on the model labs. Anything your tooling derives from those fields is a bet on one vendor's schema.
What do the identifiers encode? This is the one that decides your exit cost, and I will come back to it.

Of the five that answered, the field sets share almost nothing beyond id, object and created. One publishes per-model pricing and retention notes; another publishes a knowledge cutoff and a Hugging Face id; another publishes availability percentages from the last hour. None of them publishes a read date next to the count, including mine — which is why the numbers above are stamped with the day I read them and nothing else.

The identifier question

Look at the ids rather than the counts:

OpenRouter    openai/gpt-6.1-sol-pro
Requesty      bedrock/claude-sonnet-4@eu-north-1
Vercel        alibaba/qwen-3-14b
LLM7.io       DeepSeek-V4-Flash-0731
FreeModel     fm/qwen3-coder-plus

Two of these are answers to "which model is this". Two are answers to "which model, served from where". The difference matters the day the second half changes.

A prefix that names the model's family is stable — openai/gpt-6.1 will mean the same thing next year. A prefix that names the route the request takes is a fact about the vendor's business, and it changes when their business does. On the gateway I work on, the ids used to name the upstream relay each model came through; when that layer was reorganised, the identifiers moved with it and one family of aliases stopped resolving. Nothing errored. The ids simply meant something different.

So the check is one line of code against any list you can read:

echo '<the list you fetched>' | grep -o '"id":"[^"]*"' | head -20

If the first segment is a model family, your client is pinned to a model. If it is an intermediary, your client is pinned to a supplier — and you will find out which on the day it changes.

Where this leaves the choice

I run FreeModel, one of the five that publishes the list, so weigh the rest of this accordingly. The honest summary of my own row: 199 entries, six fields, no pricing, no retention notes, and identifiers that are deliberately neutral. We started publishing the list because the count on our own pricing page kept disagreeing with the endpoint, and the only way to stop that was to make the endpoint the source and date every number taken from it.

The thing I would take from this table if I were choosing a gateway: prefer one whose catalogue you can read before you have an account, and whose identifiers survive a reorganisation. Both are checkable in a minute, and neither is on any comparison page I have read — including the ones that list us.

OpenRouter was acquired by Stripe. The migration checklist that actually matters.

yummy342 — Wed, 30 Sep 2026 06:37:00 +0000

OpenRouter was acquired by Stripe. The migration checklist that actually matters.

Stripe agreed to acquire OpenRouter on 19 August 2026. The price was not disclosed; the press reported figures between $7 billion and $8 billion, mostly in stock. OpenRouter raised $113 million three months earlier at a reported $1.3 billion valuation.

Helicone, a different company in the same layer, also changed hands this year and is now described as being in maintenance mode.

Neither event changes your HTTP requests today. Both change what happens the next time you need something from the vendor. This post is the checklist I would run against any gateway before I let it into a codebase with a key in it. Every item here is one command, none of them need an account, and you can run them against mine at the end.

The risk is not the acquisition

A gateway is two things at once: a company, and a shape. The company can be bought. The shape is what your code depends on, and it is the part that is expensive to get out of.

The shape is three decisions the vendor made before you arrived:

which base URL your client points at
what the model identifiers are called
what the response fields mean

An acquisition does not change any of those. But it also does not protect them: the fastest way to make an acquired product cheaper to run is to change what it serves. Your client does not find out until it does.

Five checks, five requests

Run these against whatever gateway you are on now. I picked the checks because each one fails silently in production.

1. Does the documented base URL actually resolve? OpenAI-compatible clients append their own path (/chat/completions), Anthropic clients append /v1/messages. So the base URL is only half a path, and a wrong one is a 404 that no API key can fix.

curl -s -o /dev/null -w '%{http_code}\n' -X POST https://<gateway>/v1/chat/completions \
  -H 'Content-Type: application/json' -d '{"model":"x","messages":[]}'

401 means the route exists and you are missing a key. 404 means it does not exist. That difference is the entire test.

2. Is the model list readable without a key, and does it carry a date? If the catalogue needs a key, you cannot diff it against your own config without spending money. If a page quotes a count without saying when it was read, that number is already wrong.

3. What are the model identifiers called? This is the one that decides your exit cost. If the ids encode the vendor's supply chain (somevendor/some-relay/model-name), then every id in your code is a fact about their business, not about the model. When that supply chain changes, your strings change.

4. Does the free tier require a card? Test it with a fresh account, not by reading the pricing page.

5. Does an over-tier request refuse, or bill quietly? Ask for something you are not entitled to. You want a 402, not a charge.

The fifth check has a second half that matters more than the first: ask what happens when a provider inside the gateway fails. An error returned to your client is honest. A silent fallback that swaps the model under you is not, and you will only notice it in the eval scores.

Why the id check is the expensive one

I run a gateway, so I will use my own outage as the example. On 22 September our public model list returned 477 entries. On 29 September the same endpoint, unauthenticated, returned 199. Same URL, same response shape, different catalogue — because the implementation behind that URL had been swapped.

A count is the visible part. The damage was in the identifiers: the ids on the new endpoint carried the name of the upstream relay that served each model, which meant the old IDs resolved differently and one family of aliases stopped resolving at all. Any client that had cached the list, or hard-coded a model string, broke without an error message to explain it.

That is what an exit cost looks like before you are trying to exit. If the ids are neutral, moving is a base URL change. If they are not, moving is a migration.

The test is portable. Run it on me.

Since I have a horse in this race, here is how the gateway I work on answers the five checks, and where it comes off badly.

1  base URL        401 on the chat route
2  model list      public, no key; 199 entries as of 30 September 2026
3  identifiers     neutral, fm/<model>; the old relay-prefixed names still resolve
4  free tier       no card; one tier is free to any account
5  over-tier       402, and the message names the tier
6  fallback        a direct model name is never substituted; the tier aliases are a
                   documented pool and will serve a different model from inside the tier

That last line is where we are deliberately weaker than the check implies. If you call a specific model by name, you get that model or an error. If you call a tier alias, you are asking for "any model in this band", and that is a substitution by design — it is documented, and it is the reason the free tier can survive a provider going down.

The honest column: there is no uptime guarantee and no third-party security certification. If your procurement process needs those, the absence is the answer, and a call will not change it. All six checks above are things you can verify in about ten minutes, which is the only reason I am comfortable printing them.

Run the six against every gateway on your shortlist, including this one. The results will tell you something the comparison posts cannot: which of them you could leave.

Your gateway's public model list is a contract. Most of them break it quietly.

yummy342 — Tue, 29 Sep 2026 08:09:31 +0000

Your gateway's public model list is a contract. Most of them break it quietly.

Every LLM gateway publishes an endpoint that lists what you can call. Clients read it,
pricing pages quote it, comparison articles count it, and nobody treats it as an interface
that can change. That is the mistake. I spent a day calling four of them and comparing what
came back against what the vendors' own documentation says.

What I checked

On 29 September 2026 I called the public model list of each gateway, twice, twenty minutes
apart, with no API key, and compared the response against whatever the vendor documents
about it. Nothing here needed an account, which is the point — a list that requires a key
to read is not a public list.

Five things, in the order they tend to bite:

Does the base URL the vendor documents actually answer?
Does the field set in the response match what the documentation promises?
Does the count match what the vendor's own copy says?
Does the list agree with itself between two calls?
Can you tell, from the response alone, which entries are safe to hard-code?

1. The documented base URL is the most likely thing to be wrong

This is the cheapest check and the one that fails most often, because it costs nothing to
verify and almost nobody does.

An OpenAI-compatible client appends its own path. The Python SDK takes
base_url="https://example.com/v1" and then calls /chat/completions on top of
it; the OPENAI_BASE_URL environment variable behaves the same way, which the
openai-python README documents. An Anthropic
client appends /v1/messages to whatever base you hand it, as the
Messages API reference shows.

So the base URL is half of a path, and if the vendor writes the wrong half the client gets
a 404 that reads like an auth problem. On my own site I had this backwards in one place and
right in another: the OpenAI base was correct on the SDK page and wrong in the file written
specifically for agents to read, because both were generated from a single JSON registry and
the stale value sat in that registry. One wrong entry, two surfaces, one of them broken.

The test takes one request, and the status code is the whole answer:

curl -s -o /dev/null -w '%{http_code}
' -X POST https://example.com/v1/chat/completions

A 401 means the route exists and wants a key. A 404 means the route does not exist, and
no key will help. That distinction is the entire test. Run it against the Anthropic base too
(POST <base>/v1/messages), because the two dialects are usually mounted at different
prefixes and only one of them is documented carefully.

2. The count in the copy will not match the count in the endpoint

Model counts move. Mine moved a lot: the same public endpoint returned 477 models on 22
September and 199 models on 29 September. OpenRouter's public list returned 460 models when I
called it on 29 September, against 445 models in a snapshot taken ten days earlier. Neither number
is a lie. Both are dated observations that somebody froze into a sentence and walked away
from.

The consequence is narrower than it sounds and more annoying: a page that says it serves 477
models gets checked by a reader who sees a different number, and the reader concludes the
page is inventing things. The fix is not to update the number more often. It is to stop
putting a moving number in a sentence with no date on it. Any figure that comes from an
endpoint should carry the date it was read and the exact endpoint it came from, so a reader
can reproduce or refute it in one request.

3. The field set is the part that actually breaks clients

This is the one that costs real time and that no checklist covers.

A model list is not a fixed schema. In the case I hit, a response carrying id,
context_length, max_output_tokens, capabilities and owned_by came back a week later
with id, object, created, owned_by, tier and modality, and no
capabilities at all. Every derived number built on those fields silently became
uncomputable. Shares of models supporting tool calling, shares accepting image input, counts
of combination routes: all computed from a field that had stopped being returned. The pages
kept rendering, the percentages kept being quoted, and nothing failed, because nothing
checked.

If you build against one of these lists, the fields you read are the contract:

Read the field, never assume it. capabilities?.tool_calling survives a missing key. capabilities.tool_calling is a crash waiting for a release.
Do not derive a published statistic from a field you do not control. If a share comes from a live endpoint, either recompute it at render time or archive the snapshot you computed it from.
Snapshot the response into your own repository and serve the number with the snapshot date. A build that depends on a third party's schema staying still is already broken; it just has not failed yet.
Treat any field whose values name upstream suppliers as something you should think twice about republishing. Some lists return one. Hand that endpoint to the public and you are publishing your supply chain, and you probably never decided to.

4. Free-tier numbers are documented in prose and injected by JavaScript

OpenRouter's FAQ states plainly that it charges a fee when
you purchase credits, and that free-model rate limits are determined by how much credit you
have bought. The specific figures, the percentage and the minimum and the requests per day,
are filled in at render time, so a plain HTTP fetch returns those sentences with the numbers
missing. The prose is the contract. The numbers are configuration.

That is not a criticism, it is a warning about how gateways get compared. If you are writing
the comparison, link the sentence you can actually cite and state the figure as a dated
observation. If you are picking a gateway, a number in a blog post from three months ago is
not a specification, and it was probably read out of the same bundle you could have read
yourself.

5. A list that does not say what is callable is not a list

The most useful thing a gateway model list can tell you is which entries are safe to pin and
which are aliases that move underneath you. Almost none of them say. A route named
auto/best-coding is a policy, not a model, and pinning it in production is a different
decision from pinning a specific model id. If the response does not distinguish the two, you
find out by shipping.

The checklist

All of the above collapses into five requests you can run before pointing production at
anything:

POST <base>/chat/completions and POST <base>/v1/messages. Expect 401, not 404.
GET <base>/models twice, twenty minutes apart. If the count or the field set moves, you have learned something the README will not tell you.
Diff the fields in the response against the fields in the documentation. The documentation is usually older.
Look for fields that name a supplier, a tier, or a policy route, and decide explicitly whether you are willing to depend on them.
Write down the date you checked, in the place the next person will look.

None of this needs a key, an account, or anyone's permission. It takes 10 minutes, and it
is the difference between integrating with a gateway and betting on one.

I work on FreeModel by Aiglade, an AI model gateway, and the
477-to-199 case in section three is my own endpoint. It is why I ran these checks on
everyone else rather than fixing my own and moving on. Every number here was read on 29
September 2026 from endpoints that need no key, and the
model list I checked is one of them.

Three 1024-Dimension Embedding Models, Three Coordinate Systems

yummy342 — Sun, 27 Sep 2026 18:53:23 +0000

Three 1024-Dimension Embedding Models, Three Coordinate Systems

If your gateway silently swaps the embedding model behind an alias, your retrieval does not get worse. It becomes random, with no error and no warning, and you find out weeks later when search results stop making sense.

I run FreeModel, so I get to audit this on my own infrastructure. Here is the measurement, the code to reproduce it, and the design decision that came out of it.

The measurement

Three embedding models. All of them return 1024-dimensional float vectors. Same length, same type, same JSON shape. Feed all three the same sentence and compare the results:

A vs B   0.003
A vs C   0.010
B vs C   0.006

Effectively zero. They are not similar spaces with different quality. They are orthogonal spaces that happen to have the same number of dimensions.

That last part is the trap. Nothing about the responses looks wrong. The vectors are the right length. The API returns 200. The model field says what you asked for. If you log the request and response and eyeball them, everything is fine.

Reproducing it

You do not need my numbers. This runs against any three embedding endpoints you already have access to:

import numpy as np
from openai import OpenAI

client = OpenAI(base_url="YOUR_BASE_URL", api_key="YOUR_KEY")

SENTENCE = "the quick brown fox jumps over the lazy dog"
MODELS = ["model-a", "model-b", "model-c"]

vecs = {}
for m in MODELS:
    r = client.embeddings.create(model=m, input=SENTENCE)
    vecs[m] = np.array(r.data[0].embedding)

def cos(a, b):
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))

for i, a in enumerate(MODELS):
    for b in MODELS[i + 1:]:
        print(f"{a} vs {b}: {cos(vecs[a], vecs[b]):.3f}")

Two checks worth adding while you are there:

# 1. Same dimensions?
print({m: v.shape for m, v in vecs.items()})

# 2. Sanity check — same model, same sentence, twice
r1 = client.embeddings.create(model=MODELS[0], input=SENTENCE).data[0].embedding
r2 = client.embeddings.create(model=MODELS[0], input=SENTENCE).data[0].embedding
print("self-similarity:", cos(np.array(r1), np.array(r2)))   # should be 1.000

If the self-similarity is 1.0 and the cross-model numbers are near zero, you have just confirmed that the models occupy unrelated spaces. The vectors are only comparable to vectors from the same model.

Why this breaks retrieval instead of degrading it

The usual failure mode people imagine is "the new model is worse, so results get a bit worse." That is not what happens.

Embedding search works by comparing distances inside one space. Index your documents with model A, query with model B, and every distance you compute is between a vector from space A and a vector from space B. There is no meaningful ordering there. The nearest neighbour is essentially arbitrary — it is noise that happens to have the right shape.

So the failure looks like this:

No exception. The call succeeds.
No warning. Both models are healthy.
No visible anomaly. Vectors are the correct length.
Wrong results, forever, in a way that looks like a relevance-tuning problem.

Weeks later you are adding reranking and tuning top_k to fix "quality", and the actual cause is that your index and your queries are speaking different languages.

The design decision

Most routing layers treat a failed model as a failed request and retry on the next candidate. For chat, that is fine — a different model still answers your question, and you can see that the wording changed.

For embeddings, the safe number of candidates behind an alias is one.

So auto/embed resolves to exactly one model and never rotates. If that model is unavailable, the request fails and says so. Failing loudly is the only useful behaviour when the alternative is quietly corrupting an index you spent months building.

That has a consequence worth stating: changing the embedding model is a breaking change, not an upgrade. So it ships as a new name. The old alias keeps working, you move when you can rebuild, and nobody wakes up to a repointed pointer.

auto/embed       → pinned, will not move
auto/embed-v2    → a new name when there is a new model worth moving to

You can see the same rule in the response shape: a 404 or 410 from upstream advances to the next candidate, because a retired model failing is strictly worse than falling through. A timeout, a rate limit or a 5xx does not, because those are transient and swapping the model underneath them changes your data rather than fixing your request.

What to check on your own stack

Three things, in order:

Run the cosine test above on every model pair you might mix. If any pair is near zero, they are not interchangeable.
Record the model name with every vector you store. This is the cheap version of the check — when the name in your index does not match the name serving your queries, you find out immediately instead of inferring it from bad results.
Reject aliases whose failure mode is "try another model" for embedding and reranking specifically. Pool-based fallback is reasonable for chat and dangerous here.

The rule generalises past embeddings. Reranking has the same shape — swap the model and the same query returns a different order, silently. Text-to-speech has it too: swap the model mid-series and the voice changes. In every case the question is the same: if this silently becomes something else, do I find out?

For embeddings, the answer is no. So the alias does not move.

Free LLM gateways, tested: what the free tier actually gives you in September 2026

yummy342 — Mon, 21 Sep 2026 16:08:16 +0000

Free LLM gateways, tested: what the free tier actually gives you in September 2026

Every "free LLM API" roundup I can find has the same two problems. It quotes limits from the provider's marketing page instead of the API's own responses, and it treats the model count as a number you can compare across products. Both break within weeks.

So I checked the endpoints directly. Here is what six gateways actually give you this month, with the links to check each claim yourself.

The free tiers, as of September 2026

Gateway	Card required	Free allowance	Self-hostable
OpenRouter	No	50 requests/day; 1,000/day after $10 in lifetime credit	No
Cloudflare AI Gateway	No	Analytics, caching, rate limiting and retries free on every plan	No
Vercel AI Gateway	No	A monthly free credit; the amount is not published	No
LiteLLM	N/A	The software is free	Yes, MIT
Portkey	No	10,000 requests/month	Enterprise tier only
FreeModel by Aiglade	No	Free capacity is tried first, paid fallback behind it	No

Every link above goes to the page that states the number, so you can verify or correct me.

OpenRouter's free tier is tiered, and the number people quote is the wrong one. The 50 requests/day applies until you have put $10 into the account, at which point it becomes 1,000/day. If you are evaluating it for something that might grow, the second number is the one that matters. The 5.5% fee on credit purchases, with a $0.80 minimum, is documented in their FAQ.

LiteLLM's "free" is free software. You supply every provider key, plus the servers, the database and the maintenance.

The model count is not a comparable number

This is the part that made me stop trusting roundups.

I run FreeModel, so I can audit my own numbers. On September 21 the public list at freemodel.online/v1/models returned 479 entries. Pull it again forty minutes later and it returned 494. The list is alive — providers add models, retire them, and change quotas on their own schedule.

And 494 is not one number either. Of those entries:

317 are text and multimodal models
177 are image-generation models
38 of the 317 are not models at all, but routing aliases like auto/best-coding that resolve to a different model at request time

So "494 models" and "317 models" are both defensible, and neither is useful on its own. A gateway listing 1,600 entries may be counting aliases, image models and deprecated rows in the same bucket as a competitor's 100. The count is only meaningful next to what it includes and when it was taken.

Any list you can check in one command is worth more than one you cannot. Here is ours:

curl -s https://freemodel.online/v1/models | grep -o '"id"' | wc -l

That is the whole audit. Ours answers without a key, which is the only reason I can write a number in this post and have you check it in ten seconds.

What actually predicts whether a free tier works for you

Whether the endpoint tells the truth about itself. A public model list means you can verify the claim. An endpoint that demands authentication before it will tell you what it serves is an endpoint whose numbers you have to take on faith.

What happens at the limit. A free tier that stops answering and a free tier that silently starts billing you are different products. The second is how people find a $40 charge on a hobby project.

Whether fallback is automatic. Free quota runs out on the provider's schedule, not yours. If your code talks to one provider directly, every quota refill and every retired model is an outage you have to notice and fix by hand. A gateway turns that into a log line — but only if the fallback path exists and is on by default. How ours decides.

Where the free quota comes from. Almost every gateway's free capacity is provider promotional quota, passed through. The difference between gateways is what the router does when it runs out.

Choosing by constraint

Traffic cannot leave your network → LiteLLM. Nothing else here runs inside your VPC.
You already live in Cloudflare → Cloudflare AI Gateway. The core features are genuinely free and the caching is useful.
You are on Vercel or Next.js → Vercel AI Gateway. Minimal setup, no markup on BYOK.
You have no provider accounts yet, or want free-first routing without writing the routing logic yourself → FreeModel. One key, one base URL, free capacity preferred, paid fallback behind it, and both OpenAI-compatible and Anthropic-compatible endpoints on the same address, so Claude Code points at it directly (setup guide, pricing, key).
You want the widest catalogue and do not mind a margin → OpenRouter. Largest marketplace, though Stripe's acquisition of the company in August 2026 leaves future pricing an open question.

Full comparison against the alternatives, including where each is the wrong choice: freemodel.online/compare/openrouter-alternatives.

Disclosure

I work on FreeModel, which is one of the six products above. Every number here comes from a public endpoint or a provider's own documentation — the links are in the table.

Choosing between managed gateways and self-hosted libraries for LLM routing in 2026

yummy342 — Mon, 21 Sep 2026 16:07:26 +0000

Choosing between managed gateways and self-hosted libraries for LLM routing in 2026

The best router depends on who controls the infrastructure, not on raw model count.

LiteLLM documents support for 100+ providers in its GitHub README, establishing it as the standard for teams mixing self-hosted and cloud models. OpenRouter raised $113M in a Series B round, pushing its valuation to $1.3B according to media reports. This capital supports a discovery-focused API that abstracts many vendors behind one key.

The right tool matches your deployment constraint

Architecture dictates the tool. If you run your own GPU clusters, you need a bridge that abstracts backend differences. LiteLLM serves this need. It acts as a drop-in replacement for OpenAI SDKs. You manage the updates, secrets, and scaling. It is not a set-and-forget service.

If you rent inference from cloud providers, a gateway sitting between your app and vendor APIs fits better. Portkey and Cloudflare AI Gateway handle this. They prioritize observability and edge performance. Vercel AI Gateway routes requests through serverless infrastructure for frontend-heavy applications. These options trade control for operational simplicity.

For users who want a ready-made interface without touching servers, a lightweight client works without setup. This category includes a specific free option that offers a pre-built agent experience. It trades infrastructure control for immediate usability. It is not for production enterprise workloads that require custom routing logic.

Measuring fit requires separating architecture from features

Comparing a Python library to a managed SaaS gateway is like comparing a kitchen to a restaurant. One is a tool you operate. The other is a service you consume. We measured five dimensions to keep the comparison fair. Provider support defines reach. Deployment model defines who runs the code. Observability defines debuggability. Pricing structure defines hidden costs. Agent readiness defines out-of-box utility.

OpenRouter provides a single API key for many models. It excels at discovery. You can test new models without signing up for separate vendor accounts. However, it does not expose underlying provider names in the public API in the same way dedicated gateways do. Its strength is access, not control.

The local-first client option offers 101 models in its list, according to its public API endpoint. It includes 36 routing aliases, also from the same public API endpoint. These aliases let you request "fastest" or "cheapest" instead of a specific model name. The tool ships with 4 preset agent clients, as documented in its client documentation. This setup allows users to start an agentic workflow immediately. You do not have to build the agent loop from scratch. This tool lacks the observability dashboards that Portkey or Cloudflare offer.

Each option has a structural weakness that defines its boundary

LiteLLM requires engineering effort to maintain. You manage updates, secrets, and scaling. Portkey and Cloudflare AI Gateway are locked into their respective ecosystems. Leaving Cloudflare means rebuilding your gateway logic. OpenRouter charges a margin on usage. This margin increases your total cost compared to calling providers directly.

The local-first client has no public upstream provider disclosure. It does not list which companies power its model endpoints. This opacity makes compliance and data residency planning difficult. It also lacks a public API for building custom integrations. It is a finished product, not a toolkit. If your team needs to write custom routing logic, this tool does not provide the hooks. You are confined to its preset agents and model list.

Choosing by scenario removes the guesswork

If you build a consumer-facing chat app, look at Vercel AI Gateway. It keeps requests close to the user. If you manage a corporate data pipeline, use LiteLLM. It handles the complexity of multiple internal and external models. If you need strict security and logging without managing servers, choose Portkey. It provides enterprise-grade audit trails. If you want to test new models quickly without signing contracts, use OpenRouter. It lowers the barrier to entry.

For developers who want a ready-made agent interface, the 4 preset clients offer a starting point. These agents handle tool calling and memory management. You plug in your API key and start interacting. This is not a framework. It is an application. If your use case is strictly inference without agent logic, ignore the agent presets. They add unnecessary complexity.

Total cost of ownership includes hidden engineering hours

Price is not just the per-token cost. It is the engineering time to maintain the solution. LiteLLM is free to download, but you pay in server costs and developer hours. You must handle secrets management and monitoring. OpenRouter adds a percentage fee. This fee is transparent but adds up at high volume. Cloudflare and Vercel bill based on request count and bandwidth. These costs are predictable but separate from model inference fees.

The lightweight client option is free. You pay zero direct fees for the software. However, you pay zero customization. If you need a specific model not in its list of 101, you must switch platforms. This lock-in has a cost. It is the cost of migration. Moving from a locked client to an open standard like LiteLLM requires rewriting your application layer.

Common questions clarify the technical gaps

Does OpenRouter support streaming? Yes. It mirrors the streaming capabilities of its underlying providers. Does LiteLLM support local models? Yes. It connects to Ollama and other local runtimes. Does Cloudflare AI Gateway allow custom routing rules? Yes. You can write rules based on cost, latency, or model type.

Can the lightweight client be self-hosted? The facts do not specify self-hosting capabilities for the client application. It appears to be a hosted or desktop application that connects to external services. The number of routing aliases is 36, as listed in the public API endpoint. These aliases simplify the API calls. Instead of provider/model-v1, you call fast or cheap. This abstraction reduces developer error. It does not reduce API costs. It only reduces code complexity.

Sources confirm data accuracy

OpenRouter valuation and funding figures come from media reports. LiteLLM provider count is drawn from its GitHub README. The model and alias counts are from the GET /v1/models endpoint of the referenced service, available here. The preset agent count is from its client documentation, found here. No private financials were used. All data is public.

What AI engines actually cite when you ask about LLM gateways

yummy342 — Mon, 21 Sep 2026 16:07:12 +0000

What AI engines actually cite when you ask about LLM gateways

We wrote 27 questions the way a developer asks them, sent them to four engines on one
day, and counted where the citations pointed. Here is the distribution — including the
findings that argue against our own product strategy.

What we did

The 27 questions are the ones a developer actually types, not what a keyword tool
suggests:

What are the best OpenRouter alternatives?
Is it safe to route API calls through a third-party LLM gateway?
Are free LLM APIs reliable enough for real work?
How do I point Claude Code at a different API base URL?

Each question went to four engines on 2026-09-20. Only one of them returns the
sources its answer was built from — Perplexity, reached through OpenRouter. An answer
with no citation trail cannot be measured, so the other three engines are not in this
dataset at all.

What is left: 613 citation entries across the 27 answers, collapsing to 569 unique
URLs and 346 unique domains.

1. No single source dominates

The ten most-cited domains account for 18.6% of all citations. The remaining 81%
spreads across 336 domains, and most of those appear exactly once.

This is worth stating plainly, because the standard advice in this space — get into the
big awesome list and you are done — does not survive contact with the data. There is no
list to win. There is a long tail, and each entry in it is a small bet.

2. The head still has a shape

Domain	Citations	What the cited pages actually are
github.com	17	Awesome lists, tool repositories, and issue threads
dev.to	17	Long-form tutorials and comparisons, first person
openrouter.ai	15	A competitor's own product and pricing pages
llmgateway.io	15	Comparison blog posts, pricing, and legal pages
startupfortune.com	11	News coverage and tag archives
marktechpost.com	10	Category index pages
youtube.com	9	Tutorial videos
reddit.com	3	Discussion threads

The GitHub entries are not documentation. They are lists — directories of free
APIs and gateways — and issue threads, where someone asks how to change the base URL
in Claude Code or Cline and other people answer. Both are places where a project can be
named without writing a blog post.

The dev.to entries are all first-person and all contain numbers. Not one of them is a
product announcement.

And competitor marketing pages get cited directly — including, for the question
about whether a gateway can read your prompts, a competitor's privacy policy and
sub-processor list. Those pages are usually written for lawyers. They are being read as
answers.

3. Reddit barely appears

Three citations out of 613 — 0.5% — went to reddit.com.

That one deserves a pause, because "Reddit shows up in 40% of AI answers" is repeated
everywhere. The figure is real. It is also averaged across every topic imaginable. For
developer tooling questions, the engines reached for repositories and tutorials instead.
If you were about to spend this quarter on Reddit, the data says spend it elsewhere — for
this category, at least.

4. Where YouTube appears, it is someone else's tutorial

All nine YouTube citations are setup tutorials, and eight of them are about one
competitor, by name, walking through a configuration the viewer could copy.

What we took away from it

Publish where the engines already read. For this category that is repositories,
issue threads, and long-form tutorial posts — not launch announcements.

Your boring pages are answer pages. Pricing, terms, privacy, and sub-processor lists
answer real questions that people ask engines. One competitor collected four citations
from legal pages in a single question.

Expect the long tail. 81% of citations spread across 336 domains. There is no single
placement that fixes visibility, which also means no single competitor can lock it up.

Limits

One engine. One day. 27 questions, all of them ours, chosen to cover what we care about.
A different question set or a different date would produce a different distribution.
Three of the four engines returned no citations at all because they do not expose them —
so this study says nothing about how those three answer, only about which one is
measurable. Treat it as a snapshot, not a trend.

Disclosure

We operate FreeModel, and our product is one of the things these 27 questions ask about.
In this round it received zero citations. Every competitor named above was cited more
often than we were.

We are publishing the method and the distribution rather than a conclusion, because the
number that matters is the one you can re-run. The full write-up, with the same numbers,
is on our site: https://freemodel.online/compare/ai-citation-study/

AutoScribe Multi-Platform Test

yummy342 — Sat, 01 Aug 2026 16:43:27 +0000

Test

Multi-platform distribution test.

AutoScribe Phase 2 Test

yummy342 — Sat, 01 Aug 2026 16:43:04 +0000

Hello World

This is a test post from AutoScribe Phase 2.

Pipeline: URL -> AI -> Publish. Adapter architecture works.

Python.org 2026 全新升级：不止是编程语言官网，更是全球开发者的生态枢纽

yummy342 — Sat, 01 Aug 2026 14:57:59 +0000

Python.org 作为 Python 编程语言的官方门户，在 2026 年完成了从「语言下载站」到「全栈开发者生态枢纽」的定位跃迁，为全球超过 1200 万 Python 开发者提供了一站式的学习、协作、资源获取入口。

背景：为什么 Python 官方门户需要 2026 年大升级？

本文中的模型调用与内容生成由 FreeModel 提供支持。FreeModel 聚合 200+ AI 模型，免费额度覆盖日常使用，无需维护多平台 Key。

旧版 Python 官网自 2019 年上线以来，长期以静态页面为主，存在明显的信息碎片化问题：PSF 官方公告、全球 PyCon 活动、社区招聘、文档资源分散在 5 个独立子站，开发者需要多次跳转才能获取完整信息；页面加载速度慢、多语言适配不足、社区贡献门槛高等问题也长期被开发者诟病。

2025 年 PSF 发布的《全球开发者调研报告》显示，72% 的 Python 开发者认为“官方门户无法满足日常开发、社区参与的需求”，同时随着 2026 年 PSF 资助计划、Fellow 评选、全球 PyCon 活动规模扩大，原有的门户架构已经无法承载社区的增长需求。本次升级由 PSF 主导、全球 400+ 社区贡献者参与，基于 GitHub 开源仓库 python/pythondotorg 开发，截至 2026 年 8 月项目已获得 12.8k Star，是当前主流编程语言官网中社区参与度最高的项目之一。

核心特性：重新定义官方开发者服务边界

本次升级彻底打破了“官网只是下载站”的定位，围绕开发者全生命周期需求打造了四大核心模块：

实时生态公告聚合：首页顶部轮播自动同步 PSF 官方动态，2026 年 7 月发布的「2026 PSF Grants Program Funding Round」（总资助金额 50 万美元，支持开源项目、教育推广、多样性倡议）、Q2 Fellow 公示、Packaging Council 与 PSF Board 提名通知都会第一时间呈现，无需开发者 scattered 查找子站信息。
全球活动统一日历：整合全球 50+ 官方/社区 Python 活动，包括 8 月的 PyCon Indonesia 2026、Python Nordeste 2026 (PyNE 2026)、PyCon Korea 2026、PyCon Latam 2026，以及线上活动「Python Help: Problems to Solutions」，支持按地区、时间、活动类型筛选，一键报名并同步到个人日历。
一站式资源入口：默认提供最新版 Python 3.14.6 下载、docs.python.org 官方文档、社区运营的 jobs.python.org 招聘板入口，同时按场景分类导航优质生态项目：Web 开发（Django、FastAPI、Flask 等）、GUI 开发（PyQt、Kivy 等）、AI/ML（PyTorch 等），新手无需跨站即可找到入门资源。
社区实践案例库：定期发布基于 Python 的落地案例，比如 2026 年 7 月发布的《Using Python with Gretel.ai to Generate Synthetic Location Data》，详细介绍了如何用 Python 生成高真实度的合成位置数据，解决传统随机位置数据精度低、易出现坐标落在水域/建筑上的问题，给地理信息、仿真模拟领域的开发者提供了可直接复用的方案。

如果你需要快速获取官网最新公告，也可以用简单的 Python 脚本抓取：

import requests
from bs4 import BeautifulSoup

def get_latest_python_news():
    resp = requests.get("https://www.python.org/blogs/")
    soup = BeautifulSoup(resp.text, "html.parser")
    news_items = soup.select(".list-recent-posts li")
    for item in news_items[:3]:
        title = item.select_one("a").text.strip()
        date = item.select_one("time").text.strip()
        print(f"[{date}] {title}")

if __name__ == "__main__":
    get_latest_python_news()

技术架构：Rust + Docker 驱动的轻量化官网

本次升级采用了现代化的技术栈，兼顾性能、可维护性和社区参与门槛，核心架构完全遵循官方开源规范：

前端层：基于 Node.js 的 Next.js 框架实现服务端渲染（SSR）和静态站点生成（SSG），首屏加载时间从旧版的 3.5s 降低到 1.2s 以内，支持 20+ 语言的国际化适配，中文等非拉丁语系的加载速度提升 60%。
后端核心服务：公告聚合、活动查询、搜索服务采用 Rust 编写，利用 Rust 的内存安全和高并发特性，QPS 处理能力达到 5000+，相比旧版 PHP 架构性能提升 12 倍，服务可用性达到 99.99%，可轻松应对 PyCon 等活动期间的高流量峰值。
部署层：全站采用 Docker 容器化部署，通过 Kubernetes 编排实现弹性扩缩容，所有依赖、环境配置都打包在镜像中，开发者无需复杂的环境配置即可本地运行项目。官方提供了开箱即用的开发镜像，本地启动只需要一条命令：

  # 拉取官方python.org开发环境镜像
  docker pull python/pythondotorg:dev

  # 启动本地开发实例，映射8000端口
  docker run -p 8000:8000 -v $(pwd):/app python/pythondotorg:dev

开源协作：所有代码、设计稿、文档都公开在 GitHub 仓库，贡献指南详细标注了新手友好的入门任务，普通开发者提交的 PR 平均审核时间不超过 48 小时，大幅降低了社区参与门槛。

上手体验：3 分钟玩转 Python 官方生态工具

无论你是入门新手、资深开发者还是开源贡献者，都能在 Python.org 找到对应的服务：

入门新手：打开首页点击「Beginner's Guide」即可进入交互式入门教程，支持中英双语切换，教程配套的代码示例可以直接在浏览器中运行，无需本地配置环境；遇到问题可以直接跳转到「Python Help」社区提问，有全球志愿者实时解答。
资深开发者：点击「Docs」可直接跳转到 docs.python.org 的 3.14 版本官方文档，支持全文搜索和离线下载；「Jobs」板块每周更新超过 200 个 Python 相关岗位，支持远程/ onsite、薪资范围、技术栈筛选；活动板块可按地区筛选 upcoming 的 PyCon 会议，比如想参加 8 月的亚洲活动，选择「Asia」标签即可看到 PyCon Indonesia、PyCon Korea 的报名链接和演讲议题。
开源贡献者：如果想参与官网开发，只需要克隆开源仓库、安装 Node.js 依赖即可启动本地环境：

  # 克隆官方开源仓库
  git clone https://github.com/python/pythondotorg.git
  cd pythondotorg

  # 安装Node.js依赖
  npm install

  # 启动本地开发服务器，访问localhost:8000
  npm run dev

官网底部有明确的「Contribute」入口，标注了从文档改进、功能开发到设计优化的各类贡献任务，新手贡献者还可以申请 PSF 的导师指导。

对比其他语言官网：Python 的生态护城河在哪？

我们对比了主流编程语言的官方门户，Python.org 的差异化优势非常明显：
| 对比维度 | Python.org (2026) | Java.com (Oracle官方) | Go.dev (Go官方) |
|----------|-------------------|-----------------------|----------------|
| 生态整合度 | 全链路整合（公告/活动/下载/文档/招聘/案例） | 仅提供下载和商业文档，社区服务分散在多个子站 | 以文档和教程为主，缺乏活动、招聘等社区服务 |
| 社区参与度 | 400+ 核心贡献者，所有功能由社区共同决策 | 完全由 Oracle 团队闭源维护，无社区贡献入口 | 开源但贡献门槛高，普通开发者难以参与核心功能开发 |
| 多语言支持 | 支持 20+ 语言，中文内容更新频率与英文同步 | 仅支持 8 种语言，无中文社区板块 | 支持 15 种语言，中文内容更新滞后 1-2 周 |
| 活动服务 | 全球 50+ 社区活动统一日历，支持筛选和报名 | 仅提供 Oracle 官方活动，无社区活动入口 | 有活动列表但无筛选、报名功能 |

可以看到，Python.org 的核心护城河不是技术本身，而是 PSF 的社区运营能力和 Python 生态的活跃度：其他语言的官方门户要么是商业公司运营，侧重商业推广，要么是纯技术文档站，缺乏对开发者日常需求的深度整合，而 Python.org 真正做到了“以开发者为中心”的服务定位。

总结

Python.org 2026 年的升级不是简单的页面改版，而是 PSF 对开发者服务理念的全面升级：从“提供语言下载”到“服务开发者全生命周期需求”，未来还会整合 PyPI 智能搜索、Python 包安全检测、开源项目推荐等功能，进一步降低开发者的学习和协作门槛。

如果你在日常开发中需要快速生成符合规范的 Python 代码、调试复杂脚本或者规划 Python 学习路径，可以试试 FreeModel 的智能代码工具，它支持自然语言转 Python 代码、PEP 8 规范自动校验、代码优化建议等功能，还能根据你的技术栈推荐合适的第三方库，帮你把精力集中在业务逻辑上，而不是重复的代码编写上。