Skip to content
littleworksdocs

Explore the documentation

Meet LittleworksA little backend for what you’re building on Shopify.Connect to LittleworksChoose the CLI, a plugin, or a remote MCP connection.CLIConnect from your terminal with Shopify approval and no manual tokens.Claude pluginThe Littleworks MCP connection and agent guidance in one package.OpenAI pluginThe Littleworks MCP connection and agent guidance in one package.MCP with OAuthConnect a compatible client directly, without a marketplace plugin.Build with an agentThe operating guide for agents building on Shopify with Littleworks.Write a workA JavaScript handler, a small manifest, and an immutable version each time you deploy.Keep secretsEncrypted credentials, shared across your store’s works.Call external servicesMake public HTTPS API requests from a work using http.fetch().Store dataDocument collections with a small API, scoped automatically to the work that uses them.Call ShopifyUse Shopify’s GraphQL API directly, with credentials held by Littleworks.Expose an endpointConnect an existing frontend to a work through a small JSON API.Customer access and invitationsRequire a signed-in shopper or a narrow, expiring invitation before a work runs.MCP tool referenceTen tools to inspect, deploy, run, and manage the backend for a connected store.Usage and allowancesSee what your works use, how much capacity remains, and when allowances reset.Inspect and troubleshootFind the relevant run, understand the failure, and make the next change deliberately.Limits and securityThe current runtime boundaries, data isolation model, and execution allowances.
Shopify admin
Reference
Markdown

Usage and allowances

See what your works use, how much capacity remains, and when allowances reset.

In Littleworks, open Works → Usage & plan. The page shows current allowances across Live and Preview, with breakdowns by environment and work. Agents can call get_usage without running or changing a work.

Inspect usage from the CLI
littleworks call get_usage '{}'

Activity over time

Choose the last 7, 14, or 30 days and filter by Live or Preview. View daily runs and external requests as line charts, compare the previous period, or expand Activity data for the underlying values. Today is partial; the final comparison day ends at the same time of day in UTC. Work rankings cover the current calendar month. Current capacity always covers both environments.

get_usage.history includes daily activity for up to 60 UTC dates, including today, so agents can calculate the same comparisons. Activity comes from retained run records, includes failed runs and deleted works, and survives detailed-log cleanup. External requests are attributed to the run’s start time. Storage shows a current snapshot; historical storage snapshots are not recorded.

What counts

  • Runs count when execution is admitted, including runs that fail or time out. Invalid authorization, rejected input, paused works, rate-limited admissions, and idempotent replays do not consume another run.
  • External requests count each admitted outbound attempt, including redirect hops. Allowance totals use the attempt time; work/environment breakdowns group attempts by their run’s start time, so they can differ around a UTC reset.
  • Storage counts UTF-8 document bodies and records across features and environments. Expired records occupy space until cleanup. Data shared by a feature is not attributed to one work.

Shared capacity and reset dates

Current daily and monthly run/request allowances reset at midnight UTC and the start of the next UTC calendar month. get_usage.period contains exact dates. Storage does not reset. The page warns at 80% and 95% and shows when a limit is reached. Refresh for current usage; in-flight activity can cause small differences between counters and breakdowns.

Customer-facing traffic uses a portion of the store allowance, leaving capacity for merchant and agent runs. Each customer-facing work also has daily, monthly, per-minute, and concurrency limits shared across Live and Preview. Expand Daily and customer-facing limits to see them. See Limits and security for execution constraints.

When a limit is reached

A run allowance stops new executions. A storage allowance stops net growth; reads and space-releasing changes remain available. You can still inspect, pause, and delete works. Deleting a work does not erase its usage. Before retrying a failed run, check for partial effects.

Protection notices are sampled signals, not a complete count of blocked traffic. They explain the affected work and the retry time. Respect Retry-After; do not automatically replay mutations or switch environments to bypass a limit. Usage visibility does not change your plan or create a charge.