Generally you should only have two models in the pool per domain. I wrote some of my learnings building a router here: https://try.works/first-principles-of-model-routing

The trick is to rarely switch, or switch at task boundaries. Often the conclusion of routing is actually "this one model is actually at the pareto front for this task, just use it always".

and caching is related to performance too ofc

Ans: we rarely switch, often times it's just a "switch to using this model for your agent"

Thanks! We are going to add continual RL via Tinker soon too

Router and model optimization from traffic is the main differentiator

They make money on enterprise plans: https://www.experientiallabs.ai/pricing#enterprise

Look at the Intelligence features in the Enterprise plan:

* Per-prompt model optimization

* Caching

* A model you own, trained on your traffic

the business model, I suspect, is classic rug-pull in some time after building user base.

proof: boldly claiming being open source in literally first sentence, while cowardly hiding on-by-default telemetry (WTF??) in truly last paragraph of readme.

sorry to sound harsh, but this is typical old era playbook here.

in the era of AI, fortunately, such products has much lower value. people and VCs didn’t yet tune to it.

Yep! One interesting example is often Opus 5 on low reasoning ~= Opus 5 on high reasoning.

For the online signal, we use a LLM judge with a rubric calibrated offline by the user via TUI. UX of the calibration is a major focus area. Semantic caching is interesting, open to supporting it but not currently planned.

Looks like first PR is June 24th: https://github.com/experientiallabs/experiential/pull/1

So, two months. Still impressive!

See you soon

Yep! If you look at the commit history that's exactly what happened.