We gave Claude Fable 5 one job: register a domain without human help

On June 9, Anthropic released Claude Fable 5, the first Mythos-class model available to the general public. Launch coverage describes it as Anthropic's most capable public model so far, with an emphasis on software engineering, knowledge work, vision, and longer multi-step tasks (TechCrunch).

Long, complex, multi-step tasks is exactly the category "go get yourself a domain and set it up" falls into. So we set up the obvious test: connect Fable 5 to the AIvikings MCP server, give it a plain-English goal, and watch how it handles a registrar workflow.

What Fable 5 is, in 60 seconds

The short version, for anyone who skipped the launch coverage:

• Mythos-class is a new tier Anthropic positions above Opus. Fable 5 and the restricted Claude Mythos 5 are the same underlying model; the difference is the safeguards around it.
• Fable 5 ships with a routing safeguard: queries in certain high-risk areas (cybersecurity, biology) get answered by Claude Opus 4.8 instead. Anthropic says this triggers rarely, with early data showing at least 95 percent of sessions running fully on Fable 5 (TechCrunch).
• API pricing is reported at 10 dollars per million input tokens and 50 dollars per million output tokens. Model string: claude-fable-5.
• Early customer comments in launch coverage highlight tool-calling, one-shot app building, and self-validation on harder tasks.

That last point is the one a domain registrar for agents cares about. Better tool use and self-validation should mean fewer retries, fewer malformed tool calls, fewer cases where you babysit the loop. Testable.

The test setup

We used the Anthropic Messages API with the MCP connector, pointed at our production MCP server. No custom agent framework, no retry wrapper, no system prompt engineering. The whole harness:

import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=2000,
    messages=[{
        "role": "user",
        "content": (
            "You are setting up infrastructure for an automated "
            "price-monitoring service. Find an available domain that "
            "describes the service, register it for one year, and "
            "confirm the registration status. Pick something on .icu, "
            ".sbs, or .cfd. Human memorability is irrelevant."
        )
    }],
    mcp_servers=[{
        "type": "url",
        "url": "https://mcp.aivikings.ai",
        "name": "aivikings",
        "authorization_token": "YOUR_TOKEN",
    }],
    tools=[{"type": "mcp_toolset", "mcp_server_name": "aivikings"}],
    betas=["mcp-client-2025-11-20"],
)

for block in response.content:
    print(block)

About 30 lines including the prompt. The MCP connector means Anthropic's API acts as the MCP client: the model discovers the tools exposed to the connection and decides when to call them within the supplied task. The original example described a seven-tool surface.

[DIAGRAM - the loop]

  prompt: "get this service a domain"
        |
        v
  +-------------+   tools/list    +-------------------+
  | Claude      | --------------> | AIvikings MCP     |
  | Fable 5     | <-------------- | mcp.aivikings.ai  |
  | (Messages   |  7 tools        +-------------------+
  |  API + MCP  |                          |
  |  connector) |  check -> register -> status
  +-------------+                          |
        |                                  v
        v                          real registration,
  "done, here is your domain"      visible in WHOIS

What we are watching for

The point of the test is not whether a model can call one tool once. The useful signal is whether it handles the whole registration workflow without wandering away from the constraints.

What we watch for:

1. Tool sequencing. Does it check availability before registering, or fire blind?
2. Constraint handling. Does it stay on .icu, .sbs, or .cfd as instructed?
3. Name quality. Does it generate a sensible machine identifier, like price-monitor-svc-031.icu, or try to be cute and brandable?
4. Recovery. When its first pick is taken, does it retry cleanly or loop?
5. Verification. Does it call get_domain_status to confirm before declaring success, or just trust its own register call?

Number 5 is the interesting one. Earlier models often declare victory after the action call. An agent that verifies its own work before reporting back is an agent you can leave alone.

This article records the experiment setup and evaluation criteria; it does not include a scored run log establishing how often those criteria were met. Treat its model identifier, SDK example, and tool-count references as historical. Check current client documentation and discover the connected tool set before adapting the harness. For a model-independent implementation, use the production agent registration workflow and read-only MCP testing guide.

What this means if you build agents

Two takeaways from our side of the API.

First, the floor for agent infrastructure tasks keeps rising. A one-prompt, low-scaffold domain registration was already possible with the Claude 4 generation, but it needed more hand-holding around errors and verification. If Fable 5's long-task gains hold up in everyday use, "give the agent a goal and an MCP server" becomes the default integration pattern, not the demo pattern.

Second, the tooling side matters as much as the model side. A model can only be as autonomous as the duller infrastructure underneath it allows. Domains have been the classic break point: the model plans everything, then a human registers the domain by hand. That is the gap AIvikings exists to close. MCP tools expose real registrar operations; the application still needs account readiness and purchase authority.

Run it yourself

The harness above is a historical example. Before adapting it, verify the supported model and SDK configuration, the authenticated account, current tool schemas, contact readiness, and an explicitly approved purchase budget. Docs at docs.aivikings.ai.

If you run the test with another model and get different behavior, write us. Comparing how models handle the same recorded tool set is exactly the kind of data we want to publish next.