Back to Prompt Library
implementation
Build the application
Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.
Linked challenge: Build an Accelerator Chassis Power Budget and Throttling Reviewer
Format
Code-aware
Lines
73
Sections
11
Linked challenge
Build an Accelerator Chassis Power Budget and Throttling Reviewer
Prompt source
Original prompt text with formatting preserved for inspection.
73 lines
11 sections
No variables
1 code block
## Build
Correlate server chassis electrical power caps with per-device DCGM utilization logs. Formulate dynamic power balancing schedules and throttling prevention plans using hosted Claude.
## User
Datacenter Power and Facilities Engineer
## Workflow
1. Ingest rack PDU power limits and per-accelerator DCGM power consumption telemetry using pandas.
2. Detect electrical headroom deficits where total peak draw risks tripping rack-level circuit breakers.
3. Invoke hosted Claude via Anthropic API to synthesize power cap balancing proposals across non-critical workers.
4. Generate a structured power allocation manifest detailing per-GPU watt limits validated via pydantic.
## Interface
Dashboard visualizing rack power envelope utilization and Claude-recommended power capping profiles.
## Data
Simplified synthetic app records representing power telemetry logs from server PDUs and DCGM metrics across 8-accelerator chassis.
Starter examples below are synthetic. They are not downloaded records.
## Source
[NVIDIA DCGM exporter](https://raw.githubusercontent.com/NVIDIA/dcgm-exporter/main/README.md)
Extracts DCGM power metrics (DCGM_FI_DEV_POWER_USAGE) and hardware power limit registers.
## Tools
dspy, anthropic, pandas, pydantic.
DSPy compiles robust prompt pipelines to guarantee hosted Claude produces schema-compliant power allocation limits.
Hosted a currently available hosted Claude model accessed via official SDK; does not emit live electrical breaker or firmware commands.
## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.
## Acceptance
- Identifies potential PDU overload conditions when peak sum exceeds rack threshold.
- Calculates balanced power allocation across active server chassis.
- Produces hosted Claude explanations for selected power capping setpoints.
## Starter Examples
```json
[
{
"input": {
"pdu_max_kw": 12,
"chassis_count": 4,
"unconstrained_peak_kw": 14.5,
"priority_chassis_index": 0
},
"expected_output": {
"breaker_trip_risk": true,
"recommended_chassis_caps_kw": [
4,
2.6,
2.6,
2.6
],
"total_budget_kw": 11.8,
"allocation_rationale": "Chassis 0 maintained at peak demand for SLA compliance; remaining chassis capped to prevent PDU overload."
}
},
{
"input": {
"pdu_max_kw": 12,
"chassis_count": 4,
"unconstrained_peak_kw": 9.2,
"priority_chassis_index": 0
},
"expected_output": {
"breaker_trip_risk": false,
"recommended_chassis_caps_kw": [
3.5,
2.5,
2,
1.2
],
"total_budget_kw": 9.2,
"allocation_rationale": "Operating load is well within the 12 kW PDU envelope. No power capping required."
}
}
]
```
## Safety
Provides advisory power capping allocations; does not issue live IPMI power cap updates.
Use mock external writes. Require human review before any real deployment.Adaptation plan
Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.
Keep stable
Hold the task contract and output shape stable so generated implementations remain comparable.
Tune next
Update libraries, interfaces, and environment assumptions to match the stack you actually run.
Verify after
Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.