Real-world examples
- Draft a follow-up email to a department committee
- Summarize meeting notes before a faculty discussion
- Answer a student's basic question about syllabus formatting
How to use ChatGPT modes effectively, understand Work and Codex credit usage, and choose the right model, speed, and thinking level for Codex. Work and Codex can consume credits quickly depending on the model, settings, and workload, so review the guidance below before starting credit-intensive work.
Practical guidance for choosing the right mode for common campus work.
Work and Codex share your monthly credit allocation and use token-based credit pricing. Usage can increase with higher-capability models, larger tasks, reasoning effort, speed settings, and other agent activity. Check your remaining monthly allowance before starting larger Work or Codex tasks.
Choose your starting settings intentionally. An unsuitable default can increase credit usage more than a single complex task.
Choose a current supported model that matches the task. Use a lower-cost model for routine coding and a higher-capability model when the work requires stronger reasoning or more complex agentic workflows.
| Situation | Recommended model | Why |
|---|---|---|
| Normal coding | Lower-cost coding model | Strong performance without selecting a higher-capability model unnecessarily |
| Small edits | Lower-cost coding model | Good enough for quick changes |
| Debugging across files | Higher-capability model | Needs stronger reasoning |
| Architecture, migrations, hard bugs | Higher-capability model | Appropriate when the task requires stronger capabilities |
| Repeated failures | Upgrade model | One strong attempt can be cheaper than many weak ones |
Fast mode prioritizes faster response and consumes credits at a higher rate than Standard.
| Speed | Use when | Avoid when |
|---|---|---|
| Standard | Default for almost all coding | Don't avoid it just because Fast exists |
| Fast | Live pairing, demos, urgent fixes, short tasks where waiting is the problem | Normal development, long repo analysis, large refactors, exploratory debugging |
| Level | Use for | Token risk |
|---|---|---|
| Low | Rename, formatting, tiny local changes | May miss context |
| Medium | Default coding, tests, normal bug fixes, small features | Best balance |
| High | Hard bugs, multi-file reasoning, security-sensitive changes | Use when deeper reasoning benefits the task |
| XHigh | Big migrations, architecture, autonomous repo work | Use when the task requires the deepest reasoning |
Use the open files only. Make the smallest
safe change. Do not refactor unrelated code.
Explain what changed and list any tests
I should run.
Analyze the relevant files first. Propose
a short plan before editing.
Make the smallest safe change.
Preserve existing behavior unless required.
| Task | Model | Speed | Thinking |
|---|---|---|---|
| Everyday coding | Stable coding model | Standard | Medium / Low |
| Harder coding | Stable or latest model | Standard | High |
| Urgent coding | Any | Fast (briefly, then switch back) | As needed |
Division of Information Technology
University of Maryland