ASL AI Hub desktop help center
Support: support@autosecurelogin.com. Include the app version, exact error, first and most recent occurrence with timezone, and the last successful stage. Never send provider tokens, fleet keys, private signing keys, complete journals or customer inputs/results without reviewing what is needed and authorized.
1. AI providers and fleet work are separate
New to the hosted service? Start with the account, subscription and first-task guide. It explains the $19/$49/$149 monthly plans, separate provider charges, recovery codes, payment confirmation and online cancellation. Open the public web app or download the free Windows Companion.
AI Hub Companion is a native Windows application with two independent workspaces. AI providers connects the supported provider/pairing workflow to your chosen AI Hub workspace. Fleet workflows plans approved work on machines you control, through your chosen rBroker coordinator. Neither connection authorizes the other.
AI Hub Companion is free to download. Customers pay separately for the ASL-hosted AI Hub service; that subscription is not a purchase of this desktop app. The service account provides plan selection, Stripe-hosted checkout and billing management when available. Customer-operated fleet hosting and third-party provider accounts remain separate. The Companion does not contain an embedded card-entry form or silently subscribe you when you pair or join a fleet.
You can use AI Hub without PC Steward or Master Suite. Remote execution needs a compatible, enrolled resource node such as rBroker; merely installing AI Hub on a laptop does not create a GPU server on another PC. rBroker also works without AI Hub for local integrated GPU clients, CPU jobs and fleet administration.
PC Steward contributes diagnostics and readable resource observations, not a second scheduler. Master Suite embeds these native capabilities in one separately purchased application with its own protected profiles. It does not require three other installed programs, and it does not silently import their credentials.
Opening a tab does not purchase AI usage, join a fleet, approve a workflow or install an always-running Windows service. Review each explicit operation.
2. Connect a provider workspace
Use the AI providers workspace to enter the trusted workspace address and follow its supported sign-in/pairing process. Select the intended provider and review the current connection state before requesting work. A signed-in browser or official AI client is not automatically an authorized connection to this app.
When pairing an official desktop client, use the supported one-time pairing flow. Do not paste browser cookies, a Windows password or an unrelated session's token into a connection field. Provider accounts, workspace permission and local client availability are separate checks; an expired pairing is not permission to reuse another person's account.
Usage limits, API charges, subscriptions and model availability belong to the provider and account you configured. Downloading the free Companion or subscribing to the ASL service does not include unlimited third-party AI usage. Cost labels must distinguish a measured charge, an estimate and an unknown amount. A connection failure is not proof that a call was free or that an earlier operation did not run.
3. Connect a fleet across different networks
The fleet needs a coordinator reachable by all participating machines over trusted HTTPS. Its hostname is configurable; ASL hosting is not mandatory. A Linux server or suitably configured Windows server can host it. The server operator owns certificate, backup, storage and availability responsibilities.
In Fleet workflows, configure the intended fleet and named dispatcher credential. Use the credential for this role, not a viewer key or node private key. Save the profile in this application's protected local storage. Do not put the private profile in a shared project folder or source-control repository.
On each worker computer, use rBroker or Suite's resource workspace to join the same fleet. Join fleet submits public enrollment information; manual JSON export/import remains available. The node's private signing key stays there. Then explicitly approve the dispatcher, permitted handlers, resource ceilings and consent expiry. Fleet membership by itself does not permit execution.
Nodes contact the coordinator outbound. Do not expose their loopback GPU broker or CPU-worker ports publicly or disable a firewall as a setup shortcut. Viewing resources is not an allocation, and a connected but unapproved node cannot run your job merely because its screen is green.
4. Create a plan that explains the work
Give the overall workflow and every step a title, project, purpose, stage and expected result. Prefer “Prepare forest scene for episode 1” to a session ID. Keep IDs for precise correlation, not as the only explanation. Do not include private prompts, credentials or sensitive file paths just to make a label longer.
Choose the actual target computer and one of its registered handlers. Set worker count, system-RAM requirement and any GPU-memory requirement. Select the exact input and final destination. Add dependencies so a later step cannot start before its required input is verified. Save the plan, read it, and approve that exact saved version before advancing it. A draft or validated form is not submitted work.
The current reviewed handlers cover bounded JSON work, hashing and the supported shape-animation/media path. A handler is a registered local capability, not an arbitrary remote shell. Media execution requires an explicitly reviewed local encoder and supported hardware. The app does not automatically install creative tools, models or third-party licenses on every enrolled computer.
A useful pattern is a CPU/RAM-rich workstation preparing scene data, a GPU workstation performing supported encoding, and the everyday laptop verifying and receiving the output. This illustrates scheduling and delivery; it is not a promise that an unrestricted cartoon prompt becomes a production-quality film or that every existing creative application has a registered adapter.
5. Approval, advancement and actual resources
Advancing an approved workflow offers eligible steps with their saved identities. The selected node validates scope, permission, handler availability and current ownership, then obtains local resource admission before executing. A claim is ownership of an attempt, not a GPU lease or a RAM grant by itself.
CPU worker slots and declared system RAM are admitted by the canonical parallel-worker authority. Supported GPU work also obtains its own GPU RAM lease. These are separate pools. System RAM is not graphics memory; a machine with spare GPU bytes may still lack CPU slots, system RAM or an approved handler. Declared RAM admission is scheduling accounting, not a physical-page pin or an OS hard limit on unrelated programs.
The node has the final decision. AI Hub does not bypass a stale capacity check, borrow another task's lease or extend an expired grant. Authentication rejection is not a temporary grace period. Read the original task/attempt and stopped state instead of creating duplicate work to make a conflict disappear.
The local Windows allowance is one configured GPU budget item. OMEN acceptance uses one 5,120 MiB allowance; this is not imposed as a capacity promise on every customer card. Status observations and driver allocations are labeled separately from committed leases. Unknown memory is never treated as free.
6. Input files, results and delivery
Approved content transfers use separate fleet/job/artifact-scoped authorization. The sender uploads bounded encrypted chunks; the receiver verifies the completed content before publishing a final file to the chosen destination. An existing unrelated file is not silently replaced. Make sure the coordinator and receiver have enough space for pending content as well as completed results.
Follow the displayed stage: queued, admitted, executing, stopped, transferring and delivered mean different things. A completed render with an unfinished transfer is not a delivered result. A subsequent dependency uses the verified predecessor output, not an unverified filename from an earlier attempt.
If the network drops, reopen the original workflow and resume. Confirmed chunks are reused; missing chunks are sent. A lost upload acknowledgement is reconciled with the same transfer. Do not render the job again just because a response was lost or the laptop was temporarily offline.
For server operators: a 256 KiB binary chunk becomes roughly 342 KiB in its JSON/base64 request. Use the documented 384 KiB proxy allowance for the bounded 360 KiB application request limit. HTTP 413 is a transport-size failure, not a GPU lease failure. Keep the authenticated route and role restrictions intact.
7. Recover, cancel and archive
Reopen the same saved profile after interruption. Preserve the workflow ID, approved plan hash, node fingerprint, attempt IDs and receipts. Unknown means the outcome is not confirmed; it does not mean the work failed and can be repeated. An exact-offer retry reconciles the same saved request rather than inventing a second job. Do not rotate a node key or erase a journal to bypass a warning.
Cancellation requests a stop from the owning node. It is not an immediate release of someone else's resources. Claimed ownership remains until stopped evidence is confirmed. A stale screen, disappeared PID or 404 after a service restart cannot by itself prove the original work never ran.
Archive completed workflows explicitly after required destinations are verified. Archive history preserves readable plans and receipts in protected storage and retains replay protection; it does not delete your delivered files. Pending or uncertain work cannot be concealed by archiving it. History is bounded and paged; use the archive view instead of interpreting only the recent page as all history.
Damaged or missing initialized workflow storage fails closed. Preserve it and the original identity for recovery. Do not delete the private directory, restore only half a profile or open new-schema state with an older writer. See the packaged/repository FLEET-WORKFLOW-ARCHIVES guide for operator-level details.
8. Closing the app and always-running nodes
AI Hub plans and advances workflows; rBroker or Suite resource hosting owns the node executors and local engines. Closing AI Hub is not a command to kill remote accepted work. Reopen the same profile to reconcile the original plan. Do not assume a closed monitoring window means the remote job stopped.
For a node that should work without a signed-in desktop, install the optional rBroker Windows service with explicit administrator approval. Its LocalService identity and CPU-only execution consent are separate from the desktop profile. Installation is not automatic when you buy or open AI Hub. Sleep, power loss and network loss still affect availability. Drain accepted work before a service upgrade; never restart a shared broker merely to test this screen.
Linux headless nodes use the same outbound protocol. Apple platform scaffolding is not tested macOS hardware support. Windows 10 laptop acceptance remains a separate physical test, not something proved by a minimum-version manifest.
9. Troubleshooting in order
- Cannot connect: confirm the configured origin and certificate, then the correct role credential and actual server version. A viewer working elsewhere does not prove this dispatcher is authorized.
- No eligible computer: check fresh node reporting, handler support, both consent records, expiry, worker count, system RAM and GPU policy independently.
- 401 or 403: authentication/authorization was rejected. Stop and correct the intended credential or permission; do not retry as another identity.
- 409: reconcile the saved request and current attempt/revision. Do not create a duplicate offer to bypass ownership.
- 503 or timeout: retain the original pending action and last confirmed state. Reconnect and reconcile; a responsive health page is not proof every mutation path is healthy.
- Output not delivered: inspect transfer stage, available disk space and verification. Resume the original content rather than rerunning completed work.
- Damaged local history: preserve it, do not treat it as an empty success. Contact support before replacing keys or private storage.
10. Verify your setup and get support
Start with non-sensitive sample data and one modest CPU job. Watch its readable title on the intended node, confirm the final output digest and destination, and verify its worker/RAM commitment releases afterward. Then test your supported GPU handler with its own small lease. Confirm an interrupted transfer resumes under the original job rather than executing twice.
Keep source/build tests, installed-package behavior, hardware acceptance, Store submission and public availability separate. A new help guide is not an automatic upgrade to an older installation. Review the version shown by each app and server.
Email support@autosecurelogin.com with the versions, readable task description, exact failing action and state, first/last occurrence with timezone, and last successful step. Review exports locally first. Do not email private configuration, full payloads or credentials. No support response-time guarantee is implied.
Content safety and reporting: the Help center's Report inappropriate content button opens a draft addressed to support@autosecurelogin.com. Nothing is sent automatically. It reads or attaches no task, prompt, result, identity, credential, private file or log. Enter a brief concern, app version and time yourself; do not attach harmful media or confidential material. If Windows has no email app, use the displayed support address yourself. Opening a draft is not a submitted report. There is no public feed or promise of automatic moderation.
Use only material and providers you are authorized to use. Do not use ASL tools for child sexual exploitation, non-consensual intimate content, threats, hateful abuse, fraud, malware or other illegal harm. Do not request or distribute pornography or graphic real-world violence. Respect privacy, intellectual property, provider policies and fleet-owner rules.
Review generated material before sharing it. Contact the private fleet's owner as well as ASL for concerns in a customer-operated deployment. Stop automatic advancement and use supported cancellation/consent controls; preserve unresolved ownership and recovery state. ASL reviews concerns involving its products or operated services and can restrict affected access where it has control.
The customer server owner controls its retained copies; a report cannot silently remove data on someone else's server.