Plans & limits

The server is reachable on every plan. It never supplies a credential of its own, so you connect with your own key and the same quota and field gating apply as they would to any other client. What a plan changes is depth.

What changes by tier

Current pricing and quotas: vulnetix.com/pricing.

Gating is always visible

This is the part worth internalising, because it is where a naive integration gets security decisions wrong.

Where a plan withholds detail, the counts are still returned and the tool says explicitly that the records are withheld rather than absent. Calling vulnetix_exploits for Log4Shell on Community:

{
  "id": "CVE-2021-44228",
  "exploitCount": 19868,
  "activeSources": [
    { "source": "poc", "count": 15259 },
    { "source": "other", "count": 4507 },
    { "source": "crowdSec", "count": 101 },
    { "source": "vulnetixKev", "count": 82 }
  ],
  "exploitsBySource": [],
  "note": "Per-source counts are present but the exploit records themselves are empty. That is tier gating, not an absence of exploits. The enumeration requires a Pro plan. Treat `summary` and `activeSources` as authoritative for exploitation signal."
}

exploitsBySource is empty. exploitCount is 19,868. An empty list never means “no exploits exist”. Because the note travels with the data, your agent reads it too and will not conclude otherwise.

The same pattern applies to vulnetix_iocs, vulnetix_sightings and vulnetix_threat_actors, each carrying a gated boolean.

Quota

Counted per organisation on a 24-hour rolling window. Every tool result carries the current position in _meta:

"_meta": {
  "vulnetix/plan": "community",
  "vulnetix/rateLimit": {
    "limit": "unlimited",
    "remaining": "unlimited",
    "reset": "1786406400"
  },
  "vulnetix/upstream": { "calls": 1, "ms": 4889, "bytes": 2606569, "cached": false },
  "vulnetix/shaping": { "rawBytes": 2606569, "shapedBytes": 10613, "ratio": 0.00407 }
}

A capable agent can read remaining and pace itself.

When you run out

The tool returns an error result, not an HTTP 429, because a transport-level 429 makes clients retry the whole exchange:

Vulnetix daily rate limit exhausted for this organisation. The quota resets at 2026-08-11T00:00:00Z. Do NOT retry this call. Retrying cannot succeed until the quota resets and only burns further budget.

The wording is aimed at the agent, which will otherwise call the same tool again immediately. The server itself never retries a 429.

The AI layer and your tier

Five tools add a model-written analysis on top of the database result: vulnetix_triage_reason, vulnetix_secure_code_write, vulnetix_detection_rules, vulnetix_exploit_test, vulnetix_fix_plan.

That layer runs on Pro and above. On Community you still get the complete database result, plus:

"analysisSkipped": "AI analysis requires a Pro plan or above; this organisation is on 'community'. The deterministic result above is unaffected."

The analysis is additive by design, so it can never be the reason a tool fails. Pass ai: false on any of them to skip it.

Keeping usage down

• Prefer the default detail: "summary". full is 20× larger and you rarely need to enumerate.
• Use vulnetix_kev_status over vulnetix_kev when you care about one advisory.
• Cap list tools. limit exists on every one of them.
• Let the cache work. Identical requests within a tool’s TTL are served from Cloudflare’s edge and never reach the API. _meta["vulnetix/upstream"].cached tells you when that happened.