docs: add Vast.ai GPU offer discovery

[piotrgerke-reef]

Adds a browser-harness domain skill for reading Vast.ai GPU offers through the same-origin bundles endpoint. Documents canonical GPU names, storage-aware pricing, safe field projection, dynamic-offer rechecks, and the driver-version filter caveat. Contains no credentials, account data, or user-specific offer IDs.

---

Summary by cubic

Documents a browser-harness domain skill for discovering Vast.ai GPU offers via the console’s same-origin JSON endpoints, replacing card scraping and preventing unsafe data dumps. No runtime behavior change; docs only.

• Opens https://cloud.vast.ai/create/ in the user’s session and forbids printing cookies or API keys.
• Uses GET /api/v0/gpu_types/?status=active and the canonical_name for GPU filters.
• Queries offers via GET /api/v0/bundles/?q=... with a minimal, stable filter set.
• Clarifies pricing and filter pitfalls: set allocated_storage before comparing dph_total; include storage_cost and inet costs; duration is in seconds; reliability2 is fractional; recheck dynamic offers before renting; filter driver_version client-side.
• Promotes safe field projection to avoid full object dumps.
• Adds domain-skills/vast-ai/offers.md; includes no credentials or user-specific IDs.

^{Written for commit db6f890. Summary will update on new commits.}

[browser-harness-review]

✅ Skill review passed

Reviewed 1 file(s) — no findings.

[cubic-dev-ai]

2 issues found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="domain-skills/vast-ai/offers.md">

<violation number="1" location="domain-skills/vast-ai/offers.md:47">
P3: The "Canonical GPU names" section instructs "Use canonical_name in bundle filters; do not guess display names," but the bundle query example then hardcodes the GPU string `"gpu_name": {"eq": "RTX 5090"}` instead of deriving it from the `gpu_types` result fetched just above. The example also reproduces the detected display string as a literal rather than plugging in `gpu["canonical_name"]`, so it demonstrates the same guessing pattern the doc warns against. Point the example at the lookup result (e.g. build the filter value from `gpu["canonical_name"]` / the fetched `gpu_types` list) or clarify that `gpu_name`'s filter value here equals the canonical name, so the two sections don't contradict each other.</violation>

<violation number="2" location="domain-skills/vast-ai/offers.md:70">
P2: When the same-origin bundles API returns a non-200/error payload, `x.offers || []` silently turns it into an empty list, so a post-page-load auth/session failure is indistinguishable from "no offers." The initial auth-wall guard only covers page-load redirects. Check `x.success`/`x.error` (and the HTTP status) and surface the error instead of returning `[]`.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: When the same-origin bundles API returns a non-200/error payload, x.offers || [] silently turns it into an empty list, so a post-page-load auth/session failure is indistinguishable from "no offers." The initial auth-wall guard only covers page-load redirects. Check x.success/x.error (and the HTTP status) and surface the error instead of returning [].

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At domain-skills/vast-ai/offers.md, line 70:

<comment>When the same-origin bundles API returns a non-200/error payload, `x.offers || []` silently turns it into an empty list, so a post-page-load auth/session failure is indistinguishable from "no offers." The initial auth-wall guard only covers page-load redirects. Check `x.success`/`x.error` (and the HTTP status) and surface the error instead of returning `[]`.</comment>

<file context>
@@ -0,0 +1,104 @@
+)
+raw = js(
+    f"fetch({json.dumps(url)}).then(r => r.json())"
+    ".then(x => JSON.stringify(x.offers || []))"
+)
+offers = json.loads(raw)
</file context>

[cubic-dev-ai]

P3: The "Canonical GPU names" section instructs "Use canonical_name in bundle filters; do not guess display names," but the bundle query example then hardcodes the GPU string "gpu_name": {"eq": "RTX 5090"} instead of deriving it from the gpu_types result fetched just above. The example also reproduces the detected display string as a literal rather than plugging in gpu["canonical_name"], so it demonstrates the same guessing pattern the doc warns against. Point the example at the lookup result (e.g. build the filter value from gpu["canonical_name"] / the fetched gpu_types list) or clarify that gpu_name's filter value here equals the canonical name, so the two sections don't contradict each other.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At domain-skills/vast-ai/offers.md, line 47:

<comment>The "Canonical GPU names" section instructs "Use canonical_name in bundle filters; do not guess display names," but the bundle query example then hardcodes the GPU string `"gpu_name": {"eq": "RTX 5090"}` instead of deriving it from the `gpu_types` result fetched just above. The example also reproduces the detected display string as a literal rather than plugging in `gpu["canonical_name"]`, so it demonstrates the same guessing pattern the doc warns against. Point the example at the lookup result (e.g. build the filter value from `gpu["canonical_name"]` / the fetched `gpu_types` list) or clarify that `gpu_name`'s filter value here equals the canonical name, so the two sections don't contradict each other.</comment>

<file context>
@@ -0,0 +1,104 @@
+
+query = {
+    "cpu_arch": {"in": ["amd64"]},
+    "gpu_name": {"eq": "RTX 5090"},
+    "num_gpus": {"eq": 1},
+    "gpu_ram": {"gte": 30000},
</file context>