Compact recurrent state
Aletheia updates a fixed-size state as tokens arrive. The recurrent state stays the same size as a sequence grows. Model weights, input processing, workspace files, and other runtime memory are accounted for separately.
Aletheia & HeinrichEMPHOS Group · Resource efficiency
Environment & engineering
Useful intelligence.
Careful with resources.
Resource efficiency begins with how intelligence is built, where it runs, and how work gets done. Aletheia brings CPU inference to Heinrich. Our research connects that architecture to the energy, memory, hardware, and infrastructure behind everyday use.
Last updated
From model to workspaceLocal inference
GPU trainingModel development
AletheiaTrained model
Your computerCPU
Heinrich workspaceProjects · memory · tools
Aletheia inferenceLanguage generation on the CPU
Reviewable workOutputs · checks · proof receipts
CPU inferenceAletheia at runtime
GPU trainingA separate development workload
Local firstWork close to the user
Whole-system viewEnergy, hardware, and useful output
The engineering foundation
Efficiency starts inside the design.
Aletheia is EMPHOS's core language model. It carries context through a recurrent oscillator state and runs inference on a CPU. Heinrich turns that model into an agentic workspace with projects, persistent memory, controlled tools, and reviewable results.
Inference on the CPU
The current inference architecture targets the processor in a laptop or workstation. GPU compute is used during training. Keeping those workloads separate makes the resource requirements of each easier to examine.
Local work by default
Heinrich keeps its model execution and project workspace on the user's computer. External services are connected deliberately, according to the task and the user's permissions.
Keep useful work available
Project memory, saved artifacts, and proof receipts let work continue across sessions. This gives the workspace a basis for reusing established context and inspecting previous results.
Make actions reviewable
Plans, approvals, tool execution, and output checks connect a request to a recorded result. Our efficiency work follows the entire task, including retries, verification, and background activity.
Design for practical machines
Consumer hardware is an important test environment for EMPHOS. Memory use, thermal behaviour, responsiveness, and sustained load help determine where a model or workflow fits.
The objective: complete useful work with a clear understanding of the resources it requires. Output quality, task completion, and energy use belong in the same evaluation.
Measurement & development
A measured starting point.
A broader evaluation program.
The environmental research has moved into instrumented testing. Our internal laptop campaign provides a starting point for examining Heinrich's operating behaviour; the next phase extends the method across workloads, hardware, and deployment conditions.
Internal test · July 12, 2026
Consumer-laptop power campaign
The recorded test used an Intel Core i7-13700HX laptop with 32 GB of memory. It tracked Heinrich's process tree and whole-machine battery readings through four operating phases, including a 200-query load.
- 01 · BaselineComputer running with Heinrich off.
- 02 · Application idleHeinrich open with no queries submitted.
- 03 · Answer loadThe application processing the query workload.
- 04 · ControlRequest-loop overhead measured separately.
This campaign informs the measurement program. Repeatable workload definitions and calibrated external measurement are the next steps toward a public energy benchmark.
What the next evaluation measures
- A defined workloadRecord the model build, input and output lengths, tool activity, task requirements, and acceptance criteria.
- The complete operating sessionCapture startup, idle time, active execution, and verification alongside useful output.
- Repeated measurementsUse external power instrumentation, repeated runs, and documented power settings to establish the range of results.
- Comparable workCompare systems on the same task, quality requirements, and accounting boundary, then review the method and results independently.
Explore the system
Follow the work.
Count the resources around it.
A useful evaluation states exactly what it measures. Expand each boundary to see how a device test, a hosted service, and a broader lifecycle study answer different questions.
01 · The device and the task
This boundary examines the computer completing the work: its total energy, the application's additional load, and the time required to produce an accepted result.
Compute & memory
Processor activity, model state, application memory, and storage access.
Idle & active time
The energy used while waiting, answering, running tools, and checking outputs.
Useful output
Task completion, answer quality, latency, retries, and review requirements.
02 · The delivered service
A hosted deployment adds shared resources around the model. The service boundary follows the request through the servers, storage, network, and facility systems that support it.
Shared capacity
Active servers and the capacity kept ready to serve users.
Facility operation
Cooling, power conversion, networking, and operational overhead.
Demand over time
Workload mix, concurrency, utilization, and completed tasks during the measurement period.
Google's published inference methodology explains why active compute, idle capacity, CPU/RAM, and facility overhead all matter.
03 · The equipment and development lifecycle
The broader research scope includes the resources used to develop, operate, maintain, and eventually replace the system. Model training and hardware production sit outside a simple runtime-only reading.
Model development
Training and evaluation runs, development machines, and data preparation.
Equipment lifecycle
Manufacturing, service life, maintenance, reuse, and end-of-life handling.
Location & infrastructure
Electricity supply, cooling method, water use, and the site conditions behind operation.
Power · watts
The rate at which a system uses electricity. Compare idle and active operation over a defined period.
Energy · watt-hours
Electricity used over time. Energy per completed task connects the operating session to its useful result.
Emissions · carbon dioxide equivalent
Electricity-related emissions depend on the electricity source and the accounting method. Equipment emissions require their own lifecycle information.
Water · litres
Record the cooling method and distinguish water withdrawn, returned, and consumed. State whether electricity-related water use is included.
How energy per task is calculated
Measure energy across the chosen period and divide it by the number of tasks completed to the agreed standard. Keep total system energy and the application's additional energy as separate measures.
Energy per task (Wh/task) = measured energy (Wh) ÷ completed tasks
For a variable load, energy comes from the power readings over time. Hardware power limits and rated thermal power describe operating constraints; the measurement records what the system actually used.
Hardware & everyday operation
Make practical use of practical machines.
Our desktop direction puts existing computers at the centre of the experience. The engineering work is to match the model and workspace to the machine, with attention to the whole working day.
Hardware fit
Evaluate processor support, available memory, storage, and thermals before defining a supported configuration. Sustained workloads are part of that evaluation.
Quiet periods matter
An application can spend much longer waiting than answering. Startup behaviour, background tasks, and idle energy are important parts of the optimization program.
Keep work portable
Project files, saved outputs, and reviewable records give work a life beyond a single session. Compatibility and continuity guide how we develop the workspace.
Deployment follows the workload. Local execution, customer-managed infrastructure, and hosted services have different resource profiles. We evaluate each against the work it needs to perform.
EMPHOS A1 · Proposed infrastructure
Carry the same discipline into infrastructure.
EMPHOS A1 is our proposed CPU-based delivery campus in British Columbia. Its environmental design program brings compute, power, cooling, water, and building use into one engineering process. Site selection and feasibility work will shape the final design.
CPU server deployment
Test Aletheia on server hardware under realistic concurrency. Match throughput, memory, reliability, and measured power to the service being delivered.
Site-specific cooling
Investigate sealed heat-exchanger cooling alongside local climate, available water sources, temperature limits, and permitting requirements.
Limit cooling water consumption
Evaluate cooling designs intended to avoid evaporative water consumption. The water study covers withdrawal, return, treatment, and seasonal conditions.
On-site solar
Assess solar generation against the selected site's orientation, usable area, seasonal output, and grid connection. Integrate generation into the full electricity plan.
Recover useful heat
Explore server-heat recovery for building use. Heat availability, temperature, transport distance, and seasonal demand determine the practical opportunity.
Account for the full facility
Include cooling, power systems, networking, support spaces, and maintenance. Compare facility energy with the volume and quality of work delivered.
Research applications
Take measurement into real working environments.
Our energy and cleantech work is organized around scoped evaluations with partners. Each proposed pilot starts with a specific operational need, a defined workload, and a way to measure the result.
Enterprise workspaces
Evaluate Heinrich on an organization's own hardware using representative project tasks.
- Energy across complete work sessions
- Task quality and completion time
- Deployment and support requirements
Constrained edge systems
Study model operation where power, memory, connectivity, and maintenance access are limited.
- Processor and memory requirements
- Idle and active operating profiles
- Reliability over sustained use
Energy-sector workflows
Explore bounded reference and documentation tasks inside customer-controlled environments.
- A clearly defined operator workflow
- Permissioned access and review
- Measured operating requirements
Common questions
Architecture, energy, and deployment.
Does Aletheia use a GPU?
Aletheia uses a GPU for training and a CPU for inference in the current architecture. These are separate stages with separate energy requirements. Heinrich is the workspace that runs on Aletheia.
How much electricity will Heinrich use on my computer?
The result depends on the computer, model build, workload, output length, tool activity, and time spent idle. Our measurement program evaluates those conditions together so a published result can be connected to a specific configuration and task.
How does local execution relate to environmental impact?
Local execution puts inference on the user's computer and makes that machine part of the measurement boundary. An environmental comparison also accounts for the work completed, the computer's electricity use, connected services, and the alternative deployment being compared.
Why study both local software and a delivery campus?
Different customers have different deployment needs. Heinrich's desktop direction centres on local work, while enterprise and hosted research examines shared delivery. EMPHOS A1 is the proposed infrastructure path for that hosted work.
Can a research or engineering team review the work?
Yes. Contact EMPHOS with your research area, proposed evaluation, and the equipment or expertise you can bring. We can discuss a suitable scope for technical review, measurement replication, or a pilot.
Further reading
The wider measurement context.
Energy & AI
The International Energy Agency's 2025 report examines the equipment, cooling, and electricity demand behind data centres.
Measuring AI inference
Google's 2025 methodology describes a service-level approach to energy accounting, including idle capacity and supporting infrastructure.
Research · Engineering · Investment
Help build intelligence with resource discipline.
We welcome conversations with measurement specialists, research groups, infrastructure engineers, prospective pilot partners, and investors. Bring a workload, an engineering question, or a deployment challenge.