Powered by DGrid AI Gateway
FOUR-LIFE runs on DGrid.
DGrid is the agent's primary LLM path for narrative, content, risk, vision, consensus, and image work. The live rail below shows whether DGrid is serving now or whether the fallback chain is carrying traffic. Every successful DGrid call is hash-chained and periodically anchored on BNB Chain.
DGrid degraded
primary = — · last = checking
Breaker · closed · primary path
fails 0/3 · opened 0×
Live DGrid status needs attention
Judges should see a green DGrid rail before the demo. Current traffic is degraded or falling back, so the DGrid bounty story depends on restoring credits/connectivity and then publishing a fresh Merkle root.
DGrid share
0%
0 of 0 calls
Total LLM calls
—
since service boot
DGrid $ burn
$0
total across all: $0
Transient retries
0
0 fallbacks · 0 breaker skips
Chaos mode — live fallback demo
Deliberately inject DGrid failures to see the fallback chain engage live.
circuit breaker trips normally · disabling resets it
Resilient fallback chain
primary
dgrid
Every attempt is recorded — successful or failed. On transient 5xx we retry DGrid once before falling back. After 3 consecutive failures the circuit breaker opens for 30s, so we stop paying latency on a doomed primary.
On-chain attestation · cryptographic proof of DGrid usage
Every successful DGrid call is folded into a SHA-256 hash chain. Published tips are anchored on BNB Chain as self-transactions, while newer calls remain visibly counted as unpublished until the next anchor.
Current Merkle tip
a4300dba550bdfa798604ea4…10e24f7a18713f507e2e
commits to 5024 DGrid calls · 0 unpublished
Full call log (5024 entries) available at /api/dgrid/audit/calls — download + re-derive the chain yourself to verify the root.
Cost breakdown · USD spent per task / model
By task
no cost accrued yet
By model
no cost accrued yet
Task → model routing via DGrid
Remap via
DGRID_TASK_OVERRIDES="content=anthropic/claude-sonnet-4.5". All tasks default to the cheapest capable DGrid model for sustained operation.Self-optimizing leaderboard · per (task, model)
auto-tune: off
waiting for calls — leaderboard is empty until the router sees traffic
Multi-model consensus via DGrid · flagship capability
Fan a decision out to 3 DGrid models in parallel and vote. This is the defining DGrid-only behavior: one API, one auth, three models, one vote. FOUR-LIFE uses this for the DEFEND phase of every token's lifecycle.
Side-by-side model comparison via DGrid
One prompt. Three models. One API. Demonstrates the core DGrid value prop without the voting layer.
Recent calls
refreshes every 10s · 0 in ring
No calls recorded yet.
Integration surface for judges
GET /api/dgrid/stats — per-task routing, fallback counts, cost $
GET /api/dgrid/health — green/amber/red reachability
GET /api/dgrid/trace?limit=N — last N calls, with chain tip + cost
GET /api/dgrid/leaderboard — per-(task,model) rolling stats
GET /api/dgrid/audit — current Merkle root + last on-chain txhash
GET /api/dgrid/audit/calls — full call log for independent Merkle verification
POST /api/dgrid/probe — force a DGrid-only call, verify live
POST /api/dgrid/compare — N models, same prompt, side-by-side
POST /api/dgrid/consensus — N models vote on a JSON field
POST /api/dgrid/chaos — toggle simulated DGrid outage (rate-limited)
POST /api/dgrid/attest — (admin) publish Merkle root on BNB Chain
Every public response with LLM content carries an
llm_provider field so judges can audit which provider served which decision — not just aggregate stats.