Coder Legion - Recent posts tagged xbox

I Tried to Build Persistent Compute on an Xbox SSD. The Failed Tests Changed the Architecture.

Mon, 12 Oct 2026 21:54:26 +0000

The Xbox wrote 8 GiB of persistent data.

I still couldn't call the experiment successful.

The bytes were there, but the operation failed because a completely different part of the system had timed out. In another test, the worker correctly refused to allocate more storage even though its configuration technically allowed a much larger workload.

Eventually, the experiment passed. But getting there required much more than writing files to an SSD.

I had to investigate how Xbox processes share resources, build a separate coordination component, introduce a recoverable page store, survive real application restarts, and learn which failures were bugs and which were legitimate platform boundaries.

This is one of the experiments behind XCP that I hadn't explored in the previous articles.

The five-part XCP series ended with the platform becoming open source. This bonus chapter goes back into the original Xbox research to explain how I approached persistent computation inside the Developer Mode sandbox.

The problem wasn't just memory capacity

In the earlier experiments, XCP measured an application memory budget of 5 GiB in one Xbox Series X Developer Mode configuration.

That was useful. It gave us an actual resource boundary for the worker rather than a number inferred from the console's hardware specifications.

But it also raised another question.

What happens when the work I want to execute is larger than the memory I can keep resident?

I wasn't trying to bypass the sandbox or convince the Xbox that its SSD was additional physical RAM.

I wanted to build something different: an execution system that could keep data and completed work in persistent storage, bring bounded pieces into memory, process them, and continue from a valid checkpoint after an interruption.

Before building the storage layer, though, I had another hypothesis to investigate.

Could a second process help?

First, I investigated the Xbox process model

XCP already had a foreground worker capable of running CPU and GPU workloads.

I wanted to understand whether another process inside the same UWP package could perform useful background coordination without consuming the worker's entire resource budget.

The candidate was an out-of-process App Service.

On desktop Windows, creating another process might seem straightforward. On Xbox Developer Mode, I wasn't going to assume that the desktop behavior applied unchanged.

So I started measuring.

The first live probes established that the worker and an auxiliary App Service could run with distinct process and activation identities. They exchanged messages, maintained independent heartbeat activity and retained touched, verified memory during overlapping execution windows.

That was already useful.

But it did not prove that we had discovered a second independent 5 GiB memory budget.

To investigate properly, I built an eleven-phase matrix covering CPU execution, verified GPU execution, simultaneous activity, progressive memory pressure, bidirectional storage visibility, suspension, termination, restart, redeployment and cleanup.

And this is where the testing started getting complicated.

The first failures weren't even storage failures

Worker .150 reached the Xbox but exposed incomplete measurement data. It could report IPC latency summaries, yet the acceptance contract required the underlying distribution, including median, p95 and bidirectional throughput.

There was no legitimate way to reconstruct missing measurements afterward.

So that run remained diagnostic.

Worker .151 produced another interesting failure: 79 of 81 preflight checks passed.

The two failures came from heartbeat validation.

The foreground heartbeat ran at 25 ms intervals. The auxiliary broker used a 100 ms timer. During an approximately 935 ms observation window, the broker produced nine ticks.

The test incorrectly expected 32 because it had reused the foreground count.

The broker wasn't failing to run. Our expectation was wrong.

That candidate stayed failed, and the next version corrected the measurement contract.

Worker .152 passed the preflight, but memory-pressure testing exposed another gap. The Xbox refused a bounded allocation, yet the error didn't carry enough structured information to establish the responsible component, observed headroom, applied reserve and cleanup outcome.

A text error saying that memory allocation failed wasn't sufficient to classify the platform behavior.

Worker .153 added the missing observations.

The completed matrix passed all eleven phases, retaining fourteen actual attempts in its evidence history.

The separate classification step selected Case B: a distinct but resource-limited useful process.

That result changed the design.

I didn't have evidence for a second large compute process. But I had enough evidence for a small coordination service.

That was what I built.

The second process became a coordinator

Instead of creating another general-purpose worker, I gave the auxiliary process a narrower responsibility.

It could participate in lifecycle observation, heartbeat management and storage reservations.

The main worker still controlled execution admission, semantic verification, recovery authorization and final result publication.

This separation mattered because the broker could disappear and restart independently.

A reservation could not simply be assumed valid because some old record said it existed.

The worker had to validate the reservation identity, generation and storage plan before accepting new work.

Worker .154 tested this arrangement on the physical Xbox.

55 of 55 checks passed, with zero violations.

The useful result wasn't more RAM.

It was an operational coordination mechanism on which persistent computation could be built.

Next, I needed storage that could survive failure

Writing a file is easy compared with deciding whether that file represents completed computation.

Imagine a workload producing hundreds of output pages.

The application writes a page, updates some metadata, and then disappears.

After restarting, which pages can be trusted?

Did a page finish writing? Does its recorded hash match the bytes? Was its journal entry committed? Can the computation resume from that point without silently skipping or duplicating work?

For XCP, I built the storage system around content-addressed data and an append-only journal.

Each committed page had an identity derived from its content. The journal recorded ordered transitions, with records linked through hashes.

A page was not considered committed just because its file existed.

The system had to verify the relevant content and metadata before including it in the committed sequence.

Recovery worked from the longest valid committed prefix. Anything beyond that boundary could not silently become trusted state.

That approach allowed the runtime to distinguish a completed checkpoint from bytes left behind by an interrupted operation.

Then I tried breaking it

Worker .155 exercised the page store and recovery system on Xbox.

The tests included truncated journal entries, corrupted hashes, missing pages, incomplete root manifests, conflicting page identities, exhausted quotas, stale reservations and repeated cleanup.

The live campaign also tested recovery after worker restart, auxiliary restart and package redeployment.

One deployment experiment uncovered an unexpected problem.

An in-place installation using the same package version left the application running, but Xbox Network Isolation silently dropped the inbound worker connection.

The correction was not to pretend the storage operation had succeeded.

We used a clean uninstall with application data preserved, reinstalled the exact package, restored connectivity and verified that the committed storage root had survived.

The complete .155 campaign eventually passed 248 of 248 checks.

At this point I had a storage substrate capable of preserving committed data through the tested failure and lifecycle scenarios.

But I still hadn't demonstrated useful persistent computation.

That required the next experiment.

Running computation through persistent storage

For the first workload, I reused an existing XCP test called Provable Worlds.

It produces a deterministic field of 1024 × 1024 unsigned 32-bit values.

The complete result is only 4 MiB.

That may sound small for an SSD experiment, but this test wasn't intended to prove beyond-RAM scale yet.

I wanted to establish that computation could be divided into independently checked units, committed in order, interrupted and resumed correctly.

The field was divided into 256 tiles of 16 KiB each.

Each tile had a known global position in the output. The signed CPU Capsule could compute its bounded portion, and XCP compared that result against the CPU reference.

The runtime used bounded output buffers rather than requiring the complete result to stay resident.

The important condition was that the durable cursor advanced only after a page had been committed successfully.

The first uninterrupted runs passed. Restart failed.

Worker .156 completed two uninterrupted executions.

Then I tested the restart path.

Both real-restart resume attempts failed.

The problem was the reservation lifecycle.

After the foreground interruption, the system attempted to continue using the old coordinator lease. But that lease belonged to the previous activation.

This contradicted what the earlier process-topology experiments had already shown.

Persistent data could survive the interruption.

A live process reservation could not be treated the same way.

So I separated those two concepts.

The committed journal retained its original storage identity and generation. A resumed worker had to obtain a fresh live reservation, with a newer generation, and reauthorize the persisted work before continuing.

Worker .157 implemented that correction.

The test deliberately committed the first 128 tiles, computed the next tile without committing it, and interrupted execution.

After the real restart, the worker verified the committed prefix, skipped those first 128 tiles and computed the remaining 128.

It reproduced the expected final field hash.

The uninterrupted tests, restart/resume path, cleanup and same-package regression checks passed.

XCP admitted that specific bounded persistent-compute capability.

One distinction is worth keeping: the tiled execution used the signed CPU Capsule, not a newly implemented GPU-tiled engine. The existing GPU path was checked separately. Nor did this test demonstrate performance gains from asynchronous I/O overlap.

It demonstrated correct bounded computation and recovery.

Now I wanted to investigate the storage scale.

Eight gigabytes, and another failed experiment

For the scale test, I moved to a different page geometry.

Instead of the 16 KiB computation tiles, the storage characterization used 4 MiB pages.

The target was 8 GiB: exactly 2,048 pages.

I also defined a progression through 256 MiB, 512 MiB, 1 GiB, 2 GiB, 4 GiB and finally 8 GiB.

The data was generated deterministically, with page-specific content, so the test could verify distinct pages without treating a single repeated blob as proof of physical growth.

And there was a safety condition: the operation had to preserve 16 GiB of reported available storage as a reserve.

Then came worker .158.

The worker materialized the full 8 GiB.

But the operation failed.

After more than 163 seconds of storage work, the coordinator attempted to release its reservation using an IPC deadline that had been established at the beginning of the operation.

That deadline was only 30 seconds.

The data had been written, but the protocol could no longer complete the operation correctly.

This was not an accepted result.

I corrected the lease-release timeout handling, added an explicit cleanup path for the failed run and tested again.

Worker .159 successfully committed all 2,048 pages.

The measured seed operation took approximately 164 seconds.

That is an end-to-end operation time, including page generation, hashing, storage and journal work. It isn't a raw SSD throughput benchmark.

But .159 was not the final success either.

The 64 GiB attempt was refused

The broader storage policy allowed much larger declared reservations, so I also tested what happened when the system attempted to continue beyond the 8 GiB seed.

The remaining planned growth was 56 GiB.

The platform-reported filesystem space was nowhere near sufficient for that growth plus the required 16 GiB safety reserve.

The worker returned:

STORAGE_SCALE_PLATFORM_HEADROOM_REFUSED

And crucially, it refused before writing additional data.

The existing workspace remained unchanged. Cleanup subsequently removed the 8 GiB seed and a second cleanup confirmed that the namespace was already absent.

This result did not establish that the Xbox SSD had a 64 GiB limit, or that the entire physical SSD was visible to the application.

The application had observed a much smaller storage filesystem, approximately 32.2 billion bytes of reported capacity in that test.

The configured storage quota was not the same as actual platform capacity.

The refusal was correct.

Instead of trying to force a larger allocation, I froze the demonstrated 8 GiB size as the target for the final characterization.

The result: worker 0.1.160.0

Worker .160 was built and signed as a new exact package and tested on the physical Xbox.

This time, the process completed the full storage lifecycle.

It committed 2,048 distinct 4 MiB pages, totaling 8 GiB, then released the reservation.

I returned to the Xbox Home screen and resumed the worker without power-cycling the console.

The resumed worker obtained a fresh reservation generation, recovered the persisted namespace, reread and rehashed the complete 8 GiB, and committed the ordered root without allocating another storage rung.

A separate verification operation then read the complete data again under another fresh lease and reproduced the same root identity.

Finally, cleanup removed the 2,048 unreferenced blobs and all 8 GiB of their content.

A second cleanup found nothing left to remove.

The complete .160 lifecycle passed its checks.

That was the accepted storage-scale result.

Not 64 GiB. Not the console's full SSD. Not virtual RAM.

Eight GiB of bounded, recoverable, content-verified persistent storage, measured through the actual Xbox worker lifecycle.

What this proves, and what it doesn't

The completed experiments establish two related capabilities.

First, XCP demonstrated a persistent-compute workflow in which deterministic tiled execution could survive a real worker interruption, verify previous committed work and resume without recomputing the valid prefix.

Second, it demonstrated an 8 GiB persistent storage namespace with recovery, full-root verification and cleanup on the physical Xbox.

These were separate tests.

The 4 MiB computation experiment did not prove that an arbitrary dataset larger than RAM could be processed end to end.

The 8 GiB storage experiment did not prove an 8 GiB GPU or CPU workload, transparent paging, unrestricted SSD access or a performance-optimized streaming engine.

In fact, the recorded streaming runtime exposed no measured prefetch/compute overlap advantage. The bounded buffers, ordered commits and recovery path were the capabilities being established.

Combining those pieces into larger real workloads is further engineering work, not something I can claim was already completed.

But the distinction between demonstrated components and future integration doesn't make the result less interesting.

It tells me which parts of the problem are actually solved.

Why the failed tests mattered more than the number

Looking back, there wasn't one dramatic failure.

There were several small, independent ones.

The auxiliary process existed, but didn't prove an independent memory budget.

The heartbeat worked, but the test expected the wrong number of ticks.

Memory pressure produced a refusal, but not enough structured evidence to classify it.

The storage layer survived, but an installation sequence disrupted the worker connection.

Computation succeeded uninterrupted, but couldn't resume under the old lease.

Eight gigabytes were written, but the IPC timeout invalidated the operation.

And a larger storage request was refused because the available space could not satisfy the reserve.

Each result forced a different correction.

Some changed the implementation. Some changed the measurement contract. One changed the resource-topology decision. Another changed the scale we were prepared to claim.

I think this is one of the most interesting aspects of XCP.

It didn't become more capable by assuming the Xbox restrictions were irrelevant.

It became more capable by discovering which capabilities could be combined reliably inside those restrictions.

The result was not a magic way to make SSD behave like RAM.

It was a storage and recovery architecture that allows computation to have a durable history independent of the process that produced it.

The code is now open source

The original Xbox experiments were performed in the historical XCP research environment.

The public repository contains reconstructed reference implementations and the source needed to inspect the design, including:

The distinction between the original historical results and the newly reconstructed development packages remains important.

The public source lets developers inspect and rebuild the relevant components. The historical hardware results belong to their original package versions and evidence records.

Newly reconstructed packages do not automatically inherit those physical-Xbox results. They require their own device validation.

That boundary is explained in the public reconstruction audit.

Beyond the SSD experiment

XCP started as an attempt to make an Xbox Series X a programmable execution target.

The project eventually expanded into a virtual machine, CPU/GPU execution, agent-driven development, a desktop studio and tools for adapting and building software.

The SSD experiments explored another necessary part of that picture.

A useful execution target needs more than the ability to run a program once.

It needs a way to preserve work, recover from interruption and continue under a new execution context without pretending that the old one still exists.

The most valuable result of this experiment wasn't the eight-gigabyte figure by itself.

It was the realization that the lifetime of a computation does not have to be identical to the lifetime of the process executing it.

On this particular Xbox, we demonstrated some concrete parts of that idea.

And as with the rest of XCP, the next meaningful step is to take those capabilities into a more demanding workload and find out where they stop being sufficient.

XCP is open source

GitHub: https://github.com/Daniele-Cangi/xcp-xbox

XCP Studio: https://xcpstudio.com/

XCP: From an Xbox Experiment to an Open Development Platform

Thu, 08 Oct 2026 10:54:36 +0000

XCP — Chapter 5
In the previous chapters, I wrote about turning an Xbox Series X into a programmable execution target, building a virtual machine inside its sandbox, connecting AI coding agents to real hardware, and measuring the memory and GPU capabilities available in Developer Mode.

Those articles explained individual parts of XCP. This final chapter is about what they were all leading toward.

The goal was never simply to run AI-generated code on an Xbox. The goal was to build a development platform around the console, one that independent developers could eventually extend with familiar tools, engines and frameworks.

That distinction matters because XCP now contains considerably more than the compute worker that started the experiment.

It includes a programmable runtime, a desktop development environment, an execution and evidence system, Godot adaptation research, a native graphics pipeline and procedural worlds generated from WorldLoop.

Each of those components grew out of a practical experiment. Together, they suggest a different way of approaching console development.

From hardware research to a development platform
The first question was relatively simple: how much useful computation could we perform on an Xbox Series X without bypassing its security model?

XCP began inside the supported Developer Mode application sandbox. We explored memory allocation, persistent storage, CPU execution, GPU compute, graphics rendering and communication with a development PC.

Those experiments produced measurable results, including a 5 GiB application memory budget in one tested configuration and more than 7.7 TFLOP/s in a bounded FP32 shader workload. We also built XVM, a verifiable execution environment capable of running admitted programs and returning structured execution evidence.

But the more interesting possibility emerged after those foundations were working.

We already had a console that could receive structured work, execute it, report its state and preserve a history of what happened. The next logical step was to use that infrastructure for complete software projects rather than isolated compute workloads.

That decision changed XCP from a hardware research project into a creative-platform project.

Three Godot games, three different problems
One of the most important parts of the original XCP research was adapting existing Godot projects into bounded, playable experiences on the Xbox.

Rather than using a single demonstration designed specifically for the platform, we worked with three substantially different games.

Blokki — a 2D puzzle
Blokki gave us a compact starting point for testing scene interpretation, grid interaction, controller input and gameplay feedback.

The adaptation translated pointer-based interactions into a controller-driven grid, replaced some presentation elements with procedural drawing and preserved a bounded playable puzzle loop.

The Xbox playability checks covered rendering, controller response, valid and invalid action feedback, and the usability of the interaction loop.

Minedot — a 3D voxel-style sandbox
Minedot introduced a different class of problems: a 3D environment, camera navigation, spatial interaction and mining or placing blocks.

Its playable reconstruction used the left stick for movement, the right stick for looking around and bounded controller actions for interacting with the world.

Some source dependencies were incomplete, so the Xbox implementation used declared substitutions rather than pretending that the original game had been reproduced completely.

The resulting bounded experience was tested on physical hardware, including movement, camera control, interaction feedback and visual usability.

Open RTS — a more complex 3D strategy game
Open RTS pushed the experiment further.

This time the adaptation involved a strategy environment with unit selection, movement, combat, interface visibility and a victory condition.

The first physical test exposed presentation problems. Rather than simply accepting a successful launch, we corrected the interface behavior and performed another test.

The revised version passed its bounded playability checks, including selection, movement, combat and victory feedback.

Across these three projects, the research recorded 3/3 bounded playable reconstructions, 15/15 human playability checks and 17 captures.

These results do not establish full source equivalence or universal Godot compatibility. The reconstructions used explicit substitutions, and additional work remains before an arbitrary Godot project can pass through the system without project-specific adaptation.

What they do establish is that the approach was exercised across a 2D puzzle, a voxel-style 3D sandbox and a more complex 3D strategy game on real Xbox hardware.

That is a useful foundation for developing reusable engine adapters instead of continuing to create isolated ports.

Forge: when WorldLoop met Xbox
Godot adaptation was not the only creative experiment.

Another branch of the original research connected XCP with WorldLoop, my procedural CAD and world-generation project.

WorldLoop was originally developed around procedural construction and scene generation. Buildings, structural relationships and larger environments could be generated from structured rules rather than manually assembled one object at a time.

I wanted to see whether that same approach could produce content for a completely different execution environment.

This led to Forge Protocol, a native Xbox graphics and gameplay experiment using Direct3D 11.

The important architectural decision was to keep generation on the development PC. WorldLoop produced structured environments, which were then compiled into bounded native assets that the Xbox application could load and render.

The console did not need to run the original generator or its development dependencies.

The pipeline was approximately:

WorldLoop procedural generation

         |
         v

Structured world + geometry

         |
         v

PC-side asset compilation

         |
         v
Forge scene bundle
         |
         v

Xbox native D3D11 runtime

         |
         v
Rendering + gameplay

The experiments progressed beyond simple geometry.

Orbital Forge Alpha demonstrated a WorldLoop-generated scene on Xbox, while Orbital Forge Beta expanded the environment into thousands of render parts, multiple placed structures, roads, structural relationships and a larger native scene bundle.

The Beta world contained 2,364 render parts and compiled into 56,736 vertices and 28,368 triangles. It was installed and launched on the physical Xbox, with further iterations addressing scene scale, composition and gameplay readability.

This mattered for a reason beyond the visual result.

The same console execution target was receiving content from a procedural world generator that had not originally been designed for Xbox.

Forge was not proof that every procedural engine could automatically run on the platform. It demonstrated one workable boundary between external generation and a native console runtime.

For XCP, that boundary is important. Different authoring environments should not necessarily require completely separate execution infrastructures.

XCP Studio: one project, shared by humans and agents
The next part of the platform was the development experience.

XCP Studio was designed as a Windows desktop environment where a developer, a visual interface and an AI coding agent can operate against the same project representation.

Rather than giving each interface its own interpretation of the software, the project has a shared structure and explicit contracts.

A project can declare its modules, assets, required capabilities and runtime configuration. XCP validates these declarations against the capabilities actually exposed by the execution target.

The development cycle is:

Developer / coding agent

       |
       v
Editable XCP project
       |
       v

Validate + build bundle

       |
       v
 Install on Xbox
       |
       v
Launch + interact
       |
       v

Observe + capture evidence

       |
       v
 Revise or rollback
       |
       +------> Next iteration

The desktop environment is not merely a dashboard for a worker.

It is intended to become the place where software is created, adapted, tested and evolved.

The original research has already measured an end-to-end XCP Studio Technical Preview workflow on physical Xbox hardware, including project validation, installation, activation, launch, interaction and capture.

The packaged preview still requires further clean-machine validation and release preparation. It should not be confused with a generally available finished product.

Nevertheless, the essential development loop has been exercised.

Why this could matter commercially
There is a practical audience for a platform like this: independent developers, small studios, technical artists, researchers and people who want to experiment with interactive software on real console hardware.

For many of them, the difficult part is not necessarily writing the first prototype. It is managing the gap between a familiar development environment and the constraints of a different execution target.

A useful platform could reduce that gap.

Imagine creating a small project with an existing engine, adapting it through a community-maintained integration, running it on an Xbox in Developer Mode and receiving structured feedback from the actual device.

The developer could then revise the same project and repeat the cycle without rebuilding a separate workflow for every experiment.

That would be particularly useful during early prototyping, when ideas change frequently and fast iteration is often more valuable than elaborate release infrastructure.

There are already official development paths for engines such as Godot and Unreal Engine. XCP is not intended to replace Microsoft's commercial publishing programs, nor does it grant access to restricted console capabilities.

Its proposed value is different: an open, reusable prototyping and execution environment built around the capabilities available to it.

The long-term ambition is to support increasingly complex projects and established frameworks through reusable adapters and runtime components.

Godot is a natural starting point because we have already conducted adaptation experiments. Unreal Engine and other major frameworks represent possible future integration work, not compatibility that XCP can currently claim.

And I do not think this requires waiting until every feature of a major engine is supported before the platform becomes useful.

A carefully defined subset that developers can actually build, execute and test may already provide value.

Why I made XCP open source
The original repository grew into a laboratory containing hardware probes, multiple generations of runtime experiments, creative projects, integration prototypes, successful tests and failed approaches.

It was useful for research, but it was not a particularly good starting point for external contributors.

That is why I extracted a separate public XCP repository around the reusable components: project contracts, XVM, source adapters, semantic infrastructure, execution evidence, conformance tests and development tools.

The public repository is not a complete copy of the original laboratory. Third-party game sources and assets are excluded, and historical Xbox results must not be presented as fresh verification of newly reconstructed binaries.

The next stage also cannot depend entirely on me building every integration.

For XCP to become a genuine platform, the community needs to be able to extend it.

That could mean implementing another source adapter, contributing rendering functionality, improving Godot support, building conformance tests, introducing a different runtime or exploring another execution target.

The project deliberately separates source interpretation, execution contracts and target-specific capabilities because those are the areas in which independent contributions could eventually make the largest difference.

I am not assuming that every abstraction is already general enough. In fact, one of the reasons to involve outside developers is to discover where the architecture still contains assumptions inherited from the original Xbox experiments.

A platform becomes interesting when people can build things its original author did not anticipate.

What remains to be done
The historical research demonstrates several important capabilities, but turning those capabilities into a broadly usable development platform requires another kind of engineering.

The public toolchain needs reproducible validation against the hardware. The desktop application needs a straightforward installation and onboarding experience. Framework adapters need to become more general, and new projects must be tested without relying on prior knowledge of their structure.

That last point is especially important.

We have demonstrated bounded playable reconstructions of three Godot games. The next significant result would be an independent developer taking a previously unseen project through the adaptation and execution process, with a clear record of which features work, which require substitutions and which remain unsupported.

That would measure something different from the historical experiments: the usefulness of XCP as an extensible development tool.

There is also substantial room for the community to explore beyond games. Interactive scenes, simulations, procedural environments, educational software and GPU-driven experiments all fit the same general direction.

The platform should grow according to what can actually be implemented and measured, rather than a fixed list of promises.

The bigger idea behind XCP
Looking back, the development of XCP followed a somewhat unusual path.

It started with an Xbox and a question about its computational capabilities.

That led to memory and GPU experiments, a virtual machine, verified execution, AI-agent integration, a creative runtime, Godot adaptation, procedural worlds and finally a desktop development environment.

None of those individual components tells the whole story.

XVM is not the final product. GPU compute is not the final product. Forge and the Godot experiments are not separate destinations.

They are different parts of a larger effort to make real hardware available as a practical, programmable and verifiable development target.

The long-term vision is an open platform where developers can bring familiar tools, the community can expand the supported capabilities, and AI agents can participate in development without replacing the developer's authority over the project.

The Xbox Series X is the first physical target because that is where the experiment began and where the current evidence exists.

It does not have to be the last.

And that is why I think XCP has a meaningful future beyond its original hardware research.

Not because it already supports every engine or solves every problem in console development, but because it has established several working pieces of an environment that independent developers could help turn into something substantially larger.

The next interesting result will not be another benchmark produced by me. It will be something built by somebody else using XCP.

That is what I would like to see the project become.

XCP is open source
GitHub: https://github.com/Daniele-Cangi/xcp-xbox

XCP Studio: https://xcpstudio.com/

The public repository contains the extracted platform, reference implementations, contracts and verification tooling. The original Xbox research provides historical hardware evidence, while new builds require validation against their own exact artifacts.

Contributions, experiments and technical discussion are welcome.

This is the final chapter of the XCP introduction series. The development itself continues.

XCP Studio: One Project, Three Ways to Work With It

Sat, 03 Oct 2026 15:31:14 +0000

In the first two posts I wrote about the larger XCP idea: turning an Xbox Series X in Developer Mode into a programmable execution target, and keeping AI-assisted software inside a continuous build → execute → observe → correct loop.

But most of that work has one place where it becomes visible.

XCP Studio.

Recorded XCP Studio workspace from the public XCP repository.

XCP Studio is the Windows development environment around XCP.

The idea behind it is deliberately simple:

the developer, the visual interface and the coding agent should not operate on three different versions of the project.

They should work on the same project authority.

One project, three ways to work with it

A project can be approached at different levels.

                XCP PROJECT
                     │
          ┌──────────┼──────────┐
          │          │          │
       Guided      Expert      Agent
          │          │          │
          └──────────┼──────────┘
                     │
                 same state

Guided exposes higher-level project operations through the interface.

Expert gives direct access to the detailed development workflow.

Agent allows coding agents to work through the same project lifecycle and portable XCP tooling.

The important part is not the existence of three interfaces.

It is that they do not create three separate project models.

If a developer changes the project, the agent works from that project.

If an agent creates or adapts something, Studio works from the same authority.

There is no hidden AI-only version of the software that has to be reconciled later.

That becomes increasingly useful when development moves back and forth between humans and agents.

Studio does not stop at generation

A lot of AI development tools effectively end here:

prompt
   ↓
code
   ↓
files

XCP Studio was built around a longer lifecycle.

idea / source
     ↓
XCP Studio
     ↓
project
     ↓
validate
     ↓
build
     ↓
Xbox execution target
     ↓
result + evidence
     ↓
inspect / correct
     ↺

Studio can create or open a project, validate it against the available contracts, build it, prepare execution and inspect the resulting evidence.

The coding agent remains on the development side.

The Xbox remains the execution target.

The two are connected through XCP's admitted project and execution contracts rather than by giving an agent unrestricted access to the console.

That distinction is important.

AI builds and modifies software. Xbox executes admitted work. XCP records what happened.

The next iteration can then start from the result of a real execution instead of only from what the model expected to happen.

Why I wanted Studio at all

Technically, much of XCP could have remained a collection of command-line tools.

The portable repository already exposes operations such as:

xcp project describe
xcp conformance all
xcp xvm verify ...
xcp xvm run ...

But the larger system needed a place where the entire project lifecycle could remain understandable.

Source, project state, target capabilities, validation, builds, execution and evidence are related.

Once AI agents enter that lifecycle, keeping those relationships visible becomes even more important.

So Studio is not intended to be an AI code generator with an "Run on Xbox" button attached to it.

It is the control surface around the lifecycle.

developer ───────┐
                 │
coding agent ────┼──► XCP Studio / project
                 │             │
tools ───────────┘             │
                               ▼
                         admitted build
                               │
                               ▼
                         Xbox Series X
                               │
                               ▼
                            evidence
                               │
                               └────► next iteration

The project survives every individual generation.

That is the part I care about most.

Now it is part of the open-source stack

XCP Studio is included in the public XCP source tree.

The repository contains the portable XCP contracts, XVM, project tooling, evidence infrastructure, source adaptation work, the reconstructed Windows development stack and the native Xbox worker components.

The portable parts can be explored without owning an Xbox.

git clone https://github.com/Daniele-Cangi/xcp-xbox.git
cd xcp-xbox

python -m pip install -e '.[test]'
python -m pytest -q
xcp conformance all

On Windows, the repository can also rebuild the development distribution containing XCP Studio and the supporting runtime components.

One evidence boundary is worth keeping explicit: the preserved product path was exercised historically on a physical Xbox Series X, while the newly reconstructed public development packages are still marked NOT_TESTED_ON_XBOX until independently reproduced on hardware.

That separation is intentional.

XCP treats a successful historical run and a newly rebuilt binary as two different claims.

The small idea behind Studio

The UI is not really the interesting part.

The interesting part is the shared object underneath it.

human
  │
  ├─────────┐
  │         │
  ▼         ▼
Studio    agent
  │         │
  └────┬────┘
       ▼
   XCP project
       │
       ▼
 real execution
       │
       ▼
    evidence

Humans and AI do not need separate development worlds.

They need a shared project, explicit capabilities and evidence from the machine that actually executed the result.

That is what XCP Studio is trying to provide.

XCP is open source

GitHub:
https://github.com/Daniele-Cangi/xcp-xbox

XCP Studio:
https://xcpstudio.com/

Previous chapters:

AI builds. Xbox executes. XCP verifies. Studio is where the loop stays visible.

A System That Lets AI Work Directly With a Real Xbox

Sun, 27 Sep 2026 19:52:46 +0000

I wanted AI to work directly with a real Xbox.

Not just generate code on a PC.

I wanted the same software project to be created or adapted, sent to Xbox, executed there, observed, corrected, and then evolved again.

That system became XCP.

And now it is open source.

👉 GitHub: https://github.com/Daniele-Cangi/xcp-xbox
👉 XCP Studio: https://xcpstudio.com/

The simplest way to understand it is this:

AI / developer
      ↓
   project
      ↓
     XCP
      ↓
 Xbox Series
      ↓
 execute + observe
      ↓
   evidence
      ↓
 next version
      ↺

AI builds. Xbox executes. XCP observes. The project continues.

What it already looks like

This is not only infrastructure.

I wanted to see actual software cross that loop.

Forge

Forge — created through the XCP workflow and executed on Xbox.

The interesting part is not that AI can generate code.

The interesting part is that the project can continue after generation: it can be executed on a real target, observed, changed, versioned, and executed again.

Minilens

Minilens — an authorized Godot project adapted through XCP and executed through the Xbox lifecycle.

This tested a different path.

Instead of starting from a new idea, XCP had to begin with an existing software project, observe its structure and behaviour, adapt what could be represented on the target, execute it, and compare the result.

I deliberately do not call this universal Godot compatibility.

It demonstrates something narrower and more useful:

A real codebase can cross from source software to Xbox execution and come back with evidence about what actually happened.

The project survives the generation

This is the part of XCP I care about most.

A lot of AI-assisted development still behaves like this:

prompt
  ↓
generate
  ↓
files
  ↓
done

I wanted this instead:

create
  ↓
execute
  ↓
observe
  ↓
correct
  ↓
evolve
  ↓
execute again
  ↺

The same project has an identity.

Its versions have identities.

Executions belong to those versions.

Evidence belongs to particular executions.

A later change does not erase what existed before.

One lifecycle I exercised explicitly went:

1.0.0 → 1.1.0 → 1.0.0

Update and rollback are operations in the system, not an informal reconstruction of old files.

That is why I describe XCP as a software lifecycle for AI-assisted development, not simply an AI code generator.

What has already been exercised

Two paths were especially important:

Path	Result
New-project lifecycle	28 / 28 operations
Existing-source lifecycle with Minilens	14 / 14 operations
Declared semantic checks	passed for the published scenario
Version evolution	1.0.0 → 1.1.0 → 1.0.0

The creation path tested whether an agent could stay inside a project lifecycle beyond generation.

The Minilens path tested whether existing software could enter that same loop.

In both cases, the important boundary was the same:

the software had to reach a real Xbox execution target.

{% details Click to see more about the two paths %}

Creating new software

An agent can create an explicit XCP project, validate it, prepare it for the target, execute it, inspect the result, correct it and continue from another version.

The public creation programme completed 28 out of 28 lifecycle operations across an interactive project and a utility.

Adapting existing software

Existing software is harder because a project is more than its files.

It contains behaviour: input, state, collisions, scene transitions, timing, persistence and assumptions about the original engine.

The Minilens programme completed 14 out of 14 lifecycle operations together with the declared semantic acceptance checks for the published scenario.

That is why XCP treats adaptation closer to semantic reconstruction than file conversion.

{% enddetails %}

Xbox is actually inside the loop

Xbox is not just the screen at the end.

It is an execution target that produces information for the next development step.

Imagine an agent changes movement.

XCP can prepare the candidate, execute it on Xbox, observe what happened, and return structured evidence.

The next iteration can start from that evidence.

change
  ↓
Xbox execution
  ↓
evidence
  ↓
next decision

The AI itself does not run unrestricted on the console.

The agent remains on the development side.

Xbox exposes bounded execution surfaces, and XCP mediates what reaches the target and what comes back.

That separation is intentional.

The virtual machine that made this possible

The project actually started from a smaller experiment.

I wanted to know how much programmable execution I could create inside the public Xbox application environment.

That produced XVM, a deterministic virtual machine.

For XCP, XVM's most important property is simple:

New bounded work can reach the Xbox execution target without every new behaviour becoming another native Xbox application.

That turned Xbox from a fixed endpoint into a programmable part of the loop.

{% details Click to see what is inside XVM %}

The current XVM v2 reference implementation includes:

26 admitted opcodes
16 registers
typed memory
structured control flow
bounded loops and calls
static execution budgets
deterministic snapshot and resume
canonical CPU execution
GPU differential execution paths

The target still decides whether submitted work belongs to its admitted execution contract.

XVM does not remove the Xbox sandbox.

It creates a programmable layer inside it.

{% enddetails %}

“It ran” is not enough

Getting software to execute was only half of the problem.

A project can launch successfully and still be wrong.

Movement may work while collision behaviour changed.

A scene may appear correct while persistence is broken.

So XCP separates:

source behaviour
      ↓
semantic representation
      ↓
target implementation
      ↓
target observation
      ↓
evidence

This produced a rule that now sits at the centre of the project:

“It ran” is not the same claim as “it was preserved correctly.”

That difference is especially important when AI agents are involved.

Build succeeded gives an agent almost nothing to reason about.

Movement survived, but this collision consequence diverged gives it something concrete to fix.

{% details Click to see the deeper architecture %}

The broader pipeline is:

exact source
    ↓
source observation
    ↓
source model
    ↓
semantic IR
    ↓
capability admission
    ↓
target lowering
    ↓
execution
    ↓
observation
    ↓
differential evidence

Today the concrete public reference path is:

Godot → XCP → Xbox / XVM

Other source systems and targets are architectural directions, not completed compatibility claims.

{% enddetails %}

Now it is open source

This is the reason for this post.

I did not simply publish the original research repository.

That repository was a laboratory: Xbox experiments, runtime probes, games, adaptation prototypes, failed paths and multiple generations of the system.

Instead, I extracted XCP around the parts that should be reusable.

The public repository contains the platform, XVM, project tooling, semantic infrastructure, evidence contracts, conformance tooling and examples.

👉 https://github.com/Daniele-Cangi/xcp-xbox

You can start with the portable parts:

git clone https://github.com/Daniele-Cangi/xcp-xbox.git
cd xcp-xbox

python -m pip install -e '.[test]'
python -m pytest -q
xcp conformance all

You can also run the VM directly:

xcp xvm verify src/xcp/conformance/vectors/xvm-v2-call-chain.json
xcp xvm run src/xcp/conformance/vectors/xvm-v2-call-chain.json

Or inspect the project contract:

xcp project describe

{% details Click to see what I want people to extend %}

The first reference source adapter is Godot.

The first reference execution substrate is XVM.

The first real target is Xbox Series.

But the architecture intentionally separates those pieces.

Interesting contributions could include:

another source adapter
another runtime
another execution target
XVM tooling
new conformance vectors
evidence and verification tooling
examples
documentation
or simply a case that breaks one of the abstractions

A broken abstraction is useful too.

It tells us where XCP still contains assumptions that should not be there.

{% enddetails %}

The next important result should not come from me

This is probably the biggest reason I wanted XCP open.

So far, Xbox has been the forcing function.

It forced the system to deal with a real target, a sandbox, bounded execution, hardware observation and the difference between “it ran” and “it behaved correctly”.

Now I want to know what happens when other people push on the boundaries.

Can somebody build another adapter without rewriting the platform?

Can another runtime use the same contracts?

Can another target preserve the evidence loop?

Where does the abstraction fail?

Those results are more interesting now than another feature I could add alone.

XCP

GitHub:
👉 https://github.com/Daniele-Cangi/xcp-xbox

Studio:
👉 https://xcpstudio.com/

For the longer story of how the Xbox virtual machine evolved into this lifecycle, I wrote about that separately:

https://coderlegion.com/28314/i-built-a-virtual-machine-inside-the-xbox-sandbox-then-i-let-ai-agents-build-on-top-of-it

The VM was the first piece.

Now the platform is open for other people to build on top of it.

AI builds. Xbox executes. XCP observes. The project continues.