Fable 5 vs. GPT-5.6 Sol on an NP-Hard Problem: Does /goal help?

July 17, 2026 | ⏱️ 6 min read

TL;DR: I pitted Claude Fable 5 against GPT-5.6 Sol using an unpublished NP-hard optimization challenge. I tested them both in standard mode and their respective native /goal modes.

🌐 Context & Background

The challenge is an operations research problem originally designed for a student hackathon. Because I spent a week years ago developing a C++ solver for this specific problem, I have a reliable human-engineered baseline for comparison.

The Verdict: Fable 5 delivered the superior overall solution, exhibiting a level of consistency I haven't seen from any other model on this task. Furthermore, the results suggest that /goal is a universal "try harder" switch not a generic performance booster.

All trajectory notes, prompts, result tables, exclusions, and code are available in CLIArena. This serves as a sequel to my [initial article on this benchmark].

---

🏗️ The Problem: KIRO

KIRO is a fiber-optic network design problem from my 2018 engineering studies. The objective is to connect terminals and distribution points across distance matrices for Paris, Nice, and Grenoble.

Structural Constraints:

• Topology: The network must use redundant loops rooted at distribution hubs.
• Architecture: Short chains (branches) must hang from towers located on these loops.
• Uniqueness: Every single tower must be utilized exactly once.
• Asymmetry: Cable costs can vary depending on the direction of the segment.

The Complexity Gap

There is no simple closed-form equation to count possible solutions because the number of loops, their sizes, and the arrangement of branches are all variable.

To illustrate the scale, consider a simplified version: assigning 532 terminals to 11 hubs. That alone yields $11^{532}$ possibilities. A more concrete lower bound can be found by assuming exactly 19 loops of 28 terminals each (since $19 \times 28 = 532$ and $28 < 30$ limit):

$\text{Possibilities} \approx \frac{532!}{19!} \times 11^{19} \approx 10^{1223}$

---

🧪 Experimental Design

The scope of this test was intentionally tight to ensure a fair comparison.

Testing Checklist:

• Models: Claude Fable 5, Opus 4.8, Sonnet 5; GPT-5.6 Sol, Terra, Luna.
• Modes: Plain vs. native /goal.
• Time Budget: 30 minutes.
• Outer Agent Timeout: 1,900 seconds.
• Reasoning: Max settings enabled for all.
• Environment: Harbor 0.1.43, Docker, subscription auth.

---

📊 Results

I began with a single 30-minute "no-hint" run for every model in the sweep. I then performed three replicated runs for the flagship models (Fable 5 and Sol).

Raw Performance Table

(Note: Negative values indicate that /goal improved the score)

Statistical Summary

While /goal won 4 out of 6 trials, the means tell a more nuanced story:

Key Takeaways:

1. Fable 5 Dominance: Fable's plain mean beat Sol's by 1,875 points; its goal mean beat Sol's by 1,984.
2. Stability: Fable's plain results were incredibly tight (319-point range), whereas Sol's plain results swung by 1,958 points.
3. Peak vs. Safety: The absolute best score was Fable's /goal run (31,934), but Fable Plain was the most reliable configuration.

---

🔍 Deep Dive: The /goal Command

Although the command is the same, the underlying architectures of Claude Code and Codex are vastly different.

Implementation Comparison

• Claude Code: Uses a separate, smaller evaluator (Haiku) to monitor the transcript. It can stop the process early but cannot determine if more iterations would yield a better mathematical result.

  Reference: Anthropic's official goal documentation (Claude Code is closed source).

• Codex: Treats the goal as a persistent state in a database. The model has access to tools like get_goal and update_goal. If the thread idles, Codex injects a prompt to audit the objective.

The core difference: Claude's evaluator is an independent observer; Codex effectively allows the model to grade its own homework.

---

📉 Why /goal is a Risky Default

In standard coding, progress is linear (e.g., fixing a bug). In NP-hard optimization, the agent first chooses a strategy (a solver). Extra time provided by /goal simply amplifies that initial choice:

• Positive Amplification: If Fable built a fast compiled portfolio or Sol found a great chain repartition, /goal helped them refine it.
• Negative Amplification: If Fable built a slow solver or Sol started an exhaustive, fruitless anchor sweep, /goal just wasted time on a bad path.

Result: The median improved slightly, but the "bad tail" of the distribution became much worse.

---

⚠️ Limitations

• This is a general coding leaderboard a test on one specific NP-hard task.
• Sequential runs via subscription services may be subject to model drift.
• Hardware Bias: Containers provided 8 CPUs despite metadata claiming 1, which likely benefited Fable's parallel processing approach.
• All final outputs were valid, thanks to the wrapper's early checkpointing system.

Final Logic Summary

def evaluate_goal_mode(initial_strategy):
    if initial_strategy == "Efficient":
        return "Better Result" # Amplification of success
    elif initial_strategy == "Inefficient":
        return "Worse Result" # Amplification of failure
    else:
        return "Marginal Gain"