Skip to main content
Choose the type of service you are supplying, rather than a label for your whole company. A model publisher releases a model. An API provider runs the service that answers requests. They can be the same organization or different organizations. If you developed a model and serve it on rented cloud machines, you still supply your own model API. Renting infrastructure alone does not make your service a cloud-host type.

​
Which type should I choose?

Follow the arrows for one service until your answer names a service type or directs you to the organization running the API. If several roles fit, classify the particular endpoint you are applying to provide. Ask support before combining services with different upstream or hosting responsibilities in one application.

​
What each type must identify

The type changes the evidence for an exact model route: one model release served at an endpoint. All serving types need organization and domain review, route testing, and separate approval before customer access.
Example: Your team develops a text model and serves its release through your API, including when the machines are rented from a cloud company.
  • Name the exact release served by the endpoint. A moving alias such as latest or current is not an exact release.
  • Identify your API endpoint, region, allowed data, price, and route expiry.
  • Apply for the organization, then submit the exact release for route testing and review.
The provider and publisher are your organization; the infrastructure company does not become the applicant merely by renting you machines.

​
Publishing model files

Model-release material can include weights, configuration and tokenizer files, a model card, license metadata, and immutable release references or checksums. Serving engineers use that material to deploy a model. A customer can then benefit through an eligible API route serving it. The distinction is visible in Hugging Face model repositories and its separate inference task APIs: a repository contains model material; an inference service answers requests. If one organization offers both, classify its inference service separately. Published artifact evidence can help identify the model claimed by a route. It does not prove what an endpoint actually serves. Selecting the files-only option creates no inference endpoint, saved model, or run. This application does not provide a separate publisher distribution, hosting, or payment path. It also does not enroll raw compute or Millwork skill artifacts.

​
Which capabilities fit this application?

Provider role describes who runs the service. Capability describes what the endpoint does. Neither is the organization’s review status, the route’s state, or the customer’s billing arrangement. This application accepts APIs that take text-chat requests and return one complete text response. The route values are openai_chat and text_nonstream. Other endpoint types need a separate integration; HTTPS access alone is not enough.
The uses above explain where a service could fit; the rows requiring another integration are not runnable recipes. A separately registered agent endpoint can have its own integration contract, but it does not automatically admit an underlying service into the model catalog.

​
How the customer gets access

A customer’s provider account is the account used to access and pay for model usage. It is separate from your Provider application.
  • With the customer’s own provider account, the customer establishes access and the provider bills that account.
  • When Millwork provides eligible model access, its commercial and capacity requirements must also be met. Provider approval does not make that access available to every organization.
After route approval, activation and customer eligibility still determine availability. Follow From provider route to customer use for the catalog, saved model, run, result, and receipt handoff.

​
If you chose the wrong type

Before submission, change Service type in the application. After submission, use Provider workspace > Organization > Edit profile. Saving a profile change restarts organization review and domain proof and withdraws existing route approval. The workspace explains the next action; arrange the change before saving a service that already has active routes. If the corrected choice is files-only, contact support rather than forcing the organization into another serving type. There is no files-only conversion action in the current Provider workspace. Once the type fits your service, prepare your Provider application.