Getting set up

There are plenty of harnesses to choose from.

• Codex and Claude Code are the popular proprietary harnesses, complete with a Command Line Interface (CLI), desktop apps, and plugins for Integrated Development Environments (IDEs) like VS Code or JetBrains.

• Some others are complete IDEs of their own (like Cursor or Antigravity), usually forks of the popular VS Code IDE.

• There are also lots of open-source options that you can find on GitHub, like cline, Kilo Code and opencode.

• Use the CLI, an IDE plugin, or the desktop app, whichever you are most familiar with. They all tend to offer similar functionalities.

What model to use?

A handful of the providers you’ll run into: proprietary (OpenAI, Anthropic, xAI) alongside open-weight (DeepSeek, Kimi, Qwen).

The answer to this question keeps changing: models keep getting better, the competition is fierce, and the ‘best’ one depends on when you ask. You can follow the leaderboard of model performance on sites like LMArena (now Arena): https://arena.ai/leaderboard

Then, there is the cost: proprietary models tend to be the most expensive. They charge separately for the tokens you send in and the tokens they send back, while the alternative open-source, cloud-based models are often dramatically cheaper. DeepSeek-V4-Flash, for instance, runs about $0.14 per million input tokens and $0.28 per million output, against Claude Sonnet 5 at $2 and $10: between 14 and 36 times less, depending on how your usage splits between input and output.

Don’t take that as a rule, though. Pricing varies by model and by the provider hosting it, and open weights — a model whose innards the maker has published, so anyone can host it or run it themselves — do not automatically mean cheap: Kimi K3 is $3 and $15 per million, which is more expensive than Sonnet 5. On quality, the open models may not be at the very top, but they are often close (depending on the moment).

Local models

Everything above assumes you are renting a model from somebody. You don’t have to: open weights means you can download the model and run it on your own hardware. Your code never leaves the machine, there is no per-token bill, and nothing changes under you when a provider updates its pricing or its terms. If you work on code you are contractually not allowed to send to a third party, that isn’t a preference, it’s the only option.

The catch is what it costs to get there.

The rest of this section is hardware arithmetic; if you are not shopping for a machine, the short version is that it costs more than you think and the target keeps moving.

Around 24GB of VRAM — the memory on the graphics card, which is where the model has to sit — is a fair floor for a model genuinely useful for coding, and you shouldn’t spend all of it on weights: target 14 to 20GB and leave the rest for the KV cache, the running notes the model keeps on the conversation, which fills fast once an agent starts accumulating tool calls and file contents. That budget runs something like Gemma 4 or Qwen3.8-27B, quantized to fit. Good models. Not the model you are used to.

Going past that gets expensive quickly. A Mac Studio or an NVIDIA DGX Spark with 128GB of unified memory runs $4,500 to $6,900, and a top-tier open-weight model like Kimi K3 will not fit on one. All 2.8 trillion of its parameters have to sit in memory even though only 104 billion are active on any given token, which puts its weights at 1.56TB. Marketing quotes the active number; memory doesn’t care.

People do build clusters for it, and the one that works is four Mac Studios with 512GB each, mesh-connected, around $40,000. It generates about fifteen tokens a second — the speed of a slow typist — because the link between consumer machines is nothing like the wiring inside a real server. Apple stopped selling that 512GB configuration in 2026 when memory prices spiked, so you may not even be able to buy it new. The same model rented through an API costs $3 and $15 per million tokens. Running a frontier open-weight model at home is a demonstration, not a deployment.

Two costs people leave out. Power: a few active hours a day on a small rig runs near 180kWh a month, about $61 in California — a recurring cost that never shows up on the sticker price. And obsolescence: a year ago a far smaller rig would have done, because Kimi K2 was a third the size. K3 tripled it, and the advice went stale without anyone announcing it. You are buying hardware against a target that moves every few months.

Privacy is worth paying for. Just know what you are paying.

Pro Tip

Before buying anything, run the model you are considering on the hardware you already have, against a real task in a real project rather than a chat prompt. A local model that answers questions well can still fall apart on the tool-calling loop, and that loop is what you will actually be using.

Resource Links

• Ollama, the simplest way to run a model locally: https://ollama.com
• LM Studio, a desktop app with a model browser: https://lmstudio.ai
• llama.cpp, the engine most of them are built on: https://github.com/ggml-org/llama.cpp
• Open weights to download, with quantized builds: https://huggingface.co/models

API per token use vs. subscriptions

Models are priced per input token and per output token (per million tokens, actually) for API usage — paying the provider directly, by the token, instead of buying a subscription — so they can be compared that way, but using the API is usually much more costly than using a subscription.

Proprietary model providers as well as open-source cloud model providers offer subscriptions that include a variable and undisclosed amount of token usage per ‘session’ and per week. Sessions tend to be a 5-hour block of time, with a cap per week on top. Some subscriptions start with a very limited free tier, but the realistic entry point is around $20 a month: that is what both Claude Pro and ChatGPT Plus cost, and it may sometimes be worth hundreds of dollars of API token usage. The heavier tiers run $100 to $200 a month.

Compare and contrast for yourself, but a subscription is usually the way to go.

What harness with what subscription?

Can I use OpenAI models with Claude Code? In theory, yes. In practice, it’s best to stick with the harness built by the model provider, for many reasons:

• proprietary model subscriptions have terms and conditions for their usage. An Anthropic subscription, for example, is meant for Claude Code, the Agent SDK, and Anthropic’s own applications (claude.ai, Claude Desktop) — not for third-party clients. Their Legal & Compliance page states that OAuth login is “intended exclusively for purchasers of Claude Free, Pro, Max, Team, and Enterprise subscription plans and is designed to support ordinary use of Claude Code and other native Anthropic applications”, and it bars third parties from routing requests through those credentials.

  The risk here is not Codex or Cursor, which don’t offer an Anthropic login in the first place. It is the various tools and wrappers that extract your Claude OAuth token and replay it to impersonate Claude Code. That is exactly what the terms prohibit, Anthropic reserves the right to enforce them without prior notice, and it did enforce in February 2026. Using one of those is a real way to get your account blocked or banned.

However, it’s possible to use API access with any harness; the cost may not be worth it.

Most open-source model providers don’t have restrictions on what harness you use, so it’s possible to use models like DeepSeek, Qwen, or Kimi using the Claude Code harness or Codex. This is set in the configuration — here’s what that actually looks like for each harness, pointed at the GLM models from Z.ai, the Chinese lab Zhipu AI, over its Anthropic-compatible endpoint. If you aren’t going to wire up a third-party provider yourself, skip to “Useful plugins and skills” — nothing later on depends on this.

Claude Code

Claude Code reads a third-party endpoint and model overrides from an env block in a settings JSON file. For your own machine, that’s ~/.claude/settings.json (create it if it doesn’t already exist); for a project shared with a team, put the same block in that project’s .claude/settings.json instead. See Settings files and precedence for how the two combine, and note that keys set closer to the project win.

~/.claude/settings.json

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "<your-api-key>",
    "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-5.3-flash[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.3[1m]",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.3[1m]",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "API_TIMEOUT_MS": "3000000"
  }
}

What each key does, confirmed against Claude Code’s own environment variables reference and model configuration docs:

• ANTHROPIC_AUTH_TOKEN sends your key as an Authorization: Bearer header, the shape most third-party gateways expect (as opposed to ANTHROPIC_API_KEY, which is for Anthropic’s own Console keys and sends X-Api-Key instead).
• ANTHROPIC_BASE_URL overrides the API endpoint.
• ANTHROPIC_DEFAULT_HAIKU_MODEL / _SONNET_MODEL / _OPUS_MODEL remap what the haiku, sonnet, and opus aliases resolve to; the [1m] suffix requests the provider’s extended context window where it’s supported.
• CLAUDE_CODE_AUTO_COMPACT_WINDOW sets how many tokens of context Claude Code fills before summarizing older turns — from 100,000 up to 1,000,000.
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC turns off auto-update checks, telemetry, and other calls back to Anthropic that a third-party-only setup doesn’t need.
• API_TIMEOUT_MS is the per-request timeout in milliseconds; third-party endpoints are sometimes slower than Anthropic’s own.

Model names move fast — GLM was on 5.3 at the time of writing, and the exact IDs above came straight from Z.ai’s own Claude Code setup guide. Check that page for whatever’s current before pasting this in.

Codex

Codex reads provider configuration from a TOML file at ~/.codex/config.toml (Codex calls this directory CODEX_HOME; it defaults to ~/.codex). Point it at a third-party OpenAI-compatible endpoint by defining a custom entry under [model_providers.<id>] and selecting it with the top-level model_provider key — this shape is confirmed against OpenAI’s own Codex configuration reference and advanced configuration guide:

~/.codex/config.toml

model_provider = "third-party"
model = "<model-id-your-provider-supports>"

[model_providers.third-party]
name = "My third-party provider"
base_url = "https://api.example.com/v1"
env_key = "THIRD_PARTY_API_KEY"

Then, in your shell — never in config.toml itself:

export THIRD_PARTY_API_KEY=<your-api-key>

env_key doesn’t hold the key. It names an environment variable — a named value your program reads from its surroundings instead of from its own code — that Codex reads the key from at runtime, so the real value never has to sit in a file, checked into git or not. Here’s one of OpenAI’s own worked examples, verbatim, for a real provider using this same shape:

model_provider = "mistral"

[model_providers.mistral]
name = "Mistral"
base_url = "https://api.mistral.ai/v1"
env_key = "MISTRAL_API_KEY"

One catch: a custom provider’s wire_api defaults to "responses", and per OpenAI’s own reference that is currently the only value it supports. The endpoint needs to speak OpenAI’s newer Responses API shape, not just the older Chat Completions shape that a lot of “OpenAI-compatible” third-party APIs actually implement — check your provider’s docs before assuming this will work.

Never commit a real key

Whatever value replaces <your-api-key> above is a secret, in either harness. Follow the Credentials guidance: keep it out of anything committed to git. For Claude Code, that means preferring a project’s .claude/settings.local.json (which Claude Code keeps out of git for you) over a shared, committed .claude/settings.json if the key has to live in a settings file at all. For Codex, it means the key only ever lives in your shell environment or an untracked .env — never typed into config.toml.

Useful plugins and skills

There is a vast quantity of open-source plugins and skills out there, and some are worth mentioning:

• The official Claude Code plugins live at https://github.com/anthropics/claude-plugins-official, and include:
  • superpowers: a set of process skills (brainstorming before building, systematic debugging, test-driven development, writing plans) that push the agent through an engineering workflow instead of letting it dive straight into code. If you install only one thing from this list, install this one.
  • remember: persists session history and the decisions made along the way, so your context survives between sessions instead of starting from nothing every morning.
  • code-review: structured review of the changes that were just made.

Claude Code

Add the marketplace once, then install whichever plugins you want from it — either from inside a session with the /plugin slash command:

/plugin marketplace add anthropics/claude-plugins-official
/plugin install superpowers@claude-plugins-official

or, non-interactively (for example in a setup script), with the claude plugin CLI subcommand:

claude plugin marketplace add anthropics/claude-plugins-official
claude plugin install superpowers@claude-plugins-official

Swap superpowers for remember or code-review to install those instead — same marketplace, same two commands. Both forms are confirmed against Claude Code’s own plugin discovery and plugins reference docs.

Codex

Codex has its own plugin marketplace mechanism, with real working commands — but it is not a drop-in replacement for the repo named above. anthropics/claude-plugins-official publishes a .claude-plugin/marketplace.json catalog in Claude Code’s own schema; Codex instead looks for .agents/plugins/marketplace.json in whatever repo you add. The two catalog formats aren’t interchangeable, so pointing Codex at that same repo won’t work.

OpenAI’s own equivalent lives at https://github.com/openai/plugins: an actively maintained repo under the openai GitHub org publishing exactly that catalog (marketplace name openai-curated), and the actual source for the curated directory built into the Codex app — OpenAI’s own docs load the plugin browser’s icons straight from this repo. Most of it is company connectors (Figma, Slack, Stripe, and the like), but two entries earn a place in an everyday coding setup:

• superpowers: the same planning, test-driven development, and systematic-debugging skill set as the Claude Code plugin above, ported to Codex almost skill-for-skill. Install this one first.
• coderabbit: AI code review from CodeRabbit, packaged as Codex skills that inspect your current diff — the lines the agent has added, changed or deleted since your last checkpoint — and turn findings into follow-up fixes.

There’s no Codex plugin for session memory yet — nothing in the official marketplace does what remember does for Claude Code. That’s a real gap in the ecosystem today, not an omission here.

Register the marketplace and install from it:

codex plugin marketplace add openai/plugins
codex plugin add superpowers@openai-curated

(marketplace add also accepts a --ref <branch>, a Git URL, or a local path; manage what’s registered with codex plugin marketplace list, upgrade, and remove. Swap the plugin name to install coderabbit instead.) You can also skip the CLI and run /plugins inside a Codex session to browse and install from any configured marketplace, including the directory that ships built in. Verified against OpenAI’s own Codex plugins, building Codex plugins, and developer commands docs.

Explore Further

https://github.com/multica-ai/andrej-karpathy-skills is widely used, and worth reading even if you never install it. Despite the name, it is not a skills marketplace: it is a single CLAUDE.md file (plus a Cursor-rules variant and a plugin wrapper) encoding four behavioral rules drawn from Andrej Karpathy’s observations of where LLMs go wrong when they write code. Think before coding: state your assumptions and ask rather than guess. Simplicity first: no speculative features. Surgical changes: edit what was asked and nothing else, no drive-by refactors. Goal-driven execution: turn a vague request into verifiable success criteria. Those four ideas are most of what separates a good prompt from a bad one, whatever harness you use.

Installing a skill into your project

A plugin bundles several skills at once; sometimes you just want one, from a repo that isn’t a plugin at all. That’s a plain file copy — no marketplace involved.

Claude Code

Skills live at .claude/skills/<skill-name>/SKILL.md: inside a project to check into git and share with the team, or under ~/.claude/skills/<skill-name>/SKILL.md on your own machine to load in every project you open. The file needs name and description in a short header block at the top; everything after it is the instructions Claude reads once the task matches.

The Karpathy repo above ships exactly such a file, so grab it directly:

mkdir -p .claude/skills/karpathy-guidelines
curl -o .claude/skills/karpathy-guidelines/SKILL.md \
  https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/skills/karpathy-guidelines/SKILL.md

That’s the whole install. (The repo also ships a Claude Code plugin wrapper — /plugin marketplace add multica-ai/andrej-karpathy-skills then /plugin install andrej-karpathy-skills@karpathy-skills — which installs the same skill file; either path works.) If you’d rather have the four rules as always-on project context instead of a skill Claude decides when to invoke, curl the repo’s plain CLAUDE.md into your own instead:

curl https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

Confirmed against Claude Code’s own skills docs.

Codex

Codex uses the same SKILL.md shape, just a different directory: .agents/skills/<skill-name>/SKILL.md in the repo (Codex walks up from wherever you launched it to the repo root, so this works from any subdirectory), or ~/.agents/skills/<skill-name>/SKILL.md for every project on your machine.

The Karpathy repo’s skill file needs no changes to work here — same frontmatter, same body:

mkdir -p .agents/skills/karpathy-guidelines
curl -o .agents/skills/karpathy-guidelines/SKILL.md \
  https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/skills/karpathy-guidelines/SKILL.md

This particular repo only ships a Claude Code plugin manifest, not the .agents/plugins/marketplace.json Codex’s marketplace command looks for, so codex plugin marketplace add won’t find it here — copying the file directly, as above, is the way. For the always-on-context version, Codex reads AGENTS.md instead of CLAUDE.md; the repo doesn’t publish one, but the content is plain Markdown, so the same file works there too:

curl https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md >> AGENTS.md

Confirmed against OpenAI’s own skills docs.