Allora has launched Worker Hosting on Forge, Allora's platform for building and running prediction models. It gives builders a managed path from a compatible model package to a running worker that submits predictions to the network.
This removes a major operational barrier between building a model and putting it to work on the network. Instead of assembling separate systems for package validation, runtime-image build, compute, signing, deployment, monitoring, workload control, and usage, builders can manage the complete operating path through Forge.
Builders upload compatible worker code, dependencies, a manifest, and optional model weights. They select a supported topic with a defined forecasting task, choose the network, and configure the required compute and resources. The package then moves through validation, security checks, build, deployment, and managed signing. Once the worker is running, Forge provides status, logs, workload controls, balance, and usage history in one place.
The purpose is specific: bring deployment, operations, and usage controls into one workflow designed for Allora workers, so builders can spend more time on the model itself.
One managed path to a running worker
Worker Hosting turns operating an Allora worker into a product workflow rather than a separate infrastructure project.
Before a model can participate, its builder needs more than a working prediction function. The worker has to be packaged correctly, checked, built, provisioned, connected through signing, kept observable, and funded. Each stage can stop a model from reaching live evaluation even when the model itself is ready.
Bringing those stages together changes what Forge enables. Builders can move from model work into deployment and ongoing operations without leaving the product to assemble the surrounding stack. The worker can be checked, launched, observed, controlled, and funded through one operating surface.
The model still has to perform. Worker Hosting makes the route to proving that performance substantially more direct.
The work around the model
A model that performs well in development is not yet an operating Allora worker.
Running that model against a live topic requires a compatible package, compute, and the correct signing path. The package needs to be checked and built into a runtime image. The resulting workload needs to be deployed, observed, and funded. Builders also need controls for pausing, resuming, or deleting it when operating conditions change.
None of those tasks improve the model's features, training process, or predictive logic. They are infrastructure requirements around the model.
Builders can already operate that infrastructure themselves. Worker Hosting adds a managed route for those who want to move from a compatible worker package to an operating worker without assembling the complete hosting stack.
From package to deployment
The flow begins with a compatible worker package. The package can include code, dependencies, a manifest, and optional model weights. Packages that support training or retraining can also include the relevant resource and schedule settings.
The builder selects a supported Allora topic and network, then configures the compute and resources the worker needs. Availability, resource options, pricing, and any access limits should be read from the production product at the time of deployment.
Before deployment, Forge validates the package and runs security checks. It then builds the runtime image. This order matters: checks happen before build and deployment.
Forge provisions the worker in a managed isolated runtime and configures managed signing for the selected destination. Once deployed, the worker's state and logs are visible in Forge. Builders can pause, resume, or delete the workload as needed.
Usage controls sit in the same operating view. Builders can review estimates, balance, and history, then top up credits through the supported payment flow.
The result is one connected path across package configuration, checks, build, deployment, runtime operations, and usage.
The ownership boundary
Worker Hosting changes who operates the surrounding infrastructure. It does not change who owns the model.
The builder retains control of the model, code, data dependencies, weights, logic, and output quality. Forge does not create or improve the model, take ownership of it, or make decisions about its predictive behavior.
Forge operates the managed isolated runtime, signing path, deployment lifecycle, monitoring surface, and usage controls. This boundary lets a builder use managed infrastructure without turning the model itself into a managed asset.
That distinction also defines what Worker Hosting does not do. Hosting does not make a model more accurate. It does not train the model. It does not guarantee access to a topic or rewards from one. Performance still depends on how the worker scores within the topic's regret-based scoring loop.
A managed deployment path, not a separate scoring path
A hosted worker participates in the topic as a worker. Its deployment route does not create a different standard for evaluation.
The model still submits predictions according to the topic's epoch, target, and required format. Ground truth still arrives through the reputer role. The scoring loop still measures the worker against realized outcomes, and rewards still depend on performance within that loop.
Compute credits pay for the resources used by the hosted deployment. They do not buy topic access, a better score, or a preferred position in the network inference.
This separation is important for builders comparing a hosted deployment with infrastructure they operate themselves. Worker Hosting changes the operational path. It does not change the prediction task or how the network judges the worker.
Builders can therefore choose an operating model based on their own infrastructure capacity. The worker remains accountable to the same topic rules either way.
What changes for builders
Worker Hosting reduces the amount of operational work required to establish and observe a running worker.
A builder can move from a compatible package into a deployment without first designing a separate build, compute, signing, monitoring, and billing stack. Configuration and operating state remain visible in the same product.
That makes the path from development to live evaluation easier to inspect. Builders can follow validation and build state, read runtime logs, control the workload, and track credit use. They can then return to the work that determines performance: data, features, model design, and adaptation to the topic.
Builders who prefer to manage their own infrastructure can continue to do so. Worker Hosting adds another operating path for builders who want Forge to handle more of the deployment layer.
The model still has to earn its place through performance. Worker Hosting makes it simpler to put that model in position to be evaluated.
