# How Do You Build Software Safely with AI?
Canonical source: [https://isaiuseful.com/thinking-with-ai](https://isaiuseful.com/thinking-with-ai)
Beginner-safe AI development · checked 31 July 2026
Codex, Claude Code, OpenCode and spec tools differ at the edges. The durable method is the same: make the problem clear, keep changes small, verify the result and let security checks stop unsafe code before production.
This guide starts with your first branch and ends with an evidence-based decision about subscriptions, emergency APIs, open-weight models, DGX hardware and private cloud.
- [Start with one safe task](#start)
- [Put security in CI now](#security)
Human-owned loop
Repeat for every change
1. **01** **Understand** Read before editing
2. **02** **Specify** Define the behavior
3. **03** **Plan** Choose the smallest path
4. **04** **Build** One reviewable task
5. **05** **Verify** Tests, scans and review
6. **06** **Learn** Keep the useful rule
The model may type the code. **You still own the requirement, permission boundary and release decision.**
- [**6** reviewable build stages EXPLORE → REVIEW](#loop)
- [**5** levels of agent authority COMPLETE → AUTOMATE](#surfaces)
- [**4** inputs to every task GOAL · CONTEXT · CONSTRAINTS · DONE](#start)
Before the first prompt
## Prepare a reversible place to learn.
You do not need to be a senior developer. You do need a repository, a small task and a way back when an experiment fails.
Foundation 01
### Learn the Git safety net.
A branch isolates work. A commit records a checkpoint. A diff shows exactly what changed. A pull request gives another person and your automated checks a review surface.
- [Practice visually with Learn Git Branching →](https://learngitbranching.js.org/)
- [Read the free Pro Git book →](https://git-scm.com/book/en/v2)
Foundation 02
### Know where commands run.
The terminal runs with your user permissions. Before approving a command, read its target path and effect. If you cannot explain it, ask the agent to explain it without running it.
**Beginner notice**
Never paste a command containing a password, API key or private token into chat, code or a commit.
Foundation 03
### Write down how the repo works.
Keep build, test and lint commands; important directories; conventions; forbidden paths; and “done” checks in a short repository instruction file. Prefer rules a person or CI job can verify.
- [See the file each tool reads →](#tools)
New to a codebase?
**Ask for a map before asking for a change.**
Start read-only: “Explain the folder structure, how to run the tests, where authentication lives and which files you would inspect for this task. Do not edit anything.” Check the answer against the repository.
A reusable first prompt
### Give four things—not a novel.
Good context reduces guesswork. Durable project facts belong in repository instructions; the specific goal belongs in this task.
**Goal · context · constraints · done when**
`Goal: add an empty-state message to the saved-items page. Context: inspect the page, its existing tests and the shared message component. Constraints: do not add dependencies or change the API. Plan first and ask if the expected wording is missing. Done when: the empty and non-empty cases both pass, the diff is reviewed and no security check regresses.`
Choose the smallest surface
## Give AI only as much room as the task needs.
A line completion and an autonomous terminal agent are not the same risk. Start narrow, widen authority only when the work genuinely needs it, and keep the same definition of done.
**01**
Complete
### Finish a local thought
Use an inline suggestion for a line, expression or repetitive pattern you already understand. Read it before accepting it.
Authority: suggestion only
**02**
Ask
### Build understanding
Ask for an explanation, repository map or likely files. Require references and keep the pass read-only.
Authority: read and explain
**03**
Edit
### Transform a selection
Use a targeted edit when the boundary is visible: add validation, rename a symbol or write a focused test.
Authority: named files or selection
**04**
Agent
### Execute a bounded task
Use plan/agent mode for multi-file work that can be split into tasks, tested and reviewed as a diff.
Authority: workspace + approved tools
**05**
Automate
### Repeat a proven workflow
Use a CLI, SDK or CI agent only after the interactive version is reliable, permissioned and observable.
Authority: policy-defined and logged
Pocket control is still system access
**A phone changes the surface—not the authority.**
Label a mobile session as **chat** , **assistant** or **operator** . Show whether the model and tools run on the phone, a home computer or a cloud service; preserve the same file limits, command review and approval gates you would require at the keyboard. [See the private remote pattern →](https://isaiuseful.com/remote-spark.html.md#operators)
Beginner shortcut
**Confused? Ask. Certain? Edit. Multi-file? Plan.**
If you cannot predict which files or commands are needed, begin with a read-only question. Do not jump to an autonomous agent because the prompt is hard to write—the uncertainty is a reason to explore first.
Spec-driven development
## Turn intent into a six-stage reviewable loop.
A specification does not need to be long. It needs to say what will change, what will not change and how someone can prove the result.
OpenSpec beyond code
### The value is the rail—not the file type.
OpenSpec packages proposal, requirements, design and tasks as durable Markdown. The same pattern can guide any technical change that benefits from explicit scope, ordered decisions and review gates.
**Infrastructure**
Configuration changes, architecture decisions, migrations and rollback.
**Documentation**
Technical manuals, policy sets, requirements and coordinated revisions.
**Process design**
Operational workflows, business rules, handoffs and exception paths.
**What “on the rails” really means:** the framework cannot guarantee truth or prevent every hallucination. It makes assumptions, constraints, scope changes and unfinished work visible, so a human or automated gate can catch drift before execution.
> Visual: Spec-driven AI development sequence
**Visual reading order:**
1. **01** **Explore** Read code, examples and constraints. Make no edits.
2. **02** **Specify** Problem, users, scope, requirements and acceptance cases.
3. **03** **Plan** Files, interfaces, dependencies, tests, risks and rollback.
4. **04** **Tasks** Small ordered changes, each with an acceptance check.
5. **05** **Implement** One task and its tests; stop before the next task.
6. **06** **Review** Diff, tests, security findings and the original acceptance cases.
spec.md
### The promise
Who needs what behavior? What is in and out? Which examples must work? Which questions are still unresolved?
plan.md
### The route
Which modules change? What data crosses a trust boundary? Which tests, migration and rollback are required?
tasks.md
### The sequence
Can each task be reviewed, tested and committed independently? If not, split it again.
Example acceptance case
**Write behavior a beginner can check.**
**Given** a signed-in user has no saved items, **when** they open Saved Items, **then** the page shows the agreed empty-state message and does not make a delete request. This is more testable than “make the page nice.”
**Stop and return to the spec when**
a requirement is ambiguous
the agent proposes a new dependency
a migration or permission appears unexpectedly
tests disagree with the intended behavior
the same fix fails twice
the diff is too large to explain
Three routes, one method
## Use the tool’s native controls without changing the discipline.
The material difference is usually authentication, instruction files, permission controls and model routing—not the shape of good engineering work.
| Workflow moment | Codex | Claude Code | OpenCode + OpenSpec |
| --- | --- | --- | --- |
| **Start safely** | Use default sandbox and approvals; ask or enter Plan mode before a broad change. | Use plan mode, permission rules and sandboxing; keep consequential commands behind approval. | Use the restricted Plan agent; set unknown actions to ask and deny pushes, destructive commands and out-of-repo access. |
| **Durable repo rules** | `AGENTS.md` , with nearer nested files overriding broader guidance. | `CLAUDE.md` . Import `@AGENTS.md` to share cross-tool rules, then add only Claude-specific notes. | `AGENTS.md` by default; OpenCode can fall back to `CLAUDE.md` . Keep OpenSpec artifacts under `openspec/` . |
| **Think before code** | Ask for a plan or use Plan mode; agree on files, checks and stop conditions before edits. | Use plan mode or a read-only research pass; approve the plan before implementation. | Use OpenCode Plan or `/opsx:explore` , then `/opsx:propose` to create proposal, requirements, design and tasks. |
| **Implement** | Name one task, require relevant tests, then inspect the diff or run a review. | Implement one bounded task, run tests and inspect the diff before accepting more authority. | Run `/opsx:apply` for approved tasks. Verify the artifacts and implementation before `/opsx:archive` . |
| **Switch models** | Choose models available to the plan or API key. API authentication is separate from plan authentication. | Choose the available Claude model; a plan allowance and Console/API billing are distinct capacity paths. | OpenCode connects to multiple providers, OpenRouter and local endpoints; OpenSpec supplies the workflow, not the model. |
| **What stays human** | Requirement approval, secret/data policy, production access, security exceptions, migration approval, final review and release. | Requirement approval, secret/data policy, production access, security exceptions, migration approval, final review and release. | Requirement approval, secret/data policy, production access, security exceptions, migration approval, final review and release. |
**Official routes:** the table reflects current product documentation, but interfaces change. Recheck the linked controls before standardizing a team workflow.
- [Codex best practices →](https://learn.chatgpt.com/guides/best-practices)
- [Codex AGENTS.md →](https://learn.chatgpt.com/docs/agent-configuration/agents-md)
- [Claude Code instructions →](https://code.claude.com/docs/en/memory)
- [Claude Code permissions →](https://code.claude.com/docs/en/permissions)
- [OpenCode rules →](https://opencode.ai/docs/rules/)
- [OpenCode permissions →](https://opencode.ai/docs/permissions)
- [OpenSpec workflow →](https://github.com/Fission-AI/OpenSpec)
When several agents share the work
### Buzz makes the collaboration room part of the record.
Buzz is an Apache-2.0 workspace from Block where people and model-agnostic agents can share channels, threads, workflows and code context. Use it when coordination itself is the problem; one small task for one agent rarely needs another platform.
**Shared context**
Keep the request, agent discussion, evidence, review and approval together instead of copying fragments between separate chats.
**Separate identity**
Give each person and agent its own signed identity and only the channel membership the role needs.
**Human gate**
Let agents propose, compare and critique; keep consequential tool access, merge and release decisions behind named human approval.
**Boundary:** a hosted or self-hosted relay controls the workspace record. It does not make a cloud model local or replace the underlying agent's sandbox, repository scope, network policy and credential controls. Buzz is pre-1.0; verify what works in the current release before relying on a feature.
- [Open Buzz →](https://buzz.xyz)
- [Inspect the source and current status →](https://github.com/block/buzz)
- [Read Block's introduction →](https://block.xyz/inside/introducing-buzz-where-humans-and-agents-work-together)
- [Compare Buzz in the tool catalogue →](https://isaiuseful.com/tools.html.md#buzz)
Context engineering
## Context is a budget—not a repository landfill.
The agent can act only on what its harness sends to the model: instructions, conversation, files, tool descriptions and tool results. Missing facts invite guesses; irrelevant facts bury the useful signal.
Always loaded
**Short repository rules**
Build/test commands, architecture invariants, forbidden paths and verifiable conventions.
This task
**Goal + constraints**
The requested outcome, relevant files, non-goals, acceptance checks and stop conditions.
On demand
**Scoped knowledge**
Nearby instructions, a matching skill, selected documentation and the smallest useful files.
Evidence
**Tool results**
Search output, tests, scans and diffs—trimmed to what the next decision needs.
When it drifts
**Summarize or restart**
Save decisions in artifacts, then compact or open a fresh session for the next coherent task.
Context-engineering hint
**The harness matters. So does the evidence it can reach.**
For open-source dependencies, manuals no longer have to be the agent’s ceiling: the exact source is the strongest evidence of how an implementation behaves. [opensrc](https://github.com/vercel-labs/opensrc) lets a coding agent fetch and search version-matched package or repository source with ordinary tools. Give it the implementation, tests and examples; keep official documentation for the supported contract, migrations and security guidance. [Compare opensrc in the tool catalogue.](https://isaiuseful.com/tools.html.md#opensrc)
> Visual: First agent loop sends system instructions, tools, a prompt and selected files before receiving a response. A second loop carries the repeated prefix and earlier response, then adds a new prompt, file and response, consuming more of the model context limit.
**Visual reading order:**
1. Model-specific context limit
2. **First loop** *System
+ tools* *Prompt* *File* *Response* *Available context*
3. **Second loop** *Repeated prefix + prior response* potentially cached input *Prompt* *File* *Response* *Less room remains*
**System + tools**
**Prompt**
**Selected file**
**Model response**
**Repeated / cached**
Why agent sessions grow
**Every loop adds material the next decision must compete with.**
The harness assembles instructions, tool definitions, conversation, selected files and results for each model call. Repeated prefixes may be cached for efficiency, but caching does not make stale or irrelevant context useful.
| Control | Use it when | Avoid | Portable form |
| --- | --- | --- | --- |
| **Repository instructions** | A rule matters in almost every task in this repository. | Vague advice, temporary task detail and a giant generated handbook. | `AGENTS.md` ; tool-specific files may import or complement it. |
| **Scoped instructions** | A rule applies only to one directory, language or file type. | Loading frontend, database and test conventions into every turn. | Nested `AGENTS.md` files or a tool’s path-scoped rules. |
| **Reusable prompt** | A person starts the same procedure with a different input. | Pretending a one-shot prompt is a permanent project rule. | A versioned Markdown template; native prompt commands where supported. |
| **Skill** | A repeatable multi-step capability should load only when relevant. | One enormous skill that handles unrelated jobs or hides unsafe commands. | `SKILL.md` plus reviewed scripts and references. |
| **Specialist agent** | A recurring role needs a bounded mission and restricted tools. | A “do everything” persona with write, deploy and admin access. | Named agent instructions; read-only archaeologist or test-only reviewer. |
| **MCP or custom tool** | The workflow needs live data or a real action from another system. | Connecting every server, exposing raw admin APIs or trusting model arguments. | A small typed tool contract with least privilege and approval. |
| **Subagent** | A broad, independent investigation would flood the main task context. | Delegating an ambiguous whole project or losing integration ownership. | A bounded read-only brief returning evidence and unresolved questions. |
First valuable skill
### Package judgment you do not want the agent to reinvent.
A skill is a small, version-controlled folder that teaches an agent one repeatable job. Only `SKILL.md` is required; add references, scripts or assets when they improve repeated work. A strong first skill starts with a real standard you can judge—not a vague “be helpful” persona.
**SKILL.md**
Trigger + core workflow
**references/**
Knowledge loaded on demand
**scripts/**
Tested repeatable checks
**assets/**
Optional templates + resources
- [Read the Agent Skills specification](https://agentskills.io/specification)
- [Download color accessibility skill](https://isaiuseful.com/downloads/audit-color-accessibility.zip)
- [Download code structure skill](https://isaiuseful.com/downloads/code-structure.zip)
- [Download evidence-driven testing skill](https://isaiuseful.com/downloads/evidence-driven-testing.zip)
- [Browse NVIDIA agent skills](https://build.nvidia.com/skills)
**Just landed:** [Agent Plugins 1.0.0](https://agent-plugins.org/) wraps Agent Skills and MCP servers in one portable, vendor-neutral package that compatible clients can discover. The client still controls installation, permissions and execution.
**Try it:** give the downloaded folder to your coding agent and ask: `Install this skill where you can discover it for this project, and update AGENTS.md or the repository’s equivalent instructions only if a durable note is needed.` Start a fresh task, describe the job normally and let the agent select a matching skill.
1. **01** **Pick one repeated judgment.** Collect real prompts, inputs, expected outputs and the mistakes that matter. Keep one skill focused on one coherent job.
2. **02** **Write the trigger and workflow.** Give `SKILL.md` a precise name and description, then write the shortest sequence that reliably produces a reviewable result.
3. **03** **Bundle only reusable material.** Move detailed knowledge into references and deterministic repeated work into tested scripts. Leave ordinary reasoning to the agent.
4. **04** **Run it, compare it, improve it.** Test prompts that should and should not trigger it. Replay real tasks, inspect failures and keep a new rule only when it improves the result.
> Visual: A U-shaped recall curve shows information near the beginning and end of a long context as easier to retrieve while information in the middle can be harder to retrieve.
Illustrative · below half full
**The middle can fade before capacity is close.**
Beginning
tokens
Middle tokens
**weaker recall**
End
tokens
Models can over-attend to the beginning and recent end of a long prompt while missing information buried in the middle.
> Visual: A vertical context stack shows the newest tokens clearly at the top while progressively older tokens near the bottom fade, with an illustrative halfway marker across the stack.
Illustrative · beyond half full
**Older material competes with every new turn.**
Newest tokens
Oldest tokens
Illustrative halfway mark
As a session fills, earlier requirements and failed approaches can become less reliably recalled. Different models and harnesses behave differently; the safe response is still smaller tasks and durable artifacts.
01
**Miss**
Record the concrete wrong result, not “the model is bad.”
02
**Diagnose**
Was context missing, contradictory, overloaded—or was the task beyond the model?
03
**Fix**
Add one scoped rule, example, test, tool constraint or smaller task boundary.
04
**Verify**
Undo the result, replay the same case and keep the change only if it helps.
How tool calling works
### The model proposes. Your software executes.
A model can emit a structured request such as `create_issue({title, body})` . The agent harness or your application must validate the arguments, enforce identity and policy, ask for approval when needed, run the function, and return the result. A fluent request is not authorization.
> Visual: Tool calling sequence
> Flow order: User request → Model proposes call → Host validates + approves → Tool runs → Result returns
**Minimum tool contract**
- Precise name, description and typed inputs
- Input validation and target allowlists
- Read-only default; explicit approval for side effects
- Timeouts, bounded retries and safe failure
- Idempotency where a retry could duplicate work
- Logs for attempts, failures and outcomes
- No secret values in prompts, output or logs
Context-rot notice
**A fresh session is a tool, not a failure.**
Long sessions accumulate stale plans, failed approaches and noisy tool output. Preserve approved decisions in `spec.md` , `plan.md` , issues or commits; then summarize or restart before the next distinct task.
**Portable building blocks:** Agent Skills package on-demand procedures; MCP standardizes connections to external tools and data. The context-rot figures are teaching diagrams, not benchmark curves or a model-independent 50% rule.
- [Agent Skills specification →](https://agentskills.io/specification)
- [Model Context Protocol introduction →](https://modelcontextprotocol.io/docs/getting-started/intro)
- [Product Talk on context rot →](https://www.producttalk.org/context-rot/)
Existing and legacy systems
## Rediscover the behavior before rewriting the code.
Old code contains business rules, edge cases and operational bargains that may exist nowhere else. Treat modernization as agent-assisted archaeology followed by normal spec-driven delivery.
**01 · Rediscover**
### What does it actually do?
Produce business rules with code evidence, a data model, integration inventory and an open-questions list. Read one module at a time.
Output: reviewable current-state spec
**02 · Audit**
### What should stay, retire or change?
Compare home-grown utilities, integrations, stores, runtimes and operational assumptions with current supported options. “Keep” is valid.
Output: substitution map + trade-offs
**03 · Re-architect**
### What should the target shape be?
Decide boundaries, data migration, contracts, authentication, secrets, observability, rollback and a cutover strategy before implementation.
Output: approved target plan
**04 · Replace in slices**
### How do we preserve behavior?
Derive tests from rediscovered rules, keep the old interface where practical and switch traffic gradually. Stop when behavior is ambiguous.
Output: tested, committable modules
**05 · Ship safely**
### How does the same artifact reach users?
Build, test and scan in CI; promote through dev and staging; observe both paths and keep a rehearsed rollback during cutover.
Output: repeatable release + recovery
A safe rediscovery prompt
### Ask for evidence, not confidence.
Run this against one module—not an entire twenty-year-old system. A domain expert still has to validate what is active in production.
**Read-only archaeology**
`Do not edit code. For this module, produce: (1) business rules in plain language with concrete file references, (2) entities, relationships and invariants, including database-enforced rules, (3) every external integration and operational dependency, and (4) unresolved behavior questions. Separate evidence from inference. Do not propose a new architecture yet, and never guess a missing business rule.`
Why “strangler”?
**Replace a large system one safe path at a time.**
A strangler-style migration routes selected behavior to the new implementation while the rest stays on the old one. You compare results, increase traffic gradually and retain a rollback instead of betting the business on one big switch.
Security before production
## Make the unsafe path fail early.
An AI review is useful additional evidence. It is not a replacement for deterministic tests, scanners, least privilege or a human who can own the risk.
Non-negotiable default
Security checks run on every pull request, before merge. A production deployment consumes the already-scanned commit; it does not become the first place you discover a secret, vulnerable package or obvious code flaw.
**01 · Spec**
**Threat + data boundary**
Name assets, actors, sensitive data, abuse cases and denied actions.
**02 · Workstation**
**Secret prevention**
Use environment variables, a secret manager and pre-commit or push protection.
**03 · Pull request**
**SAST + SCA + tests**
Scan code, new dependencies, lockfiles, infrastructure and containers.
**04 · Preview**
**DAST + abuse cases**
Test the running preview, authorization failures and untrusted inputs.
**05 · Release**
**Artifact + approval**
Build once, record dependencies, protect deploy credentials and approve promotion.
**06 · Operate**
**Observe + recover**
Monitor, rotate, patch, roll back and learn from real incidents.
Security words in plain language
**Four checks catch different mistakes.**
**SAST** inspects source code. **SCA** checks third-party packages and licences. **Secret scanning** catches credentials. **DAST** probes a running application. None proves the application is secure; together they find problems earlier.
### A sensible setup order for your first repository
Names differ across GitHub, GitLab, Azure DevOps and other platforms, but the control sequence stays useful. Some private-repository features require a paid security plan; use a supported scanner you can require in CI rather than leaving the gate empty.
Repository settings
### Prevent and protect
Enable secret scanning or push protection, dependency alerts, branch/ruleset protection and default code scanning where available. Do not let contributors push directly to the production branch.
Pull-request workflow
### Test the changed commit
Install from the lockfile; run lint, types and tests; then SAST, dependency review and relevant infrastructure/container scans. Give every required check a clear name.
Release environment
### Promote the same artifact
Give deploy credentials only to the release job, require an environment approval, run preview smoke/DAST checks and keep a tested rollback. A later rebuild breaks the evidence chain.
| Gate | Minimum check | Block the change when | Safe response |
| --- | --- | --- | --- |
| Before commit | Secret scan, formatter and focused unit tests | A real credential, private key or generated secret appears. | Remove it, rotate it if exposure is possible, and replace it with a documented secret reference. |
| Pull request | Full tests, lint/type checks, SAST, dependency review and licence policy | A new high/critical flaw, vulnerable runtime dependency, forbidden licence or failing test is introduced. | Fix or remove the change. A time-limited exception needs an owner, reason, compensating control and expiry. |
| Infrastructure | IaC and container scan, least-privilege review and ephemeral credentials | Public exposure, privileged containers, broad IAM or unpinned images appear unexpectedly. | Reduce access, pin the artifact, prove a denied path and document rollback. |
| Preview | DAST, end-to-end smoke tests and authorization abuse cases | One user can read or change another user’s data, input reaches an unsafe sink, or a critical flow breaks. | Return to the spec and threat model; add a regression test before the fix is merged. |
| Deploy | Protected environment, approved artifact, health check and rollback | The commit differs from the scanned artifact, secrets are unavailable or rollback is untested. | Stop promotion. Repair the release path without rebuilding unreviewed code in production. |
**If a secret reaches Git**
Deleting the visible line is not enough because history and logs may still contain it. Revoke or rotate the credential first, investigate its use, then clean history only with repository-owner coordination.
**Why this order:** OWASP’s DevSecOps guidance places multiple security tests inside the delivery pipeline. GitHub’s dependency review is specifically designed to catch risky dependencies while they are still pull-request changes.
- [OWASP DevSecOps guide →](https://devguide.owasp.org/en/09-operations/01-devsecops/)
- [GitHub CodeQL code scanning →](https://docs.github.com/en/code-security/concepts/code-scanning/codeql-code-scanning)
- [GitHub dependency review →](https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-review)
- [GitHub push protection →](https://docs.github.com/en/code-security/concepts/secret-security/push-protection)
- [Claude Code agent security →](https://code.claude.com/docs/en/security)
- [Codex approvals and sandboxing →](https://learn.chatgpt.com/docs/agent-approvals-security)
Developer subscription playbook
## Pay for a fair test. Upgrade the lane that wins your work.
Free plans are product demos, not serious reliability tests. Start with affordable paid access, then put the larger allowance behind the workflow that proves most useful.
Yesterday’s price is not today’s. Today’s price is not tomorrow’s .
Bundled subscriptions can be dramatically cheaper than equivalent API use, but the bargain can move. GitHub Copilot’s June 2026 shift from premium requests to token-priced AI Credits shows how providers can reprice expensive agentic work. Treat the bundle as favorable access—not permanent infrastructure—and keep a tested fallback.
01 · Minimum useful starting point
### Pay for a real trial.
The free tier is fine for simple prompts, but its limits can make capable models feel unreliable. For frequent development, begin with the lowest paid plan on both platforms.
**Rule:** use the checkout price in your region, including tax, and only an organization-approved plan. Do not take annual plans as they don't give flexibility to switch between tiers.
OpenAI
**ChatGPT Plus**
**~20€**
*per month*
Anthropic
**Claude Pro**
**~20€**
*per month*
02 · The upgrade trigger
### Promote the winner.
When a limit repeatedly interrupts useful work, decide which tool fits your workflow better. Upgrade that subscription to its 5× tier and keep the other on the cheaper plan.
**Do not upgrade on one bad day.** Look for a repeated limit pattern across real tasks. While Annual plans might be enticing there might be more value in switching 5x plans between providers as new models are released.
**5×**
roughly €90–€100 per month before tax
03 · Before the 20× plan
### Fix the workflow first.
Improve prompts, context files, tool choice, reusable skills, model routing and the agent harness before buying another block of capacity.
**Practical rule of thumb:** if one developer cannot make 5× last, optimize before assuming the only answer is 20×.
- **Interactive work:** target 5× for a full workweek.
- **20× signal:** measured autonomous or parallel-agent demand.
- **Watch the meter:** model, effort and fast mode change usage.
High-output developer split
### Two subscriptions. One premium lane.
This field-tested setup is used by experienced, high-output developers: keep both tools available, but put the higher tier behind the lane doing the heavier work.
Frontend / UI heavy
#### Claude Max 5× + ChatGPT Plus
**Primary:** Claude Opus 4.8 for interface work, visual judgment and long design iterations.
Backend / general heavy
#### Codex Pro 5× + Claude Pro
**Primary:** GPT‑5.6 Sol High for complex work; GPT‑5.5 Fast when turnaround matters more than maximum reasoning.
**This is a working pattern, not one person’s current split—and not a benchmark verdict.** Run the same representative tasks through both tools, count accepted results and review effort, then let your own work choose the premium plan.
Scope of this recommendation
**Choose the whole system, not only the model.**
This guide concentrates on OpenAI and Anthropic because they are the frontier options used in the subscription pattern above—not because they are the only credible choices. Google, other major labs and Chinese providers may offer a better price, model or regional route for a particular project. No useful guide can list every combination, so explore the wider tool market and test contenders on your own accepted-task set.
**The harness is part of the result.** Context selection, tools, permissions, retries and verification can materially improve—or degrade—the same model’s performance. Cursor can produce a dramatic lift when its editor context, change review and agent loop fit the way a project is built; another workflow may perform better in Codex, Claude Code or a different harness. Test the exact developer workflow, not Cursor or any other harness in the abstract.
**Use bring-your-own-key deliberately in case of Cursor.** Cursor’s Pro tier or higher can run supported OpenAI and Anthropic models through Cursor’s own agent harness using your API key. The provider then meters the model tokens separately—a ChatGPT or Claude subscription does not fund those API calls. Free access is not enough for this route, and specialized features such as Tab completion still use Cursor’s services and models. Evaluate Cursor’s own models separately and keep them only if they earn a place on your work; team plans should also check Cursor’s current platform-token charges.
- [Explore coding tools and harnesses →](https://isaiuseful.com/tools.html.md#tools-build-software-with-agents)
- [See why the harness changes the result →](https://isaiuseful.com/benchmarks.html.md#harness-efficiency)
- [Compare other model routes →](https://isaiuseful.com/cloud-models.html.md#models)
- [Check Cursor’s current pricing →](https://cursor.com/pricing)
- [Check Cursor’s bring-your-own-key limits →](https://docs.cursor.com/settings/api-keys)
- [Check Cursor’s current data controls →](https://cursor.com/data-use)
**Price and model check · 30 July 2026** Official pages list ChatGPT Plus and Claude Pro at about $20 monthly, with 5× individual tiers at $100 and 20x individual tiers at $200 before applicable tax. Regional checkout prices, billing periods, limits and model access can differ.
- [ChatGPT Plus and Pro tiers →](https://help.openai.com/en/articles/9793128-what-is-chatgpt-pro)
- [Claude Pro and Max tiers →](https://claude.com/pricing)
- [GPT‑5.6 model guide →](https://openai.com/index/gpt-5-6/)
- [Claude Opus 4.8 model guide →](https://www.anthropic.com/news/claude-opus-4-8)
- [GitHub Copilot billing change →](https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/)
- [OpenAI API retention controls →](https://platform.openai.com/docs/models/default-usage-policies-by-endpoint)
- [Anthropic zero-retention scope →](https://privacy.anthropic.com/en/articles/8956058-i-have-a-zero-data-retention-agreement-with-anthropic-what-products-does-it-apply-to)
Resilience after subscriptions
## Keep fallback routes. Provision what must be predictable.
An API account provides access, not assured capacity. Put approved provider routes behind one governed gateway, and treat owned compute as a measured capacity decision.
01 · Emergency capacity
### Treat capacity as a portfolio.
Do not assume any one on-demand provider will always have headroom. Keep approved routes behind one policy-enforcing LLM proxy, and add or retire providers only when measured capacity, quality, cost or incident performance justify it.
- [Build the five-minute switch →](#incident-runbook)
02 · Measured scale
### Own compute only after comparison.
Record real tasks and accepted outcomes, then test a suitable open-weight model through a hosted route. Consider owned compute only after quality and usage are known.
- [Run the replacement lab →](#open-alternative)
Production is down, quota is full or capacity is constrained
### Make the emergency switch boring.
The worst time to discover authentication, model behavior or spending controls is during an outage. Test this route before you need it.
1. 01 **Own the account.** Use a team or service account, MFA and a named incident approver—not one developer’s personal billing.
2. 02 **Constrain the key.** Separate it from production application keys; set the smallest model/provider allowlist, budget and expiry that works.
3. 03 **Protect the data.** Apply the same source-code, customer-data, retention and region rules as the normal route.
4. 04 **Run a smoke and failover pack.** Re-run five representative tasks against every emergency route because a fallback model or provider can produce a materially different patch, tool call or latency profile.
5. 05 **Close the incident.** Export usage, record the model and provider, disable the route, rotate if needed and write the lesson into the runbook.
Codex
### Plan + API are separate lanes.
Codex plans provide included usage and optional credits. API-key use is metered by tokens and fits CLI, SDK, IDE or CI; it does not carry every plan/cloud integration.
Claude Code
### Plan + usage credits can bridge a cap.
Claude’s paid plans can enable additional metered usage at standard API rates. A Console/API route remains a distinct billing and governance path.
OpenCode
### The harness follows the provider.
OpenCode connects to many providers and local models. With OpenRouter, use a dedicated prepaid key, budget guardrail and an explicit model/provider policy. Provider credentials stay local, so protect the workstation profile and never commit keys.
OpenSpec
### The spec does not buy inference.
OpenSpec stores planning artifacts and commands for supported coding tools. Authentication, quotas, model quality and data policy still belong to the agent/provider route.
**Incident boundary**
Do not send production secrets, customer records or unredacted incident logs to a personal account just because it has remaining quota. An emergency shortens time; it does not suspend data policy.
**Capacity check:** On-demand throughput can vary. Provision critical demand; Azure Reservations reduce cost but do not secure Microsoft Foundry capacity.
- [Codex plans and API lane →](https://learn.chatgpt.com/docs/pricing)
- [Claude additional usage →](https://support.claude.com/en/articles/12429409-manage-usage-credits-for-paid-claude-plans)
- [OpenCode providers →](https://opencode.ai/docs/providers)
- [OpenRouter budgets and allowlists →](https://openrouter.ai/docs/guides/features/guardrails/overview)
- [Amazon Bedrock provisioned throughput →](https://docs.aws.amazon.com/bedrock/latest/userguide/prov-throughput.html)
- [Microsoft Foundry provisioned throughput →](https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput)
- [Why Azure Reservations do not guarantee capacity →](https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/microsoft-foundry)
Hosted success → open alternative
## Judge a replacement by its results, not its reputation.
Once an online model works, preserve its successful tasks as a baseline. An open-weight candidate earns a place by matching those outcomes at acceptable speed, cost and risk.
> Visual: Open model replacement evaluation sequence
**Visual reading order:**
1. **01** **Freeze the job** 50–100 real, redacted tasks with acceptance checks and human outcomes.
2. **02** **Shortlist weights** Match licence, context, tool use, language, memory fit and public evidence.
3. **03** **Test hosted** Use OpenRouter or another hosted route before buying hardware.
4. **04** **Replay locally** Pin checkpoint, quantization, runtime, prompt and tools.
5. **05** **Decide** Compare accepted work, latency, operating effort and total cost.
Licence notice
**Open-weight is not automatically open source.**
A downloadable checkpoint may still restrict use, modification or redistribution. Read the exact model card and licence, record the version, and check whether your planned commercial or internal use is permitted. The [Open Source AI Definition](https://opensource.org/ai/open-source-ai-definition) is a useful benchmark for the stronger term.
| Measure | Hosted baseline | OpenRouter candidate | Local candidate | Reject when |
| --- | --- | --- | --- | --- |
| Accepted-task rate | Human-approved result on the same fixed cases | Same rubric and retry limit | Same checkpoint family, prompt and tool contract | The quality gap creates more review or rework than the saving covers. |
| Reviewer effort | Minutes and material edits per accepted task | Measure changed lines and review minutes | Measure again; quantization may change behavior | Humans become the hidden inference engine. |
| Reliability | Tool failures, retries and timeouts | Pin provider and disable fallback for the experiment | Record crashes, OOMs, queue time and recovery | The route cannot finish the real workflow predictably. |
| Performance | Wall time, time to first token and output speed | Record provider and endpoint metadata | Test concurrency, context and sustained load | Interactive latency or team throughput misses its service target. |
| Economics | Plan cost plus measured overflow/API cost | Input, cache and output cost per accepted task | Capex, power, cooling, operations and variable cost | Savings disappear after failed tasks and staff time. |
A fair OpenRouter trial
### Pin what can silently change.
Select the exact model. For a controlled comparison, set a provider order and disable automatic fallbacks; otherwise a successful response may come from a different endpoint. Enforce the data policy your inputs require, including zero-data-retention routing where appropriate.
- [Provider selection and fallback controls →](https://openrouter.ai/docs/guides/routing/provider-selection)
- [Zero-data-retention routing →](https://openrouter.ai/docs/guides/features/zdr)
- [Shortlist current local model families →](https://isaiuseful.com/local-models.html.md#catalog)
- [Choose relevant public benchmarks →](https://isaiuseful.com/benchmarks.html.md#database)
Cloud-to-local calculator
## Buy hardware only when measured work pays for it.
Use accepted tasks, not raw tokens. A cheap model that fails twice and needs a rewrite is not cheap.
Use at least one month of measured hosted/OpenRouter results. Put staff time, support, storage, networking and realistic electricity into the local side.
Measured example
**Local is cheaper at this volume**
Quality and capacity still have to pass.
Hosted / month
**€510**
Local / month
**€332**
Break-even volume
**372 tasks**
Simple payback
**14.9 months**
**The model**
`local monthly = hardware ÷ useful life + energy + operations + accepted tasks × local variable cost`
`break-even tasks = local fixed monthly ÷ (hosted cost/task − local variable cost/task)`
This result is financial only. Keep hosted access until the exact local model, quantization and runtime pass quality, latency, concurrency, context and recovery tests.
No purchase
### Existing computer or hosted model
Best for the first baseline and low or irregular volume. Use idle hardware only if its model passes; “already owned” does not make staff time free.
One power user
### DGX Spark class
DGX Spark has 128 GB unified memory and NVIDIA documents model support up to 200B parameters. Fit is not speed: benchmark the exact checkpoint, quantization, runtime and context.
- [Use the Spark runbook →](https://isaiuseful.com/remote-spark.html.md#spark-setup)
Team / large model
### DGX Station class
The current Grace Blackwell DGX Station architecture offers up to 748 GB coherent memory, including up to 252 GB HBM3e. It needs a utilization case, support owner and acceptance test—not just a model that loads.
- [Use the Station buyer’s guide →](https://isaiuseful.com/dgx-station.html.md)
Shared service
### Private cloud
Consider a shared cluster when multiple teams have steady, governed demand and can operate identity, scheduling, observability, backups, patching and incident response. Rent a comparable service before building one.
- [Compare infrastructure tiers →](https://isaiuseful.com/cloud-models.html.md#hardware)
Not only a cost decision
**Privacy or latency may justify local before financial break-even.**
Say that explicitly. The benefit is then risk reduction, data control or service behavior—not cheaper tokens. Local also creates new obligations: endpoint security, physical access, patching, backups, model licences and an operator who answers when it fails.
**Hardware facts:** vendor parameter ceilings are fit/support claims, not your application’s throughput or accuracy result. Request a quote and enter the full delivered/setup cost in the calculator.
- [Official DGX Spark hardware →](https://docs.nvidia.com/dgx/dgx-spark/hardware.html)
- [Official DGX Station architecture →](https://docs.nvidia.com/dgx/dgx-station-development-guide/overview.html)
- [Local model and memory guide →](https://isaiuseful.com/local-models.html.md)
- [Cloud and owned-infrastructure guide →](https://isaiuseful.com/cloud-models.html.md)
Your first month
## Build capability in four small weeks.
Do not install every plugin, agent and server on day one. Add a capability only when a real workflow proves it is useful.
**Week 1**
### Learn and map
- Finish the main Learn Git Branching levels.
- Create a practice repository and a branch.
- Ask an agent to explain one small codebase without editing.
- Review every proposed command.
**Exit: you can show a diff and return to a clean checkpoint.**
**Week 2**
### Specify and build
- Choose one tiny user-visible change.
- Write scope, acceptance examples and stop rules.
- Approve a plan, implement one task and add tests.
- Record which instruction would prevent a repeated mistake.
**Exit: the change is understandable in one review.**
**Week 3**
### Secure the path
- Enable secret prevention.
- Run tests, SAST and dependency review on pull requests.
- Test one denied authorization case.
- Require checks before merge and protect deploy credentials.
**Exit: an unsafe sample change fails before production.**
**Week 4**
### Measure and prepare
- Track accepted tasks, edits, time and plan/API use.
- Configure a capped emergency API route and run its smoke pack.
- Replay a small test set on one open-weight candidate.
- Keep renting unless quality, volume and economics justify local.
**Exit: you have data—not a hardware wish list.**
**What progress looks like**
You can explain the requirement, the change, the tests, the scan results, the cost and the rollback without asking the model to remember for you.
The durable skill
Use AI to widen your reach— not to outsource your judgment.
- [Start the first task](#start)
- [Choose another workflow](https://isaiuseful.com/guides.html.md)
- [Scale a proven coding workflow](https://isaiuseful.com/adoption.html.md#engineer)