Inkpilots

Settings, Notifications, and Usage

Operations

This area controls the policies and operating signals that keep a workspace stable once it has real collaborators, active automation, public visibility, and ongoing usage. These settings do not define editorial strategy directly, but they strongly affect whether the strategy can be run reliably.

This page explains how the current product handles workspace policy, push notifications, usage history, and quota visibility.

What this area is for

Use these settings when your team needs to:

  • manage the workspace identity and slug,
  • control visibility and general workspace defaults,
  • enable or disable push notifications,
  • inspect usage history by reason,
  • understand quota consumption and plan limits,
  • keep public-facing interactive features within budget.

This is the operating discipline layer of the product.

General workspace settings

The general settings section controls the baseline identity and behavior of a workspace. The current form supports settings such as:

  • workspace name,
  • workspace slug,
  • visibility,
  • workspace tone,
  • image style,
  • language,
  • Google Analytics ID.

The slug workflow also includes availability checking, which makes this section part of the public identity and delivery model, not just an internal preference panel.

Why settings should be treated as policy

These settings affect how the workspace behaves for both operators and visitors. That means they should be treated as operational policy.

For example:

  • a slug change affects public identity,
  • visibility affects who can see the workspace,
  • tone and image style affect how the workspace is expected to present itself,
  • analytics settings affect how external traffic is observed.

When these settings drift away from the real operating model, confusion usually appears everywhere else.

Push notifications in the current product

Inkpilots currently supports push notification enablement at the workspace level. The notification settings surface handles:

  • browser capability checks,
  • permission handling,
  • service worker registration,
  • subscription enablement,
  • subscription removal,
  • save and delete calls against the push subscription API.

The current notification events are tied to workspace activity such as article generation and workspace header updates.

This means notifications are a real coordination feature, not a placeholder preference.

How to use notifications well

Push notifications should help the right people notice meaningful events. They are useful when they reduce operational lag, not when they add background noise.

In practice, teams should enable them when:

  • the browser environment supports them,
  • there is a real need to react to workspace events quickly,
  • the people enabling them actually need those alerts.

Notifications lose value quickly when everyone is subscribed to everything by default.

Workspace usage history

The usage tab gives the workspace a historical view of subscription and consumption updates. The current usage table supports:

  • filtering by reason,
  • sorting by time,
  • paginated browsing,
  • reviewing tokens used,
  • reviewing articles generated,
  • reviewing images generated,
  • reviewing API calls,
  • reviewing reserved batch tokens.

It also exposes reason labels for different usage events, including content generation and API activity.

This makes the usage view useful for forensic understanding, not just dashboard decoration.

Why usage history matters

Usage logs help a team answer practical questions such as:

  • where token consumption is coming from,
  • whether usage is mostly article generation, images, or API traffic,
  • whether a recent spike came from automation or external access,
  • whether the workspace is operating within expected limits.

This is especially important once agents, image generation, API access, and public chat all exist in the same workspace.

Billing and quota visibility

Inkpilots also exposes billing and quota information so the user can see plan limits and current consumption clearly.

The current billing and quota views surface:

  • current plan,
  • monthly token allowance,
  • estimated article output,
  • estimated image output,
  • API request allowance,
  • current token usage,
  • estimated article usage,
  • estimated image usage,
  • overage pricing where relevant.

This helps the team understand both hard limits and operational headroom.

Public chat and usage policy

Public chat is configured in its own tab, but it belongs in the same operating conversation because it has explicit monthly token controls. Teams should think about it as part of usage governance, not just as a feature toggle.

If public interaction grows, the workspace should revisit limits and usage patterns before the feature becomes unexpectedly expensive or constrained.

Recommended operating practice

Review settings when the workspace model changes

If the workspace changes audience, brand direction, or public visibility, revisit the core settings instead of assuming the original defaults still fit.

Enable notifications selectively

Only enable push alerts for users who benefit from fast operational updates.

Check usage before hitting limits

Usage history and quota views are most valuable before failures happen. Teams should use them as early warning tools.

Watch API and automation together

When agents, images, API access, and public chat all consume resources, quota management should be handled as one operating problem rather than four separate ones.

Common mistakes to avoid

  • Treating settings as one-time setup instead of living operating policy.
  • Enabling notifications without deciding who actually needs them.
  • Looking at usage only after generation or API behavior becomes a problem.
  • Ignoring quota trends while scaling automation or public interaction.

How this page connects to the rest of the handbook

Use this page together with:

Related guides