Modern personal computers are becoming heterogeneous computing systems.
A single machine may now contain a CPU, integrated GPU, discrete GPU, NPU, shared and dedicated memory, multiple power states, and strict thermal constraints.
At the same time, workloads are becoming more diverse: software compilation, gaming, rendering, local AI inference, background services, and interactive applications can all compete for the same system resources.
This led me to a question:
What if the computer had a control layer capable of understanding the workload it is running and adapting its resources around that context?
That question became AICore.
What is AICore?
AICore is an experimental AI-assisted computer control layer for Windows and Linux, written primarily in Rust.
The project sits conceptually between applications and operating-system/hardware resource interfaces.
Its purpose is not to provide another collection of static “performance mode” switches.
Instead, AICore explores a continuous control model:
Observe
↓
Understand
↓
Predict
↓
Decide
↓
Validate
↓
Execute
↓
Verify
↓
Learn
The system collects platform telemetry and workload context, combines that information with application task information and optional AI inference, generates a resource policy, validates that policy against the capabilities of the machine, executes supported actions, and then verifies what actually happened.
Why a control layer?
Resource management on modern PCs is fragmented.
Applications understand their own workloads.
Operating systems understand processes and scheduling.
Hardware runtimes understand particular accelerators.
Drivers understand individual devices.
AI runtimes understand model execution.
But none of those components necessarily has a complete representation of the user's current computational intent.
AICore explores whether a separate control plane can connect some of those signals.
Conceptually:
Applications / User Intent
|
v
+---------------------------+
| AICore |
| |
| Context |
| Prediction |
| Policy |
| Validation |
| Runtime Routing |
| Execution |
| Verification |
+---------------------------+
|
+-----+-----+
| | |
v v v
CPU GPU NPU
Power / Thermal
AI should not directly control the machine
One of the most important architectural decisions in AICore is that AI inference is not treated as an authority.
An AI component can propose a decision.
It cannot bypass the control system.
The path is closer to:
AI proposal
|
v
Resource policy
|
v
Policy validation
|
v
Capability binding
|
v
Platform execution
|
v
Readback / verification
If a proposal is unsupported, invalid, stale or unsafe, the system should be able to reject it.
This separation also means that AICore does not require an AI model to remain operational.
Deterministic policy mechanisms can continue to operate when an AI provider is unavailable.
Fast control and slow intelligence
Another problem appears when AI is introduced into a control system: inference can be slow, while system state changes quickly.
A policy generated for a workload may already be irrelevant by the time it is ready.
AICore therefore separates slower reasoning and preparation from the fast control path.
The slower side can perform telemetry processing, prediction, history access and optional inference.
The fast side consumes prepared policies, validates their freshness and applicability, executes supported actions and verifies the result.
Stale decisions are not supposed to become valid simply because an AI model produced them.
Application integration
AICore currently experiments with three levels of application integration.
L0 requires no application modification. AICore attempts to infer context from the system.
L1 allows an application to explicitly describe the task it is performing and its resource requirements.
L2 provides a native task runtime where applications can submit, query and cancel tasks.
A task can describe information such as workload type, priority, latency sensitivity, power preference and accelerator requirements.
The longer-term idea is that applications should be able to communicate computational intent without directly controlling hardware policy.
Platform control
The current Windows implementation includes real platform integration for areas such as process priority, CPU affinity and power policy.
The project also contains GPU telemetry and hardware-control primitives, although GPU actuation is not yet a complete cross-vendor control path.
NPU support currently has substantially more architecture than real platform actuation.
That distinction is important.
AICore is an engineering prototype, not a claim that arbitrary CPU, GPU and NPU resources can already be universally controlled across every PC.
Failure is part of the architecture
A system that changes computer resources needs to assume that operations can fail.
AICore therefore includes concepts such as:
- capability validation
- post-condition verification
- rollback
- safe mode
- degraded operation
- policy expiration
- explicit execution states
A successful API call is not automatically treated as proof that the intended hardware state was achieved.
The control loop attempts to distinguish between requested state, execution result and observed state.
Where the project is today
AICore V4 is currently a private engineering prototype.
The project contains a multi-crate Rust workspace covering the control loop, policy system, platform adapters, AI runtime, task runtime, IPC, plugins, memory, simulation, CLI tooling and a local dashboard.
The architecture and engineering infrastructure are significantly further along than the performance evidence.
I do not yet have a cross-hardware benchmark dataset demonstrating that AICore improves performance or energy efficiency across representative systems.
Building that evidence is the next major stage.
The largest technical areas still being developed include broader GPU control, real NPU integration, cross-vendor heterogeneous compute orchestration and reproducible workload benchmarking.
Why keep the implementation private?
AICore is currently being developed as proprietary technology rather than an open-source project.
For that reason, I am publishing architectural information, demonstrations and engineering progress without publishing the core implementation.
The purpose of sharing the project now is to expose the architecture to engineers working on related problems and learn where the model is strong, weak, redundant or missing important realities of modern computing platforms.
What's next?
The next phase is less about adding more architecture and more about proving what the architecture can accomplish.
That means building reproducible experiments around workloads such as:
Compilation
Rendering
Local AI inference
Gaming
Mixed interactive workloads
and measuring the trade-offs between:
Performance
Latency
Energy
Thermals
Responsiveness
across different hardware platforms.
The question I ultimately want AICore to answer is no longer simply:
Can a computer dynamically control its resources?
Modern operating systems already do that in many ways.
The more interesting question is:
Can workload intent, system context and adaptive policy provide a useful additional control layer for increasingly heterogeneous personal computers?
That is what I am trying to find out.
Project architecture and development status:
https://github.com/7-hello007/AICore-Showcase
I would especially welcome technical criticism from people working on operating systems, performance engineering, heterogeneous computing, power management, AI PCs, hardware runtimes and local AI infrastructure.
Top comments (0)