Plan around the workload
Hardware Requirements
Choose the machine for the work.
Model size, context length, simultaneous work, document processing, and media generation all influence resource needs.

Begin with supported deployment guidance
Confirm the operating environment and requirements for the specific release. This page does not certify a universal minimum specification or every laptop, workstation, or server.
Plan memory and compute
Choose models that fit the available resources and required input types. A text workload and a media-generation workflow can have very different needs.
Explore this topic →Plan storage and recovery
Allow space for models, application data, source files, artifacts, and operational records. Keep a documented backup and recovery process.
Validate representative work
Test the tasks, concurrency, and response times you actually need before treating a hardware configuration as suitable.
Explore this topic →Describe the workload before buying
For an early-access inquiry, provide your operating system, RAM, GPU and VRAM if known, free storage, expected simultaneous users, and a representative task. The project can discuss a suitable setup. No fixed minimum, benchmark, or hardware purchase is certified by this page.
Ask Friday to guide you
In an authorized FridayLocalAI conversation, try:
Help me prepare a hardware suitability questionnaire for FridayLocalAI using specifications I provide. Ask about text, documents, images, media, context length, and concurrent work. Identify missing information without claiming you inspected my computer.
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.
Begin with a workload description
Hardware planning for local AI starts with the work you want to complete. A short text conversation, a long document review, and a media-generation job can place different demands on the environment. Describe the input sizes, expected output, number of people working at once, and acceptable response time. Include whether the system will also support other applications or shared services. Bring that description to the FridayLocalAI project before buying equipment specifically for early access. The website does not publish a universal minimum configuration or certify a particular consumer computer. A useful recommendation needs the intended release, selected models, enabled workflows, and operating conditions. A specification that works for a demonstration may not be suitable for sustained use with larger inputs or more concurrent work.
Understand memory and model choices
Model files occupy storage, and running a model also uses working resources. The amount needed depends on the model and how it is used. Context length, input processing, and concurrent activity can change the demand. A model that appears in a list is not necessarily a sensible choice for every machine or every task. Use the available model-management information and the operator’s guidance to make a selection. Safety rails may warn about or block choices likely to exceed configured limits, but they are not a performance guarantee. Start with a supported option and a small task. When comparing alternatives, check the actual model attribution and keep the test inputs consistent so the result is not confused by unrelated changes.
Treat GPU specifications as part of the picture
A GPU can be relevant to some local AI workloads, but a product name or a single memory figure does not establish compatibility or throughput. The selected software, model, workflow, and supported execution path matter. Avoid choosing a machine solely because a listing uses an AI label or a benchmark from a different task looks impressive. Provide the operator with the exact GPU model and available specifications if you know them, along with system memory and the operating environment. If you do not know a value, leave it unknown rather than guessing. Friday can help organize information you supply into a question list, but it should not claim to inspect your hardware unless the application has a permitted way to obtain that evidence.

Plan storage for the lifecycle of work
Storage requirements extend beyond model downloads. Conversations, source files, generated artifacts, operational records, and recovery copies all need an appropriate plan. Different deployments can place these resources in different locations. Confirm the intended arrangement with the operator instead of copying another person’s paths or moving application files because a directory looks large. Consider how material will grow over time and how useful outputs will be retained. A media-heavy workflow can have different storage characteristics from occasional text use. Identify who maintains backups, what is included, and how restoration is validated. Those are operating questions, not reasons to expose private file listings or credentials in a conversation. Share only the specifications and context needed for the planning discussion.
Run a representative acceptance exercise
Choose several small tasks that reflect the intended use. Include a basic response, a source-dependent answer if documents matter, and a representative artifact workflow if that capability is part of the plan. Define what counts as useful output before running the exercise. A fast but inaccurate answer may be less valuable than a slower response that needs little correction. Record the selected context, active model attribution, approximate workload, and observed result. Do not generalize one run into a universal benchmark. If the result is poor, separate resource constraints from unsupported inputs, missing context, and configuration issues. Work with the operator to change one relevant variable at a time. The goal is evidence that the proposed environment fits your work, not a competition over specifications.
Prepare a clear early-access inquiry
Include your operating system, RAM, GPU and VRAM if known, available storage, intended user count, and two or three example tasks. Explain any need for offline operation or connected features. State which details are confirmed and which require help. Do not include account passwords, private keys, or unrelated personal information. The project can then discuss the relevant access and deployment path. There is no public installer or current store purchase to use as a shortcut around that conversation. Consumer guides explain how to use the application after authorized access is established; they are not a hardware warranty or a clean-machine installation package. Plan around verified suitability and ongoing operating responsibility rather than an assumption that every modern computer is interchangeable.