{"course":{"slug":"running-models-yourself","title":"Running Models Yourself","url":"https://addaly.com/learn/running-models-yourself","level":"intermediate","track":"deep"},"lesson":{"slug":"the-hours-nobody-invoices","title":"The hours nobody invoices","url":"https://addaly.com/learn/running-models-yourself/the-hours-nobody-invoices","position":71,"of":82,"minutes":8,"answer":"A person's time is usually the largest first-year cost of self-hosting and the only line nobody writes down, so price the twenty to forty hours of setup and the monthly maintenance honestly.","keyIdea":"A person's time is usually the largest first-year cost of self-hosting and the only line nobody writes down, so price the twenty to forty hours of setup and the monthly maintenance honestly; and treat a stack only one person can restart as the risk that most often sends an organisation back to an API."},"body":{"format":"markdown","text":"## The largest line in the first year\n\nEvery cost comparison in this module so far has been about machines. In most real deployments the largest number in the first year is a person's time, and it is the one line that never appears in the spreadsheet.\n\nThis is not a rhetorical point. Work through what actually happened between deciding to self-host and having something colleagues rely on. A realistic first deployment, done carefully by someone competent but new to it, runs somewhere between twenty and forty hours: choosing and auditioning models, getting the build right for the hardware, discovering a chat template problem, configuring context and memory fractions, putting a gateway in front, writing a unit file, and the load test that tells you what you have. None of that is wasted and all of it is hours.\n\nSteady state is smaller and never zero. A few hours a month for updates and small failures, plus a spike whenever an engine upgrade changes a default or a better model appears and the audition starts again.\n\nPrice those hours at whatever you would otherwise be paid, or at what you would pay a contractor. Thirty hours at any professional rate exceeds the cost of a mid-range card, and it usually exceeds a year of the API bill it replaced.\n\n## Where the hours actually go\n\nThe distribution is lopsided and worth anticipating, because the surprising items are the ones that break a schedule.\n\n- **Templates and tokenisers.** The single most common time sink, and the least visible, because the failure is quiet degradation rather than an error.\n- **Version matrices.** Driver, runtime, engine and Python packages disagreeing. Hours, with nothing to show for them.\n- **An upgrade that changed a default.** A context length, a memory fraction, a sampling parameter. You discover it from a user report.\n- **A three-in-the-morning restart.** Not because you must fix it then, but because somebody will ask whether it is fixed.\n- **Keeping up.** Reading about new models, testing them, deciding not to switch. This is genuine work and it has no output that anyone sees.\n\n## When the hours are free\n\nFor a large part of this course's readership, they are; and it should be said plainly rather than treated as an embarrassment.\n\nIf you are learning, the hours are the point. The skill transfers, it is in demand, and the alternative use of the evening was not billable. If you are a student without a card to put in a corporate expense claim, a free notebook tier and your own time is the entire viable path. If you are in a place where paying an overseas API involves a card you do not have or currency controls you cannot navigate, your time is not competing with a purchase you could actually make.\n\nWhat changes is the decision rule, not the arithmetic. When the hours are free, local wins at far lower volumes. When the hours belong to an employer paying for them, count them, because the person who wrote the business case will be asked why the project took a month.\n\n## The organisational version: one person knows\n\nThe hidden cost that surfaces later is concentration. A self-hosted stack built by one enthusiastic person is a stack that stops when that person is on leave, and a liability when they resign. This is the most common reason organisations quietly move back to an API after a successful pilot: not cost and not quality, but that only one person can fix it.\n\nThe mitigations are cheap if done early and expensive if done after. Write a runbook that someone else can follow: how to restart it, how to roll back, what the health check is, where the logs are, who to call. Pin every version so the machine is reproducible. Choose boring, widely used components over a clever configuration that only its author understands. And have a second person do a restart and a rollback once, from the runbook, while the author watches without helping.\n\n## Reducing the number, concretely\n\nThe things that actually cut maintenance hours are unexciting. Pin the engine tag and the model revision, so nothing changes without you. Keep the previous version running during an upgrade so rollback is a configuration change. Automate the health check so the first person to notice a failure is a machine. Put quotas in the gateway so one caller cannot create an incident. And resist upgrading to each new model as it appears: the audition costs a day, and the improvement is frequently smaller than the cost of finding out.\n\n> A stack that needs no attention for a month is worth more than one that is 10% faster and needs a day."},"check":{"question":"A pilot self-hosted deployment is measurably cheaper per token than the API it replaced and performs well, yet the organisation moves back to the API after six months. Which explanation best fits the pattern described in this lesson?","options":[{"text":"Token volumes fell below the break-even point as usage patterns settled.","correct":false,"tempting":"A real possibility in general, but it contradicts the premise that the deployment remained measurably cheaper per token."},{"text":"The open model fell behind hosted models in capability over the six months.","correct":false,"tempting":"Plausible on a longer horizon, but the premise says the deployment continued to perform well for its task."},{"text":"Hardware depreciation was underestimated, so the true cost per token was higher than reported.","correct":false,"tempting":"Would make the per-token figure wrong, whereas the case states it was measured correctly and remained favourable."},{"text":"Only one person could operate it, so any absence made it an unacceptable risk.","correct":true}]},"prev":{"slug":"depreciation-and-the-resale-floor","title":"The card as an asset, and the sunk-cost trap","url":"https://addaly.com/learn/running-models-yourself/depreciation-and-the-resale-floor"},"next":{"slug":"the-break-even-model","title":"Building the break-even model","url":"https://addaly.com/learn/running-models-yourself/the-break-even-model"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The hours nobody invoices', in Running Models Yourself. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/running-models-yourself/the-hours-nobody-invoices (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The hours nobody invoices","courseTitle":"Running Models Yourself","module":{"index":8,"slug":"what-it-actually-costs","title":"What it actually costs"},"answer":null,"keyIdea":"A person’s time is usually the largest first-year cost of self-hosting and the only line nobody writes down, so price the twenty to forty hours of setup and the monthly maintenance honestly; and treat a stack only one person can restart as the risk that most often sends an organisation back to an API.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-largest-line-in-the-first-year","runs":[{"text":"The largest line in the first year"}]},{"t":"p","runs":[{"text":"Every cost comparison in this module so far has been about machines. In most real deployments the largest number in the first year is a person’s time, and it is the one line that never appears in the spreadsheet."}]},{"t":"p","runs":[{"text":"This is not a rhetorical point. Work through what actually happened between deciding to self-host and having something colleagues rely on. A realistic first deployment, done carefully by someone competent but new to it, runs somewhere between twenty and forty hours: choosing and auditioning models, getting the build right for the hardware, discovering a chat template problem, configuring context and memory fractions, putting a gateway in front, writing a unit file, and the load test that tells you what you have. None of that is wasted and all of it is hours."}]},{"t":"p","runs":[{"text":"Steady state is smaller and never zero. A few hours a month for updates and small failures, plus a spike whenever an engine upgrade changes a default or a better model appears and the audition starts again."}]},{"t":"p","runs":[{"text":"Price those hours at whatever you would otherwise be paid, or at what you would pay a contractor. Thirty hours at any professional rate exceeds the cost of a mid-range card, and it usually exceeds a year of the API bill it replaced."}]},{"t":"h2","id":"where-the-hours-actually-go","runs":[{"text":"Where the hours actually go"}]},{"t":"p","runs":[{"text":"The distribution is lopsided and worth anticipating, because the surprising items are the ones that break a schedule."}]},{"t":"ul","items":[[{"text":"Templates and tokenisers.","b":true},{"text":" The single most common time sink, and the least visible, because the failure is quiet degradation rather than an error."}],[{"text":"Version matrices.","b":true},{"text":" Driver, runtime, engine and Python packages disagreeing. Hours, with nothing to show for them."}],[{"text":"An upgrade that changed a default.","b":true},{"text":" A context length, a memory fraction, a sampling parameter. You discover it from a user report."}],[{"text":"A three-in-the-morning restart.","b":true},{"text":" Not because you must fix it then, but because somebody will ask whether it is fixed."}],[{"text":"Keeping up.","b":true},{"text":" Reading about new models, testing them, deciding not to switch. This is genuine work and it has no output that anyone sees."}]]},{"t":"h2","id":"when-the-hours-are-free","runs":[{"text":"When the hours are free"}]},{"t":"p","runs":[{"text":"For a large part of this course’s readership, they are; and it should be said plainly rather than treated as an embarrassment."}]},{"t":"p","runs":[{"text":"If you are learning, the hours are the point. The skill transfers, it is in demand, and the alternative use of the evening was not billable. If you are a student without a card to put in a corporate expense claim, a free notebook tier and your own time is the entire viable path. If you are in a place where paying an overseas API involves a card you do not have or currency controls you cannot navigate, your time is not competing with a purchase you could actually make."}]},{"t":"p","runs":[{"text":"What changes is the decision rule, not the arithmetic. When the hours are free, local wins at far lower volumes. When the hours belong to an employer paying for them, count them, because the person who wrote the business case will be asked why the project took a month."}]},{"t":"h2","id":"the-organisational-version-one-person-knows","runs":[{"text":"The organisational version: one person knows"}]},{"t":"p","runs":[{"text":"The hidden cost that surfaces later is concentration. A self-hosted stack built by one enthusiastic person is a stack that stops when that person is on leave, and a liability when they resign. This is the most common reason organisations quietly move back to an API after a successful pilot: not cost and not quality, but that only one person can fix it."}]},{"t":"p","runs":[{"text":"The mitigations are cheap if done early and expensive if done after. Write a runbook that someone else can follow: how to restart it, how to roll back, what the health check is, where the logs are, who to call. Pin every version so the machine is reproducible. Choose boring, widely used components over a clever configuration that only its author understands. And have a second person do a restart and a rollback once, from the runbook, while the author watches without helping."}]},{"t":"h2","id":"reducing-the-number-concretely","runs":[{"text":"Reducing the number, concretely"}]},{"t":"p","runs":[{"text":"The things that actually cut maintenance hours are unexciting. Pin the engine tag and the model revision, so nothing changes without you. Keep the previous version running during an upgrade so rollback is a configuration change. Automate the health check so the first person to notice a failure is a machine. Put quotas in the gateway so one caller cannot create an incident. And resist upgrading to each new model as it appears: the audition costs a day, and the improvement is frequently smaller than the cost of finding out."}]},{"t":"quote","runs":[{"text":"A stack that needs no attention for a month is worth more than one that is 10% faster and needs a day."}]}],"check":{"question":[{"text":"A pilot self-hosted deployment is measurably cheaper per token than the API it replaced and performs well, yet the organisation moves back to the API after six months. Which explanation best fits the pattern described in this lesson?"}],"options":[{"text":[{"text":"Token volumes fell below the break-even point as usage patterns settled."}],"correct":false,"tempting":[{"text":"A real possibility in general, but it contradicts the premise that the deployment remained measurably cheaper per token."}]},{"text":[{"text":"The open model fell behind hosted models in capability over the six months."}],"correct":false,"tempting":[{"text":"Plausible on a longer horizon, but the premise says the deployment continued to perform well for its task."}]},{"text":[{"text":"Hardware depreciation was underestimated, so the true cost per token was higher than reported."}],"correct":false,"tempting":[{"text":"Would make the per-token figure wrong, whereas the case states it was measured correctly and remained favourable."}]},{"text":[{"text":"Only one person could operate it, so any absence made it an unacceptable risk."}],"correct":true,"tempting":null}],"order":[0,2,3,1],"why":null},"prev":{"slug":"depreciation-and-the-resale-floor","title":"The card as an asset, and the sunk-cost trap","minutes":8},"next":{"slug":"the-break-even-model","title":"Building the break-even model","minutes":10}}}