L³ — The Large Language Learning Center

AI is the performer. You are the director.

You do not need a magic phrase. You need to describe the result, hand over the useful context, set the boundaries that prevent a real mistake, and explain what finished work looks like. A strong brief has four parts:

1. Goal. Say what you want created, changed, investigated, or decided.
2. Context. Add the file, screenshot, example, audience, history, or live source that changes the answer.
3. Boundaries. State what must remain unchanged, what must not be sent or published, and where the model must ask first.
4. Done when. Describe the test: the page works on a phone, every link opens, the email is ready to paste, or the calculation ties out.

Goal: [What I need you to create, change, research, or decide.]

Context: [Who I am, who the audience is, what files or examples matter, and what has already been decided.]

Boundaries: [What must stay unchanged, what must not be guessed, and what needs my approval before it affects another person.]

Done when: [The exact result and the checks that prove it is complete.]

Show me the finished work directly. Explain only what I need in order to review or use it.

The five habits that improve almost every answer

• Give the actual material. Paste the text, attach the file, or feed the screenshot. Do not make the model imagine what it could inspect.
• Ask for the deliverable, not a lecture. Say “write the email” or “build the page,” then request explanation if you need it.
• Use the second round. The first answer is a first draft. Point to what is wrong, missing, too long, or unlike you. Do not restart unless the topic truly changed.
• Name the audience. A seller, first-time buyer, brokerage owner, regulator, and software developer need different language.
• Request proof. Ask what was checked, what remains uncertain, and which claims came from live official sources.

Conversation, research, and agent work are different

Before you finish, review your work as a skeptical expert. Check every requirement I gave you, identify any factual claim that needs a current source, test anything testable, and correct the problems you find. Then show me the final version and a short list of anything that still requires human judgment.

The short answer

Use Sonnet for most daily work, Opus when judgment and polish matter more than speed, Fable for the hardest long-running agent jobs, and Haiku for simple, fast, repeatable work. In Claude Code, aliases such as sonnet and opus move to Anthropic's recommended current version. Use a full model name only when you need a fixed, reproducible version.

Model IDs: claude-fable-5, claude-opus-5, claude-sonnet-5, and claude-haiku-4-5-20251001. Current pricing and availability can change. The official Claude model page is the authority at the moment of use.

Claude Code aliases

Change the model without confusion

Use /model inside a session. Use claude --model ... when starting one. A resumed Claude Code session normally remembers the model it was using. The alias can move when Anthropic updates its recommendation; a full model ID stays pinned.

Reasoning effort

Effort controls how much reasoning the selected model applies. Lower effort is faster and less expensive. Higher effort gives difficult work more time. Availability depends on the model. Start with the default. Increase effort when the task has several interacting constraints, unclear causes, high stakes, or a difficult verification problem. The highest setting is not automatically the best setting for every job.

What Codex is

Codex is OpenAI's software-building agent. It can understand a project, change files, run commands, use a browser, inspect images and documents, connect to outside systems, test its own work, review changes, and carry a long task to a finished result. The same core workflow appears in several places:

Install the ChatGPT desktop app on Windows

Use the Microsoft Store or run this official Windows package command:

Open the app, sign in, add the project folder, and select Ask for approval while learning. Install the common building tools when the project needs them:

Git powers change review and safe history. Node.js runs many websites and development tools. Python handles data, automation, documents, and scripts. GitHub CLI connects repository workflows after gh auth login.

The Codex working loop

1. Add the project. Choose the exact folder that owns the work.
2. Show the result. Attach a screenshot, file, example, or error whenever it can replace a long explanation.
3. State goal, context, boundaries, and done when. Codex can handle a rough prompt, but these four items make large work reliable.
4. Use Plan mode for hard work. Let Codex inspect and form a plan before the implementation begins.
5. Let it work through the loop. Inspect, change, run, observe, correct, and repeat.
6. Review the diff. Click the exact changed line or block when you want a correction.
7. Demand validation. A build is not finished merely because files changed. The actual experience must work.
8. Keep one task per coherent outcome. Fork when the work truly branches; continue when the same result is still being refined.

What belongs where

Model and reasoning control

Start with the default Power setting. Move toward Smarter when the task needs more judgment or planning. Move toward Faster when the task is narrow and repeatable. Use Max for a single exceptionally hard quality-first task. Use Ultra when a difficult job genuinely divides into independent workstreams that subagents can run in parallel.

Open this project and inspect the current implementation before editing it.

Build: [Describe the finished experience.]
Preserve: [Brand, working behavior, approved copy, compliance language, and protected files.]
Use: [Screenshots, examples, source files, or official documentation.]
Verify: [Build command, browser path, screen sizes, links, forms, calculations, or other proof.]

Take ownership of the complete implementation and safe verification. Keep me updated in plain English. Do not publish, send, delete, or expand access unless I explicitly authorize that action.

The reliability ladder

• Prompt: Say the outcome.
• Context: Give Codex the correct project and evidence.
• Rules: Put durable project truth in AGENTS.md.
• Tools: Connect only the outside systems the workflow needs.
• Skill: Package a method after it works more than once.
• Automation: Schedule it only after the exceptions are understood.
• Review: Inspect the result, not merely the activity.

What Claude Code is

Claude chat talks about work. Claude Code can enter a project folder, read the files, edit them, run commands, start a preview, inspect errors, and continue until the requested result is working. You still direct the job and approve sensitive actions. The most important choice is not a clever command. It is opening the correct folder and defining what finished means.

The easiest path: Claude Desktop

1. Download Claude Desktop from claude.com/download, install it, open it, and sign in.
2. On Windows, install Git for Windows and restart Claude. Git is required for local sessions in the Code tab.
3. Open the Code tab. Choose the smallest folder that contains the project you want Claude to work on.
4. Start with a read-only orientation: “Explain what is in this folder, how the project runs, and which files control the page I showed you.”

The Desktop Code tab can run parallel sessions, isolate work with Git worktrees, show file changes, preview a site, open a terminal, connect outside tools, and let you comment directly on a change before Claude revises it.

The terminal path: install Claude Code

Windows PowerShell

Open PowerShell in the project folder and run:

To update a WinGet installation later:

macOS, Linux, or WSL

Native installs update automatically. Package-manager installs may require their own upgrade command. Run claude doctor when installation, login, or configuration feels wrong.

Your first serious Claude Code job

1. Open the right folder. Claude can only understand the project it can see. Avoid handing it your entire computer.
2. Orient before editing. Ask it to explain the structure, the running instructions, and the files that matter.
3. Plan difficult work. Use Plan mode for a large, ambiguous, risky, or multi-page change.
4. State the build law. Brand rules, protected files, audience, compliance language, and required tests belong in the prompt or CLAUDE.md.
5. Let it implement. Approve normal project edits. Read requests that reach outside the project before approving them.
6. Require proof. Ask it to run the project, inspect the page, test the important path, and correct what it sees.
7. Review the change. Use the visual diff. Point to the exact sentence, block, or behavior that needs revision.
8. Finish deliberately. Ask what changed, what was tested, what remains uncertain, and what would be required to publish.

Inspect this project before changing anything. Tell me which files control the result I described and how you will verify the finished work.

Goal: [Describe the working result.]
Audience: [Describe who will use it.]
Protected decisions: [Brand, copy, data, compliance language, or files that must remain unchanged.]
Use these references: [List or attach examples.]
Done when: [Name the checks.]

After you understand the project, implement the complete change, run the relevant checks, inspect the actual result, correct any problems, and show me the finished work directly.

The commands worth remembering

Permissions: the rule that prevents expensive mistakes

Normal project reading, editing, and testing are the work. Requests to reach outside the project, install system software, expose a secret, delete files, publish, send a message, or bypass protections deserve a deliberate review. Never make “skip every permission” your beginner default. A fast agent with the wrong folder and unlimited access can make a mistake much faster than a person.

When Claude gets lost

• Stop adding five new requests to the same turn. Restate the single outcome that matters now.
• Point to the exact file, screenshot, error, or part of the page.
• Ask Claude to explain what it believes is true before it edits again.
• Use claude doctor for setup trouble and a new session for a truly new problem.
• Keep durable project rules in CLAUDE.md; keep temporary instructions in the conversation.

First separate the product from the model

ChatGPT is the application. Codex is the software-building agent. A name such as GPT-5.6 Sol is the model doing the thinking. The product can add memory, search, files, voice, image tools, connectors, projects, and permissions around that model. Your plan and workspace determine which choices appear.

ChatGPT thinking choices in plain English

Reasoning changes how long the model works, not whether it has permission to take an action. Search, connectors, files, memory, and computer control are separate capabilities. A slower answer is also not automatically a correct answer. Verify important facts no matter which setting you choose.

Codex model control

In the Codex app, choose from the model control or use the Power/Smarter/Faster slider. In the Codex terminal, use /model or start with codex --model gpt-5.6. The current Codex family is:

• Sol: complicated, open-ended, or highly polished work.
• Terra: the everyday coding and knowledge-work balance.
• Luna: narrow, well-defined, repeatable work at speed.

Three different things carry the Grok name

Current Grok model map

Using Grok well

1. Open grok.com and decide whether this is a conversation, research job, media-generation job, or a build.
2. For current events, ask Grok to show the sources it actually used. Open the primary source before acting.
3. For a build, open the smallest correct project folder in Grok Build and give it the same goal, context, boundaries, and done-when brief used with Codex or Claude Code.
4. Use /model inside Grok Build when you need to inspect or change the engine. Use grok inspect when diagnosing a Build setup.
5. For macOS, Linux, or WSL, follow the official installer at docs.x.ai/build/overview. On Windows, use the current PowerShell option displayed by that official installer; commands can change.

Research this question using current information: [question].

Separate:
1. facts confirmed by primary sources,
2. credible reporting,
3. interpretation or inference,
4. anything still unknown.

Show the source and publication date beside every time-sensitive claim. Do not treat a social post, search snippet, or repeated claim as confirmation. Finish with the three facts I should verify myself before I act.

There is no single “best AI”

Models compete across reasoning, speed, cost, privacy, context size, media, search, coding, local deployment, language coverage, and integration. The right question is: which tested model, inside which product, with which tools and protections, fits this job?

Choose by job, not by fan club

The seven words that remove the mystery

Windows starter workstation

1. Install ChatGPT desktop and/or Claude Desktop. Learn one building surface before adding five.
2. Install Git so changes have history and can be reviewed.
3. Install Node.js LTS for modern websites, and Python only when the work needs it.
4. Create a normal project folder with a plain name. Do not use the entire Desktop, Documents folder, or drive as the project.
5. Open that folder in the AI builder. Ask it to explain the files before authorizing changes.
6. Keep approval prompts on while learning. Read anything involving publishing, deletion, installation, passwords, or access outside the project.

These are separate commands. You do not need every tool for every project. An agent should inspect the project and tell you which runtime it actually uses.

Mac starter workstation

Install the official ChatGPT and Claude desktop applications. Apple's developer command-line tools supply Git when a project needs it. Add Node.js or Python only from trusted sources. The operating rule is identical: one defined project folder, visible change review, explicit permission, and proof before publishing.

The builder's sequence

1. Brief. Describe the person, the problem, the finished experience, the boundaries, and the proof.
2. Inspect. Let the agent find the project structure, brand system, data, and running instructions.
3. Plan. For large work, agree on the parts and the order. A plan is a map, not the finished building.
4. Build. Let the agent make the complete coherent change inside the authorized project.
5. Run. Start the actual product, not just a syntax checker.
6. Observe. Inspect it at realistic sizes with realistic content. Read the words. Use the controls.
7. Correct. Give specific feedback tied to the visible result, then repeat the checks.
8. Release. Publish, send, or automate only after the owner approves the tested result.

Build a polished, responsive website in this project for [audience].

The visitor should immediately understand [main promise] and be able to [main action].
Pages or sections: [list them].
Brand: [colors, logo, voice, examples].
Content: [what is approved; what you may draft].
Boundaries: preserve [files, behavior, compliance copy, accessibility, privacy].

Before editing, inspect the project and explain how it runs. Then implement the complete experience, start the local preview, inspect desktop and mobile, test every important control, correct visible problems, and summarize the proof. Do not publish until I approve the preview.

How to give useful visual feedback

• Say what you see: “The directory is buried below the fold.”
• Say what should happen: “A first-time visitor should see the major learning tracks without guessing.”
• Name the protected quality: “Keep the Royal gold, generous white space, and calm premium feel.”
• Attach a screenshot and point to the exact area. A visible example beats a vague adjective.

When to create a skill or automation

Do the workflow manually with an agent until the decisions, exceptions, data, and review steps are understood. Turn it into a reusable skill when the method works repeatedly. Schedule it only when a predictable trigger, owner, approval point, and failure path are defined.

High-value jobs for a realtor

Using only the verified property facts below, draft a clear and specific listing description for [audience and channel].

Facts: [paste approved facts]
Voice: [brand voice]
Length: [limit]

Do not invent features, measurements, views, school claims, commute times, neighborhood character, future value, or legal conclusions. Avoid language that indicates a preference for or discourages any protected class. Put any missing fact in a separate “Questions before publishing” list instead of guessing.

Turn these notes into a warm, concise follow-up email to [client].

Include:
- what we decided,
- what I owe them,
- what they owe me,
- dates that were explicitly confirmed,
- the next conversation.

Do not add promises, deadlines, rates, legal interpretations, or property facts that are not in the notes. Mark any ambiguity for me below the draft. Write like a trusted professional, not a marketing robot.

Analyze the attached market reports for [place and date range]. Use only the supplied data and cite the exact table, page, or source beside every number.

Separate observed facts from interpretation. Explain sample limitations and avoid claiming that one trend caused another unless the source proves it. Produce:
1. a five-bullet professional brief,
2. a client-friendly explanation,
3. three questions the data cannot answer,
4. a fact-check list before publication.

The “never guess” list

Rates, APR, payment, qualification, legal rights, contract meaning, tax treatment, school quality, crime, protected-class demographics, zoning, permit status, property condition, measurements, environmental issues, availability, and future value require an authoritative source and the right licensed professional. AI can organize the question; it cannot become the professional.

The stoplight rule

Five professional gates

1. Authority. Does this person and this AI tool have permission to see the information and take the requested action?
2. Source. Can every important name, number, date, quote, and claim be traced to authoritative evidence?
3. Fair Housing. Does the language avoid preferences, exclusions, coded descriptions, steering, and unsupported claims about people or neighborhoods?
4. Licensed judgment. Has mortgage, legal, tax, appraisal, inspection, insurance, or other professional guidance stayed with the proper licensed person?
5. Human approval. Has the owner reviewed the exact message, file, audience, access, and timing before anything is sent or published?

Information handling

• Use approved business accounts and review the provider's current data controls, retention, training, connector, and admin settings.
• Remove unnecessary names and identifying details. Share the minimum information required for the task.
• Do not paste MLS photographs, descriptions, forms, reports, or other copyrighted material into public output unless the rights allow it.
• Never confuse a fluent summary with a legal interpretation. Read the governing document and use the right professional.
• Require confirmation before an agent sends email, publishes a page, changes access, buys anything, deletes material, or contacts a client.

This field changes faster than a printed manual

This model atlas was verified on August 2, 2026. A model can be released, renamed, restricted, repriced, or retired after that date. Treat the operating methods as durable and the model roster as dated. Before choosing a model for production, verify it on the provider's official model page.

The L³ monthly update ritual

1. Read official release notes from the major providers.
2. Record new models, retirements, pricing, context limits, tool changes, and availability by plan or region.
3. Test important workflows on a fixed Royal evaluation set instead of trusting launch claims.
4. Update recommendations only when the real work improves.
5. Date the change and preserve the previous result so a regression can be explained.

Official source desk

Evaluation card

For every serious workflow, score the model on factual accuracy, instruction following, source quality, completion rate, output consistency, speed, cost, privacy and access control, recovery after an error, and the time a human needs to review it. The winner is the system that produces the safest useful result—not the most impressive demo.