Early Access

Describe your use

Tell us about the kind of work, the deployment environment, and the capabilities that matter to you. Keep private source material and credentials out of the inquiry.

Understand the boundaries

Feature availability depends on the release, permissions, and configuration. Access requests do not guarantee a release date, invitation, or particular capability.

Get in touch

Use the contact page for current access information. Include your intended use and environment so the project can respond with relevant guidance.

Request early access

FridayLocalAI is available through early-access inquiries. Contact the project to discuss access. There is no public installer, and the FridayLocalAI Store is not accepting purchases. Include your intended task, operating environment, relevant hardware, and whether you need local-only or connected workflows. We will discuss the next steps; an inquiry does not guarantee an invitation, release date, or response deadline.

Ask Friday to guide you

In an authorized FridayLocalAI conversation, try:

I have been given access to FridayLocalAI. Help me get oriented one step at a time. Start by asking what I can see on the screen and what task I want to complete.

Tell Friday what you can see and which step you have reached. If the instructions do not match your screen, say so; ask for the relevant Help topic or contact your operator. Friday cannot be assumed to see your screen or know your current settings.

What an early-access inquiry is for

An early-access conversation helps the project understand what you want to do and whether the current deployment path fits that work. It is the appropriate starting point if you are interested in FridayLocalAI but have not been given access. It is not a checkout process, a guaranteed invitation, or a promise that a requested feature will be available on a particular date. Describe the practical outcome you need. A few concrete examples are more useful than a long list of general AI interests. You might want to organize ongoing research, review approved documents, develop drafts across several conversations, or evaluate a configured creative workflow. State which outcome matters first so the discussion can focus on a manageable starting point rather than an assumed all-purpose deployment.

Explain your environment

Provide the operating environment and relevant hardware details you know, along with the intended number of users and the kind of material involved. Mention whether work must remain within a particular infrastructure arrangement or whether optional connected services are acceptable. Mark unknown details clearly instead of guessing or copying another person’s configuration. Keep the initial inquiry non-sensitive. You do not need to send account credentials, private source files, full logs, or internal network details to explain a use case. If the project needs additional information, agree on the appropriate channel and scope. This makes the first discussion easier to review and reduces the chance that an ordinary access question becomes an unnecessary transfer of private material.

Identify essential and optional capabilities

Separate what you need to begin from features you might want later. Basic conversation and saved project work may be essential, while a particular provider integration or media workflow may be optional. Explain the inputs and results for each important task so the project can discuss availability in concrete terms. Do not assume that every visible panel or documented concept is enabled in every early-access installation. Role, configuration, model support, and operator decisions affect the available workflow. A clear list of priorities helps distinguish a current fit from a future possibility. It also creates a more useful basis for a small evaluation than a broad request to enable every capability at once.

Plan a meaningful first exercise

Choose a harmless task that resembles the work you want to do. For example, use a short practice document to test source-grounded questions or use fictional meeting notes to test summaries and revisions. Define the result you expect and how you will check it. This gives the early-access discussion a practical acceptance target. The exercise should be small enough to understand without exposing private information or making consequential changes. It should also reflect the capability you care about. A simple text response does not establish that a complex document or media workflow is suitable. The project and operator can help identify the appropriate sequence once the deployment and access boundaries are clear.

Understand the distinction between accounts

Application access belongs to the FridayLocalAI deployment supplied by the operator. The public website provides information and consumer documents. The store is a separate surface and is not accepting purchases. A store account, a third-party book purchase, or downloading a PDF guide does not automatically provide an application workspace. Use the access address and instructions you are given rather than assuming all installations use the same public route. If you are already a participant and cannot sign in, contact the operator through the agreed support process. Do not create unrelated accounts or enter credentials into a different service in an attempt to resolve an access issue that needs deployment-specific assistance.

Be ready to give useful feedback

Early access is more valuable when observations are clear and bounded. Record what you tried, what you expected, what happened, and whether the issue can be reproduced with a small example. Distinguish a confusing label from a missing capability and an incorrect answer from a failed request. Those details help the project understand what needs explanation or repair. You can ask Friday to organize your observations into a draft report after access is working. Review the report before sending it, especially if it mentions sources or technical details. Do not let the assistant turn an uncertain observation into an unsupported diagnosis. A good early-access relationship begins with a realistic task, a clear operating boundary, and feedback that can be connected to evidence rather than a promise that every desired workflow is already complete.

A useful final check

Before contacting us, identify one task you would like to try first and the result that would make the trial useful. That gives the discussion a concrete starting point.