Known stays known.
Measurements and specifications you provide are preserved as inputs rather than quietly replaced with assumptions.
PhoneFuturist Labs / Interactive Leaks
InteractiveLeaks.
Build it. Test it.
Open workspace ↓Explore community builds →FoldablesTabletsLaptops
Simulator
Build your device
Beta
Simple ModeBeta · free
01
Device
Start with the physical envelope.
02
Display
Define the primary panel and its geometry.
Display workload conditions
These describe the current content/workload, not the panel's maximum specification. APL is the average picture level: 0% is black, 100% is full-white-equivalent content.
Advanced bezel geometry
03
Battery
Capacity, runtime and optional physical battery analysis.
Enter your expected active-use hours. Interactive Leaks converts those hours into workload shares and applies calibrated reference power internally. You never need to enter watts.
Advanced physical battery data
Optional. Cell dimensions and weight are used only for packaging and energy-density calculations, not to calculate battery life.
Battery aging assumptions
Optional aging scenario. Enter only rates you have evidence for or explicitly want to test. PhoneFuturist does not assign a default degradation rate from battery chemistry.
04
Charging
Estimate wired charging from real released-phone curves.
Charging is capacity-aware and uses measured released-phone curves. Wired and wireless evidence stay separate, while battery chemistry, cell architecture and charging standard refine comparable-device selection when known.
05
Connectivity
Model one explicit radio/network workload.
Network type and signal labels do not secretly change power. Enter measured or explicit radio power when you want an energy estimate.
06
Thermal & performance
Model sustained SoC power, heat and throttling.
SoC architecture assumptions
Enter up to four CPU clusters. Relative IPC is optional and normalized to your chosen reference, where 1.0 means equal IPC. Node size is metadata only and never creates an automatic performance uplift.
GPU architecture assumptions
Optional GPU structure for raster, gaming and ray-tracing context. Shader cores and execution units are not assumed to be equivalent across vendors. Relative architecture efficiency is only used when you explicitly supply it. Nothing here is automatically converted into a 3DMark score.
GPU workload target
Optional demand-side inputs. These calculate frame budget, pixel throughput and RT ray demand. They describe what the workload asks from the GPU, not what FPS the phone will achieve.
Advanced thermal model
The lumped resistance/mass fields drive the legacy thermal trace. The optional two-node fields separately model the SoC/package and chassis/surface. Supply all four two-node physical parameters or leave them blank. Do not guess them.
Peak benchmark evidence and sustained-performance evidence are intentionally separate. Peak scores use protocol-compatible measured benchmarks. Any future-generation uplift is an explicit assumption. Sustained performance remains evidence-calibrated thermal behavior.
07
Cameras
Add only what is actually known.
Multi-camera zoom handoff
Optional. Ask the simulator which supplied camera can reach a target equivalent focal length while retaining a requested native output resolution. Computational fusion and AI reconstruction are not assumed.
No camera modules added. Camera calculations will remain unknown.
08
Packaging
Model the known internal volume budget.
Known component volumes
Battery and camera volume are calculated automatically when enough geometry is supplied.
Unknown inputs stay unknown. The engine does not silently invent missing data.
How it works
Methodology
Calculation, not clairvoyance.
Unknown stays unknown.
Missing information remains missing when the engine cannot calculate it honestly from the available data.
Math stays reproducible.
The engine version is attached to the result so the same supported inputs can be evaluated against the same model.