Getting Started

This tutorial shows how to use Chinook in a real workflow. The goal is simple: avoid unstable GPU offers before you deploy.

Start by scoring one offer. This tells you how risky it is.

{
  "host_id": 124171,
  "country_code": "ES",
  "price_per_hour": 0.076,
  "verified": false
}

Example response:

{
  "risk_score": 3,
  "stability_score": 97,
  "stability_label": "high"
}

This means the offer is very stable and suitable for longer runs.

---

Chinook gives you two key signals:

Use this simple rule:

---

Upgrade to Pro to unlock deeper insights.

{
  "expected_survival_minutes": 43204,
  "p_survival_6h": 0.96,
  "p_survival_24h": 0.94
}

This tells you:

If p_survival_6h drops below 0.5, you should avoid the offer for production workloads.

---

Instead of scoring manually, you can directly request the best available hosts.

{
  "filters": {
    "country_code": "ES",
    "max_price_per_hour": 0.10,
    "min_observations": 5
  },
  "limit": 5
}

Response:

{
  "results": [
    {
      "host_id": 124171,
      "stability_score": 97
    }
  ]
}

This is the fastest way to integrate Chinook into your workflow.

---

Typical usage patterns:

Example logic:


if stability_score < 70:
    skip_offer()
else:
    deploy()

---

When you are evaluating many offers at once, use bulk scoring.

This allows you to:

---

Summary

Chinook fits into your workflow like this:

This reduces failed runs, restarts, and wasted compute.