Finish with a hosting decision, not a shopping list
Use this path when you need to decide where a small AI-assisted publication or research workflow should run. The deliverable is a one-page decision sheet: workload, existing services to protect, execution location, cost assumptions, missing measurements and the next permitted experiment. This is a planning exercise. Following the links does not install a model or establish your server's capacity.
Bring these inputs
- One representative task, such as preparing a source-backed research brief without publishing it.
- Expected requests, an acceptable response time and the information the task is allowed to process.
- A dated resource observation from the host you actually intend to use, plus the services that must remain available.
- A spending and operator-time cap. If a number is unknown, leave it unknown rather than copying a vendor's best case.
1. Separate work that needs a process from work that needs a file
Read the small-server deployment case. Its private editor, static public pages, browser features and separate submission receiver have different operating needs. Classify your own task the same way: finished document, browser-local calculation, occasional job or continuously available service.
Write a provisional placement beside each item. For reference, the case's sanitized evidence JSON includes an October 28 snapshot and a later artifact check. Those dates matter. They do not describe your host or reserve memory for a new service.
2. Keep hardware and attention in the same decision
Read the local-AI hardware and attention budgets. Record model location, hardware allocation and review work separately. A zero API token price does not cover a new machine, electricity or time correcting outputs. If GPU fit, startup peak or sustained performance has not been measured, list it as a trial requirement.
Your output for this stage is a short risk list with an owner and a measurement for each unknown. For example: memory during one representative job, time checking a brief and behavior when a source is unavailable. Do not turn a proposed measurement into an observed result.
3. Calculate two explicit scenarios
Open the cost calculator and retain a baseline before changing assumptions. The published worked-case JSON makes a useful arithmetic check: its illustrative default returns $150.80 monthly cost and $0.01885 per accepted result. Setting both API token prices to zero while keeping its overhead returns $120 and $0.015.
Reproduce those two cases, then replace their hypothetical workload, prices and review budget with your own inputs. Save or export the assumptions. Equal acceptance rates across two options remain an assumption until tested; the arithmetic does not compare model quality.
4. Check a cost shortcut before using it
If the plan depends on cache savings, read the stable-input caching guide. Identify the repeated material and the actual provider behavior you would need to observe. Until you have that evidence, keep a no-discount baseline. This path does not apply a headline cache discount to your bill.
Completion check and next step
- The decision sheet names a task and an execution location, including any remote provider.
- It keeps dated measurements, estimates and unanswered questions in separate fields.
- It contains two cost scenarios with their inputs and an explicit rule for accepting an output.
- It states which existing service could be affected, how the trial stops and what evidence is needed before moving further.
If the host is unsuitable, stop the placement decision rather than force an installation. If the budget is plausible but quality is unmeasured, continue with a bounded pilot and stop condition. If the workflow can change or publish data, use the permission-to-proof path before granting those actions.