Ask Claude Code to fine-tune a model and the first thing worth clearing up is what it can't do: it can't touch its own weights. Fine-tuning a model from Claude Code means pointing the agent at an open-weight model, such as Llama 3.1 or Qwen, not at Claude itself. Anthropic doesn't expose Claude's weights for fine-tuning, so every chat-triggered fine-tune in 2026 works the same way: the agent writes and runs training code against an open model on a GPU it provisions on your behalf, then reports back what happened. This is that mechanism end to end, using Spheron's Agent GPU Sandbox: the prompt you'd actually type, which GPU the agent picks, what the background job looks like while it runs, and what it costs.
TL;DR: How to Fine-Tune a Model From Claude Code
- Mechanism: Claude Code connects to Spheron's Agent GPU Sandbox at
connect.spheron.ai/mcpwith one setup command, then the agent provisions its own GPU VM and runs the fine-tune there. - Not Claude itself: you can't fine-tune Claude's weights from chat; the agent trains an open model (Llama, Qwen, and similar) on a GPU it rents, not the model answering you.
- GPU default: Spheron's own documented example prompt is "Fine-tune Llama 3.1 8B on my dataset on an H100 and report the eval loss."
- Background limit: one background command inside the sandbox can run for up to 24 hours before it needs restarting, which comfortably covers an 8B QLoRA run.
- Cost: you pay the instance's normal hourly rate, Spheron H100 on-demand runs $2.64/hr as of 01 Nov 2026, and the sandbox itself is free. Compare live GPU pricing.
Can You Actually Fine-Tune Claude Itself?
No, and this is worth stating plainly before anything else. "Fine-tune Claude" and "fine-tune a model from inside Claude Code" are two different claims, and only the second one is true. Claude's weights stay with Anthropic. What a Claude Code session can do is act as the orchestrator: it reads your instructions, writes the training script, provisions the hardware, and runs an open-weight model's fine-tune on your behalf. The "chat" part of "fine-tune from chat" refers to where the instructions come from, not what gets trained.
The Prompt: What You Actually Type to Claude Code
The workflow starts with one message in a Claude Code session, after the Agent GPU Sandbox has been added as an MCP server. Spheron's own documentation gives the baseline form of that prompt: "Fine-tune Llama 3.1 8B on my dataset on an H100 and report the eval loss." A real prompt usually adds a dataset path and a couple of training specifics so the agent doesn't have to guess at anything that matters for reproducibility.
Before that prompt means anything, the sandbox has to be connected once, per session or per machine:
claude mcp add --transport http spheron https://connect.spheron.ai/mcpWith that in place, a prompt that works in practice looks closer to this:
Fine-tune Llama 3.1 8B on my dataset on an H100. The data is at
~/datasets/support-tickets.jsonl in ChatML format, about 3,000 examples.
Use LoRA with Unsloth, one epoch, and save the adapter when it's done.
Tell me the final loss and how long the run took.Nothing in that message specifies a CUDA version, a batch size, or a learning rate schedule. The agent fills in Unsloth's standard defaults (LoRA rank 16, a 2e-4 learning rate, one epoch) unless you override them, and it only stops to ask when something is genuinely ambiguous, like which of several local checkpoints to start from. If your dataset is large, that path matters: file transfer between chat and the sandbox VM is capped at 5 MB per file, so anything beyond a toy dataset has to be downloaded directly on the machine, by wget, git clone, or a cloud storage pull the agent runs itself, rather than pasted through the chat window.
If your checkpoint is a Llama 4 model instead of 3.1, say so in the prompt: Llama 4's MoE architecture changes the VRAM math enough that the Llama 4 fine-tuning guide is worth reading before you commit a GPU tier to it.
Which GPU the Agent Picks, and Why
The agent doesn't pick a GPU by feel. It matches your prompt against the sandbox's supported tiers (H100, H200, B200, B300, A100, L40S, and RTX cards) and provisions whichever one the instruction names, defaulting to a safe but not wasteful size when you leave it unspecified. Supported GPUs and the pay-only-for-the-instance model are documented on Spheron's Agent GPU Sandbox page.
An 8B model trained with QLoRA needs roughly 8 GB of VRAM, well inside even a mid-range card, and the full VRAM breakdown across full fine-tuning, LoRA, and QLoRA for 7B through 70B models is in Spheron's GPU VRAM requirements guide. That guide is also the reason Spheron's own documented example asks for an H100 for an 8B job specifically: it's a deliberately oversized, safe default rather than the minimum viable tier. If you care about cost more than headroom, naming a smaller GPU in the prompt, or an H100 GPU rental only when the job genuinely needs the extra memory, say for a 70B QLoRA run, is the better instinct. The agent follows what you ask for; it won't downgrade your H100 request to something cheaper on its own.
It's also worth being clear about what this sandbox is not. It isn't a sub-second code execution environment the way CPU-only agent sandboxes like E2B or Daytona are, covered in Spheron's AI agent code execution sandbox guide. A GPU VM here typically becomes ready 1-3 minutes after you approve the deploy preview, which is fine for a multi-hour training job and wasteful for running a one-line script. Treat it as a GPU workstation the agent operates, not a fast CPU snippet runner.
Watching the Run: Logs, Checkpoints, and the 24-Hour Background Limit
Once training starts, the agent runs it as a background command rather than a blocking one. The default command timeout inside the sandbox is 10 minutes, which is nowhere near enough for a training job, so a fine-tune has to be launched as an explicit background command, with output streaming back to the chat as it progresses. A single background command can run for up to 24 hours before it needs to be restarted, which is comfortable headroom for an 8B QLoRA job: Spheron's own fine-tuning cost guide puts a 7B-8B QLoRA run with Unsloth at 2-4 hours on a single GPU. A job that genuinely needs longer than a day has to checkpoint and resume across more than one background command rather than run as a single call.
While it runs, what you see in the chat resembles the step logs any Unsloth or TRL training loop prints: loss per logging interval, learning rate, and periodic evaluation numbers if you asked for a held-out split. The agent periodically relays the latest lines rather than the full stream, and checkpoints land on the VM's own disk at whatever interval your training arguments set. Because packages, the downloaded base model, and any checkpoints persist on the VM between tasks, you can ask the agent to resume from the last checkpoint in a follow-up message without redownloading an 8B or 70B model from scratch.
Is It Safe to Let an Agent Run sudo Commands on a GPU?
The honest answer is that the sandbox is built to limit what can go wrong, not to pretend nothing can. The agent runs shell commands as the login user with sudo, and the exit code and full output come back into the chat, so you see exactly what ran. Several controls sit around that access: every deploy, Stop, Start, and terminate shows a price preview and needs your explicit approval before it executes, only the person who deployed the instance can use its sandbox, the VM opens no inbound port and only talks outward to Spheron over HTTPS, and every command is logged with its text and exit code. You can also set a spend limit per hour on a connection, and a launch that would exceed it gets refused rather than approved silently. On top of all that, your own SSH key keeps working the entire time, so you can log into the same VM mid-run and look at exactly what the agent is doing, or take over if something looks wrong. More detail on each of these controls is in Spheron's Agent GPU Sandbox docs.
What It Costs to Fine-Tune a Model From Claude Code
The sandbox itself doesn't carry a separate fee. What you pay for is the GPU instance's normal hourly rate for however long it stays running, the same rate you'd see renting that GPU directly. Spheron's on-demand H100 runs $2.64/hr as of 01 Nov 2026, and on-demand B200 and B300 rates are on the same live pricing page.
For the 8B LoRA example above, that means a run landing in the 2-4 hour range Spheron's own fine-tuning cost guide documents for a comparable QLoRA job costs roughly that many hours of H100 time, plus whatever idle minutes pass before you tell the agent to stop or terminate the instance. That guide's worked example puts a 7B-8B QLoRA job at $1.10-2.20 on a cheaper RTX 4090, so asking for an H100 specifically, as Spheron's documented example prompt does, is paying a premium for memory headroom an 8B job doesn't strictly need. Naming a smaller GPU for a small model, and reserving the H100-class request for 70B-scale QLoRA or multi-GPU LoRA jobs, is the cheaper habit.
Pricing fluctuates based on GPU availability. Spheron rates above are live as of 01 Nov 2026; other figures reflect benchmarks recorded on their own stated dates and may have changed. Check current GPU pricing → for live rates.
To reproduce the walkthrough end to end:
- Add the MCP server once:
claude mcp add --transport http spheron https://connect.spheron.ai/mcp. - Send a prompt naming the model, the dataset path, and the method, the way the example above does.
- Approve the deploy preview when the agent shows you the GPU and its price.
- Let the training run as a background command and check in on the streamed logs.
- Approve the Stop or terminate prompt once the agent reports the final loss and the adapter path.
Once the adapter is trained, the next step is usually serving it rather than leaving it on the VM's disk. Spheron's LoRA multi-adapter serving guide covers loading a base model once and hot-swapping adapters per request, which is how the LoRA this walkthrough just trained actually gets used in production.
Triggering a fine-tune from a single Claude Code prompt only works if the agent can get its hands on real GPU hardware without you opening a terminal yourself, which is what Spheron's Agent GPU Sandbox is for.
Frequently Asked Questions
No. Anthropic doesn't expose Claude's weights for fine-tuning, so nothing a Claude Code session does changes the model you're chatting with. What it can do is provision a GPU through the Agent GPU Sandbox and fine-tune an open-weight model, such as Llama 3.1 or Qwen, on your own dataset. Claude is the agent driving the job, not the model being trained.
It writes and runs the training code itself. After connecting to Spheron's Agent GPU Sandbox, the agent deploys a GPU VM, installs the training stack (commonly Unsloth or TRL), downloads your dataset directly on the machine, starts a background training command, and reports back the loss curve and the saved adapter path once it finishes, or at intervals while a longer job is still running.
The sandbox is built to limit the blast radius rather than remove the risk. Every deploy, Stop, Start, and terminate shows a price preview and needs your explicit approval first, only the person who deployed the instance can use its sandbox, the VM opens no inbound port, and every command the agent runs is logged with its text and exit code. You can also cap a connection with a spend limit per hour so a runaway loop can't run up an open-ended bill.
The sandbox itself is free; you pay the GPU instance's normal hourly rate for however long the job runs. Spheron's on-demand H100 runs $2.64/hr as of 01 Nov 2026, and an 8B LoRA job typically needs 2-4 hours based on Spheron's own QLoRA benchmarks, so the training bill lands in the same low range those benchmarks show for a comparable job, before counting any idle time left running before you stop the instance.
