Core concepts
Providers and capabilities
Why the platform runs with zero credentials, and what adding a key actually changes.
The platform is fully functional with no credentials at all. It starts, it reports which variables would enable what, and it routes around whatever is absent. Adding a key and restarting is the only enablement step — there is no code path a new key unlocks.
Capabilities, not vendors
A caller asks for a capability — search the web, read a page, run code — and a manager picks who serves it. Several providers can answer the same capability, so losing one to a missing key loses that provider, not the run.
Ordering encodes cost as well as ability: a provider that reads a page for free is tried before one that renders it in a browser and bills for it.
Six states, not a boolean
"Unavailable" is not one thing, and collapsing the cases would repeat the mistake the evidence model exists to prevent:
| State | Meaning | Who fixes it |
|---|---|---|
healthy | Answering, and recently verified | — |
enabled | Usable, no credential needed | — |
missing_key | A credential is not set | A deployment task |
rate_limited | Throttled upstream | Clears on its own |
unavailable | The upstream is down | The upstream |
disabled | Switched off deliberately | An operator |
Previewing a plan
Before spending anything, you can ask what a request would do on this deployment — which steps would run, which are blocked, and which variable would unblock them.
curl "https://api.molthood.org/api/v1/providers/plan?request=audit%20https://example.com"