Ethen topic
Model intelligence is the information needed to choose an AI model for a task: capabilities, benchmark evidence with its provenance, price, latency, and availability. Model routing is the decision itself: which model, provider, and configuration should handle a given request.
Routing is only as good as the facts it routes on. Ethen therefore separates who owns each model fact, shows Unknown when provenance is incomplete, and routes by elimination before ranking.
This page explains the territory. For live model data, use Ethen Model Intelligence and the Model Library. Faros is Ethen's flagship intelligence layer and first-party model identity. The Faros research program in the Ethen Research Lab treats routing as a research question, and most of its publications are protocols and syntheses rather than measured results.
By elimination. Capability gates, provider health, budget ceilings, and telemetry decide which models are eligible before any model is ranked or picked. Requests are bound to a project through the API key, so eligibility and budgets apply per project.
When benchmark provenance is incomplete, a number would imply a comparison the evidence cannot support. Methodology, freshness, and comparability gates decide what is displayed, and each model fact has a named owner.
Only if it beats them. The Research Lab survey argues that strong rules are the right baseline and that learned routers should have to show non-inferiority. A companion protocol defines that test, with propensity-logged data and decision rules. The protocol has not been run.
By replaying its own historical tasks against the new model to find regressions. The Research Lab describes this as model change assurance, in a research note and a separate protocol. Both are research, not shipped Ethen features.
Faros is Ethen's flagship intelligence layer and first-party model identity. It is separate from the Ethen workspace, and you can choose models directly or use Ethen AI Gateway without it. The Faros position paper frames routing as a choice of execution configuration, not just of model.
Eligibility is elimination: the Gateway discards every model that cannot serve a request before it ranks anything at all.
Most model comparisons answer a narrower question than their headline suggests. Here is how to find the real question, check whether the numbers are comparable, and read the gaps.
When a benchmark cell has no defensible value, Ethen Model Intelligence says so. This is how provenance and missing results control what readers see.
Ethen model metadata looks like one catalog, but every fact has a named owner. Here is how to tell who answers what.
A public model page is the last step in a longer chain: a route entry, a stored record, an acceptance decision, and a verified read.
A workflow-first checklist for deciding when a general chat, a specialized app, a control plane, or local execution fits — using Ethen's stated product boundaries.
One provider export produced three very different counts. Each count answers a different question — about delivery, identity, and publication.
Faros-program publications are position papers, a survey, research notes, and protocols. No routing experiment has been run yet.
A position paper reframing AI model routing as an execution-configuration decision across model, context, tools, verification, recovery, cost and risk.
A survey of learned LLM routing: what RouteLLM, RouterBench and LLMRouterBench show, why strong rules are the right baseline, and how to test non-inferiority.
A research protocol for an LLM routing experiment: strong-rule baselines, propensity-logged data, factorial cache controls, non-inferiority tests and decision rules.
Why AI routers need propensity logging from the first decision: candidate sets, selection probabilities and verified outcomes make off-policy evaluation possible.
A research note on model change assurance: replaying an organization's own historical tasks to find regressions before an LLM upgrade reaches real work.
A position paper stress-testing AI evaluation against 10× better models and 10× cheaper inference, and arguing that verification and assurance gain value.
Ethen invests in model intelligence because every decision about which AI model to use — made by a person, by Ethen's AI Gateway, or by Ethen's automatic model choice — is only as good as the facts behind it. Model intelligence is the knowledge needed to make that decision: what a model can do, what it costs, how it performs on which kinds of task, and where each of those facts came from. The model landscape changes too quickly, and public comparisons hide too much, for that knowledge to be assembled ad hoc. So Ethen builds it deliberately: every fact with a source and an owner, Unknown shown instead of guesses, eligibility decided before preference, and a long-term aim of connecting model choices to whether the resulting work actually succeeded.
The way to choose an AI model without guessing is to stop asking "which model is best?" and start asking "which model fits this job, under my constraints, at a cost I accept?". In practice that means seven steps: describe the job; filter out models that cannot do it or cannot meet your constraints; shortlist using evidence that matches your kind of task; test the shortlist on a handful of your own examples; compare the cost of good results rather than the price per token; pick a default and a fallback; and re-check when something changes. Ethen is built to support each step — from automatic model choice in Chat to sourced comparisons in Ethen Model Intelligence and eligibility checks in the AI Gateway — but the method works with any tools.
Better AI models do not make AI products obsolete; they change which parts of a product matter. Each model release removes some reasons to build: prompt tricks that compensated for a weaker model, savings from routing around price differences, interfaces that do little more than pass text to a model. At the same time, better models are trusted with longer and more consequential work, switched more often, and harder to check by eye — which makes the parts of a product that surround the model more valuable. Those parts are knowing what the AI actually did and whether it worked, controlling what it may touch and spend, recovering when long work is interrupted, testing that a model change will not break real work, keeping memory and data under the user's control, and interfaces built around the work rather than the chat. That is where Ethen invests.
Ethen is built around many AI models instead of one because no single model covers everything real work needs. Work spans different media — text, code, images, video, audio and speech — and the models that are best at each are different. Within any one kind of task, the strongest model is rarely also the fastest and cheapest. Some data may only be processed by certain models, or only on your own machine. Checking an AI's work is more trustworthy when the check does not come from the same model that did the work. And every model is eventually replaced, while the work people do with Ethen should outlast any one of them. A multi-model design lets Ethen fit each of those needs. To keep it from becoming chaos, Ethen relies on a shared body of sourced model knowledge, rules-first selection, and a clear record of which model did what.
Before adopting a new AI model, Ethen evaluates it against ten questions. Do we know exactly which model and version it is? Does it fill a gap — a medium, a task, a price or speed point, a local or open option — that Ethen cannot already fill well? Does it perform well on tasks like the ones people actually bring to Ethen, not only on public benchmarks? Is it reliable under real conditions? Will it change without notice? Do its data-handling terms and license allow the uses our users need? How does it behave with risky requests and untrusted content? Is its pricing clear and dated? Does it fit how Ethen calls models and tools? And where, if anywhere, should people see it? A model can be listed in our catalog with sourced facts long before it is qualified for a particular use, and qualified long before it is surfaced in a curated place like Ethen Chat. Each step requires its own evidence.
Should you upgrade to the newest AI model? Not automatically. Ethen sometimes holds back from the newest model because a model that is better on average can still be worse on the specific work people rely on — and averages hide exactly those regressions. A new version may follow formats differently, refuse different requests, call tools differently, cost more per finished task, run slower, or come with different terms. Prompts and skills tuned for the previous model may perform worse until they are adapted. So Ethen treats a new model as a candidate, not an upgrade: we test it on representative work task by task, look past the average to regressions, cost and behavior, switch kind of work by kind of work where it wins, keep tested versions pinned and a fallback available, and keep watching after a switch. Sometimes that means adopting a new model within days. Sometimes it means not adopting it at all.
The gap between AI benchmarks and real-world performance comes from what benchmarks leave out. A typical benchmark score measures accuracy on a fixed, public set of tasks, under one method, often from a single attempt, without cost or speed. Real work depends on much more: whether the model fits your inputs, outputs and tools; whether it succeeds every time rather than once; whether it is fast enough to work with; whether it actually uses the long context it accepts; what each good result costs; whether its behavior stays stable; whether it stops honestly when it cannot do something; how it handles instructions hidden in content; and whether its terms and deployment options fit your data. Benchmarks are a useful starting point. Usefulness is decided by these other dimensions, most of which you can test cheaply on your own work.
Good AI model catalog design starts with identity, not presentation. When Ethen reconciled a provider export of media models, 1,499 callable endpoints collapsed into 491 distinct model families, and only 128 of those families had enough substance to deserve a public page. Of the 491 families, 145 could not yet be classified by modality — the second-largest bucket after image. Working through those numbers taught us ten lessons: count what you mean; establish identity before editing anything; publish one page per family; treat publication as a quality gate; show unknown as unknown; invest in structured metadata over prose; never confuse catalog presence with a runnable model; do deterministic work before any language-model enrichment; expect snapshots to age; and give different consumers different granularity. This article explains each lesson for anyone building a catalog of AI models.
AI model families are the useful unit for comparing AI platforms, because a family groups every version and variant of one underlying model line under a name you can reason about. Model counts are not. A platform that advertises hundreds or thousands of models is usually counting endpoints — one model offered for several tasks, at several speeds, through several providers — plus aliases, superseded versions and entries that are listed but cannot actually be run. In Ethen's own September 2026 catalog snapshot, 1,499 endpoints represented 491 families. What matters for your work is not the count but whether the families you need for your tasks are present, runnable for you, backed by evidence, and stable over time, with sensible fallbacks. This article explains what a model family is, what large counts hide, and five questions to ask instead.
A gateway is a control point, not a shortcut. Use this guide to decide whether your integration needs one.
Pick the workflow before the model: a durable checklist for task fit, inputs, execution eligibility, and delivery checks.
As of October 2026, Ethen's work falls into five areas. We are organizing Ethen into focused apps that share one foundation. We are hardening that foundation for AI work that runs for minutes or hours: durable jobs, completion that depends on evidence, honest handling of unknown outcomes, and approvals tied to specific actions. We are building a model knowledge layer so people can choose models with sources rather than guesses. We are extending Ethen to local, on-device AI through Desktop. And Ethen Research Lab now publishes its research in public, with every paper labeled by evidence status. This update separates what our public posts describe as implemented from what is design direction, and it makes no launch or date commitments.
Ethen supports more than one AI provider because no single provider is the best fit for every job, available at every moment, acceptable under every data agreement, or stable in price and behavior over time. Using several providers gives Ethen resilience when one is degraded, a choice of the right model for each kind of work, options that meet different data-residency and contractual rules, and room to respond when models and prices change. Multi-provider support also has real costs: models behave differently across providers, there are more combinations to test, and fallback paths fail when they are rarely exercised. Ethen manages those costs with a few rules — check eligibility before preference, never break a data or contract rule to stay available, keep the state of a task independent of any one provider, and record which provider served each request.
AI products have a built-in honesty problem: their output sounds equally confident whether it is right, wrong, estimated or invented. Ethen treats that as a design problem, not only a model problem. Across the product, we try to keep four states of knowledge apart — known, estimated, unknown and not checked — and to show each for what it is. When a model fact lacks provenance, Ethen Model Intelligence shows Unknown rather than a guess. When an agent's action times out without confirmation, Ethen's mission system records the outcome as unknown rather than as success or failure. When Ethen Research Lab publishes a proposal, it says the proposal is untested. We do this because people rely on AI outputs more than the outputs deserve when uncertainty is hidden, and because a gap shown honestly is more useful than a gap filled with something plausible.
A research protocol testing whether model change assurance predicts live outcomes: paired replay, regression certificates, randomized rollout and false reassurance.
A research proposal for counterfactual evaluation of AI agents: replaying completed tasks under alternative models, tools, context and recovery strategies.
A methods paper on measuring capability transfer: whether AI agent skills keep working across model, tool and task changes, including negative transfer.
A benchmark design measuring whether AI agent capabilities survive changes of model, provider, tool interface, task family and harness, including negative transfer.
A research protocol for AI skill portability: a pre-registered event study of whether agent skills transfer, degrade or reverse after a frontier-model upgrade.