Archon's pluggable AI and storage provider layer — OpenAI, Tencent Cloud Hunyuan, and Tencent COS.
Cloud providers
Archon's AI reasoning stage and artifact storage run on a pluggable provider layer. Each provider is a real, fully built adapter behind one interface; which one serves a given workload is decided by environment configuration at runtime, and the live status is always inspectable. Archon never reports an unconfigured provider as live.
Check the current status at any time:
curl https://archonaudit.xyz/api/providersAI enrichment providers
The AI Reasoning stage enriches deterministic findings through a single interface (enrichFindings(batch) → schema-validated JSON). Two adapters sit behind it:
| Provider | Selected by | Credentials | Notes |
|---|---|---|---|
| OpenAI | AI_PROVIDER=openai (or fallback) | OPENAI_API_KEY | gpt-4o-mini by default; override with OPENAI_MODEL. |
| Tencent Cloud Hunyuan | AI_PROVIDER=hunyuan | TENCENT_HUNYUAN_KEY | Uses Tencent's OpenAI-compatible endpoint (https://api.hunyuan.cloud.tencent.com/v1, overridable via TENCENT_HUNYUAN_BASE_URL); hunyuan-turbo by default. |
Selection logic. AI_PROVIDER wins when that adapter's credentials are present. Otherwise Archon falls back in order OpenAI → deterministic templates. Every scan log records which provider served each enrichment batch, and batches that fail or time out fall back to deterministic explanations for exactly those findings, with the cause logged per batch.
ELFA is not an LLM provider. An earlier build shipped a generic chat-completions adapter labeled "ELFA". ELFA is a crypto/market data API, not an inference endpoint, so that adapter was removed from the AI chain — it could only ever 404. If ELFA is integrated in future it will be an external data enrichment feature behind its own env flag, never an AI provider.
Honesty rule. An adapter without credentials is inert: it exists in the codebase, it is listed by /api/providers with the env vars it is waiting on, and it is never represented as serving traffic. The Tencent Hunyuan adapter ships fully built and activates the moment hackathon computing credits provide a key — no code change required.
Artifact storage
| Store | Role | Credentials |
|---|---|---|
| IPFS pinning | Primary for proof metadata | IPFS_PIN_TOKEN (+ IPFS_PIN_PROVIDER) |
| Tencent Cloud COS | Live — best-effort backup for report/proof artifacts | TENCENT_COS_SECRET_ID, TENCENT_COS_SECRET_KEY, TENCENT_COS_BUCKET, TENCENT_COS_REGION |
Tencent COS is active (region ap-hongkong): proof preparation additionally writes the canonical proof artifact to proofs/<reportId>.json in the configured bucket as a best-effort backup, verifiable at /api/providers (storage.backup → tencent-cos: active). A failed or unconfigured backup never blocks the primary IPFS/Postgres path — it is logged and reported as exactly what it is.
Operational notes
- Provider calls are bounded: batched findings, a 75-second per-call timeout with a single transient (429/5xx) retry, and per-finding schema validation on every response. Malformed output falls back to deterministic templates for exactly the affected findings rather than corrupting a report.
- No provider decides what a finding is. Detection stays deterministic (static analysis + Mantle rules); providers only write explanations, remediation text, and patch suggestions, which remain clearly attributed.
/api/providersexposes configuration status only — names of missing env vars, never values.