FROM MODEL TO APPLICATION

EXAMPLES Example 1: A complete request and response. A developer writes a program that sends an HTTPS request to a model provider's endpoint. The request includes the API key in a header, the model name, a system message that says "You are a helpful assistant," and a user message that says "Summarize this report." The provider runs inference, which means the model produces the summary token by token. The provider then replies with a JSON response containing the assistant message, along with information such as how many tokens were used. The program pulls the summary out of the JSON and shows it to the user. If the key was missing or wrong, the provider would instead return an error message about authentication, and the program would need to handle that. Example 2: The chat message list. Starting here, and throughout the rest of this book, every block of programming or technical code is annotated using a notation called English Readable Code (ERC). English Readable Code is an invention of D. R. Dison, created to close the gap between plain written English and the exact, literal instructions a computer requires. Each line of code in a listing is preceded by a comment, written in ordinary English sentences, that states in plain language what that line does, and each function or block of code is preceded by a further comment summarizing the purpose of the whole function or block. ERC was developed because code by itself assumes the reader already knows the syntax and conventions of a programming language, and because many readers of a book like this one are still building that knowledge; a line such as "for i in range(count):" is opaque until you are told, in English, that it means "repeat the next steps once for every number from zero up to count." For a learner, ERC turns each listing into a second, parallel explanation running directly alongside the code, so the code can be read as a narrated walkthrough rather than decoded symbol by symbol. For an experienced coder, ERC is just as useful, since it documents the intent behind each line and block in a form that stays readable even to someone unfamiliar with the specific language, making it easier to review, modify, or hand off code with confidence that its purpose is clear. In every listing, the ERC comment is written using the comment delimiter of the programming language shown, so a Python listing uses the "#" character, while other languages shown in this book use their own native comment markers, keeping each annotated listing valid, runnable code in its own right. A chat-style message list might look like the following lines. [START OF JSON CODE] // A system-role message that sets the assistant's standing instruction {"role": "system", "content": "You are a helpful assistant"} // A user-role message containing the actual request to summarize a report {"role": "user", "content": "Summarize this report"} [END OF JSON CODE] Read the first line as: the speaker is the system, and the content is the standing instruction. Read the second line as: the speaker is the user, and the content is the request. This structure is how most modern model APIs format a conversation, with small differences between providers. When a third turn happens, the harness adds the assistant's earlier reply and the user's new message to the list and sends all four items together. Example 3: Choosing open-weight or hosted. Company A downloads an open-weight model and runs it on its own servers. It controls its own data, which matters because it handles private medical notes, and it has predictable costs at high volume. But it must buy and manage GPUs and hire people who can keep the system running. Company B calls a closed, hosted model through an API. It avoids hardware work and starts in a day, but it depends on the provider's uptime and pricing, and it must make sure its data-sharing agreement with the provider is acceptable. Each company chose well for its own constraints, which shows there is no single winner. Example 4: How long does inference take? A small model answering a short question might respond in under a second. A large model asked to read a long document and reason carefully might take tens of seconds. This is a rough range, and real timing varies with provider load and settings. For a human chatting, a delay of ten seconds feels long, so you might use streaming or a smaller model. For a background agent that reviews a hundred resumes overnight, ten seconds each is perfectly acceptable. The same delay is a problem in one setting and fine in another, so the harness engineer designs for the situation.