Cost, Safety and Doing This Well ⚖️

Part 1: controlling the cost

You pay per token, both the tokens you send and the tokens you get back. It is cheap per request and it adds up fast, especially with the growing conversation histories from Lesson 55. The first rule is simply to know what you are spending.

Count tokens before you send

import anthropic

client = anthropic.Anthropic()

# The API's own counter is the only accurate one. Do NOT use tiktoken (Lesson 53).
result = client.messages.count_tokens(
    model="claude-sonnet-5",
    system="You are a helpful assistant.",
    messages=[{"role": "user", "content": "Summarise the history of Python."}],
)

print(f"This request will send {result.input_tokens} input tokens")

# estimate the cost yourself (prices per million tokens)
PRICE_IN = 3.00 / 1_000_000       # sonnet-5 input, per token
estimated = result.input_tokens * PRICE_IN
print(f"Input cost: about ${estimated:.6f}")

Read the usage after every call

# Every response reports exactly what it used. Log it and the mystery vanishes.

def report_cost(response):
    """Turn a response's usage into a rough cost, using per-million prices."""
    usage = response.usage
    price_in = 3.00 / 1_000_000        # sonnet-5, adjust for your model
    price_out = 15.00 / 1_000_000
    cost = usage.input_tokens * price_in + usage.output_tokens * price_out
    return (f"{usage.input_tokens} in + {usage.output_tokens} out "
            f"= about ${cost:.6f}")


# after a call: print(report_cost(response))
# a running total across a session tells you exactly what Jarvis costs to run.
print("usage.input_tokens and usage.output_tokens are on every response. Log them.")

The levers that actually reduce cost

Part 2: safety, honesty, and harm

The model is confidently wrong, sometimes

Lesson 53 explained why: it predicts plausible text, and a fluent wrong answer is often more plausible than an honest "I don't know". This is not a bug you can fully remove. It is a property of the tool, and your job as a builder is to design around it.

Prompt injection: your assistant can be turned against you

• Least privilege. Give tools the minimum power and the minimum credentials. A read-only tool cannot be turned into a weapon.
• Confirm irreversible actions. Never let the model send, delete, or pay without a human saying yes to that specific action.
• Sandbox anything that executes. No raw shell, no eval, no unsandboxed code execution (Lesson 52).
• Distrust retrieved content. Text you fetched is data, not instructions, and you cannot fully make the model agree.

Privacy: whose data, going where?

Every prompt you send to a cloud model leaves your machine. For a personal tool with your own data, that may be fine. For other people's data, it is a responsibility with legal weight (GDPR, CCPA, HIPAA and others, depending on the data and where you are).

• Know what leaves. If you would not email it to a stranger, think hard before sending it to a third-party API.
• Tell people. If your assistant sends user data to a provider, the user has a right to know, and often a legal right to consent.
• Go local when it matters. Sensitive data plus a local model (Lesson 60) means nothing leaves the room. Sometimes that is not just nicer, it is required.
• Do not log secrets. The habit from Lesson 28's logging note: never write API keys, passwords, or personal data into your logs.

Bias, and the limits of the training data

A model reflects its training data, and that data reflects the world, including its unfairness. Models can produce biased, stereotyped, or skewed output, and they know the world unevenly: far more about some cultures, languages, and topics than others. If you build something that affects people, test it across the range of people it will affect, and do not assume "the AI said so" is neutral. It is not.

Part 3: on building this well

A short creed for anyone who builds assistants:

• Be honest about limits. Tell users what your assistant cannot do and when it might be wrong. A tool that admits uncertainty is more trustworthy, not less.
• Design for the user's benefit, not for engagement metrics that reward keeping them hooked or telling them what they want to hear.
• Keep a human in the loop for anything that matters. The model proposes; a person decides.
• Make it auditable. Log what your assistant did, so that when it surprises you, you can find out why.
• You are responsible for what you ship. "The model did it" is not a defence. You chose to build it, and to give it the tools it used.

A note to the person who started at "what is a variable"

Look at what you can do. You began this course, perhaps, never having written a line of code. You learned what a computer is and what programming is. You learned to print, to remember, to decide, to loop. You learned to hold data in lists and dictionaries, to name processes with functions, to handle failure, to read and write files, to test your work, to structure real software. You learned the idioms that make Python look like Python, and you went out into the wild and automated, and served, and stored, and analysed, and drew.

And then you built an AI assistant, from scratch, and understood every piece of it, because every piece was something you had already learned. That was the whole point. Not to teach you a library, but to teach you to program, so thoroughly that the most hyped technology of the moment turned out to be an ordinary program you could read, build, and reason about.

You are a programmer now. Genuinely. Go and build things that are useful, and kind, and honest, and yours.

from datetime import date
import json
from pathlib import Path

SPEND_FILE = Path("jarvis_spend.json")
DAILY_LIMIT = 1.00      # dollars; set it low while you experiment

PRICE_IN = 3.00 / 1_000_000
PRICE_OUT = 15.00 / 1_000_000


def load_spend():
    if SPEND_FILE.exists():
        data = json.loads(SPEND_FILE.read_text(encoding="utf-8"))
        if data.get("date") == str(date.today()):
            return data["spent"]
    return 0.0


def record_spend(usage):
    """Add this call's cost to today's total. Returns the new total."""
    cost = usage.input_tokens * PRICE_IN + usage.output_tokens * PRICE_OUT
    total = load_spend() + cost
    SPEND_FILE.write_text(
        json.dumps({"date": str(date.today()), "spent": total}), encoding="utf-8")
    return total


def within_budget():
    """Refuse the call if today's spend is already at the cap."""
    return load_spend() < DAILY_LIMIT


# In the chat loop, before each call:
#   if not within_budget():
#       print("Jarvis: I've hit today's spending limit. Back tomorrow.")
#       continue
# And after each call:  record_spend(response.usage)
print("A hard daily cap turns a runaway risk into a bounded one.")