Services and spending

A Service is a reusable, account-owned configuration. A Script calls a local name; a Run binds that name to a published Service revision. Saving or publishing a Service does not rewrite Script source or silently change existing Runs.

Use ordinary QubeScript functions and expressions for deterministic work such as the practice quiz’s scoring. Use a hosted service only when the questionnaire actually needs external processing and the deployment permits it. Online service use has separate beta limits.

Create and publish a configuration

  1. Open Services in the Test console and choose the owning Account. Editing requires its authorized operator access.
  2. Choose New service. Enter its name, select an available Model, and write the Prompt for the intended task.
  3. Set Output schema (JSON) to the result shape your script expects. If using Fallback result (optional JSON), review what that result means and ensure it fits the schema. A fallback is not a successful provider result.
  4. Choose Create service for the new record. Later edits use Save draft. Resolve any unsaved changes before publishing.
  5. Choose Publish saved draft. Review Published history to inspect the immutable revision and its configuration hash.

Publishing creates a selectable revision. Runs remain unchanged. Archive service removes it from ordinary selection; Show archived and Restore service let an authorized operator inspect or restore the library entry. Historical pinned revisions remain distinct from the current draft.

Bind a Run to a revision

  1. Open the Run’s Settings, then Published service bindings.
  2. Choose Add binding. Enter the exact Script-local service name used by service.call, and select a Published service revision from that Account.
  3. Choose Save bindings. If the Run changed concurrently, reload and review rather than overwriting the newer configuration.
  4. Test the Run with invented input. Check successful output, failure or fallback, retry and Back behavior against the result contract your source expects.

Saved binding changes apply to future starts. Existing attempts keep their pinned revisions, and publishing another Service revision does not update the binding. The script owns how the returned result affects routing, text and study decisions; the platform owns authorization and the recorded result used for replay.

For older Run-local configurations, Check compatibility produces an audit. Import and bind services is available only when the audit permits it. It creates separate published library entries and bindings for future starts; it does not silently reinterpret an incompatible legacy configuration.

Review access and budgets before online work

Check the selected Account’s billing page and ask its authorized operator to confirm the intended AI access and available credit. A paid editor seat or a published Service is not an unlimited provider allowance. Self-service purchases are not enabled during the invitation-only beta; displayed plans are not proof of active credit or access. See People, access and billing.

These costs and limits are separate:

  • Your local AI assistant uses its own provider account and pricing. Local MCP language checks do not call a model or spend QUBE Agent credit.
  • Hosted QUBE Agent work uses prepaid credit and the spending ceiling you approve for that work. Review the ceiling in the Agent UI before starting it.
  • Online service previews have separate authorization, claims and credit limits.
  • Respondent service calls have activity/account attempt and capacity limits. A limit refusal means the call cannot proceed; contact the activity owner. This guide does not offer a customer-editable monetary budget for every respondent call or claim complete respondent-cost settlement.

Service-library editing is configuration work. It does not itself call the provider. Use invented data for authorized online tests, and consider that prompt input can be sent to the configured provider. Do not put credentials into source, prompts, service names or returned results.

Current limits

Hosted QSS service calls must match a pending request verified against the attempt’s pinned source. The service result is recorded for native replay; reloading or going Back must not be treated as permission to request arbitrary new provider work. These controls do not make the questionnaire or provider output confidential from its participant.

For timed activities, Show summary in Portal controls the Portal summary. Hiding that summary does not hide service results already shown during the activity or make an answer key confidential. Use the current practice features for visible feedback rather than consequential secret marking.

Hosted quota collection remains disabled in the current deployment. Use Fieldwork for Run operations and Survey MCP for available assistant connections.