GLM-5.3 on iac-bench 2026-10

Every model evaluated on the 2026-10 fixtures side by side, with a sortable leaderboard, picks by use case and the cost of each: LLM rankings.

Summary

GLM-5.3 places tenth of 16 by composite (82.5), between Kimi K3 (83.4) and Qwen3.8 2.4T-A95B (81.6), and third of the five open-weight models. Its 95% rank interval of 3–15 is the second widest in the field, after Claude Haiku 5.5 (2–15). In the bootstrap it finishes ahead of Kimi K3 in 52% of resamples, ahead of Qwen3.8 in 57% and ahead of Kimi K3.1 Pro in 16%. At $8.46 for all 9 attempts it is the most expensive open-weight model, about twice Qwen3.8 ($4.40) and Kimi K3 ($3.96), and third overall after Claude Fable 5.2 and Claude Fable 5.1.

Three attempts reached the published 30-minute wall-clock limit: App Service (G003) e1 and e2, and Cloud SQL (G002) e3. They are scored as written, as is every attempt that reaches the limit. G003 e2 stopped before it had a module that plans and scores 0 mechanical (composite 22.1), which accounts for the wide interval. The other 8 attempts planned, with one security finding (G003 e1, H2). S3 (G001) and Cloud SQL medians are both 83.4, ninth and eleventh in the field. App Service has the lowest median (80.7, twelfth) and also the best attempt.

Scores

Rubric items not at full credit, counted over attempts that planned: G001: A5 3/3, B1 2/3, H12 3/3, H13 3/3, H15 2/3; G002: A8 2/3, B1 2/3, H3 1/3, H4 1/3, H7 1/3, H9 1/3, H10 2/3, H11 3/3; G003: A7 1/2, H2 1/2, 1 attempt failed the gate. Definitions are in Scoring criteria.

Strengths

• A full-credit App Service module. G003 e3 earns every rubric item (95.9), one of five such attempts in the field, with autoscale, WEBSITES_PORT, metric alerts and managed-identity image pulls (E1–E4). Kimi K3.1 Pro's best App Service attempt is 87.8.
• Posture fixed in code on S3 and Cloud SQL: no security findings in 6 of 6 attempts. Every Cloud SQL module hardcodes ipv4_enabled = false and ssl_mode = "ENCRYPTED_ONLY", where Kimi K3's validation admits unencrypted connections in 3/3.
• S3 baseline expertise (3/3): bucket-owner-enforced ownership, multipart cleanup, a TLS-deny policy, the regional domain output and a <name>-<account-id>-<region> name.
• IAM authentication locked on in 2/3 Cloud SQL attempts: the module sets cloudsql.iam_authentication and a validation rejects that key in database_flags.

Weaknesses

• Interfaces over budget: 11, 16 and 21 inputs on S3 against 8 (A5 lost 3/3); 29 and 32 on Cloud SQL against 25 (A8 partial, 2/3); 39 in G003 e1 against 20 (A7 at zero). Interface design 1 in 6 of 9 attempts.
• Basic-auth publishing left on in G003 e1 (security finding, H2): neither publishing flag is set, so both stay at the provider default. Kimi K3.1 Pro turns them off in 3/3.
• Cloud SQL lifecycle and credentials:
  • databases dropped on removal in 2/3 (H11);
  • passwords in state in 2/3 (H10): raw builtin_users passwords in e2 (H7), a generated postgres password in e3;
  • no connection logging (E8, 0/3), which Kimi K3.1 Pro has in 3/3.
• Documentation that misstates the provider or the module. Documentation 0 in 4 of 9 attempts (DeepSeek V4 Pro 6, Qwen3.8 5). Two Cloud SQL attempts say IAM authentication does not support Google Groups; G002 e2 presents IAM login as working but never sets the cloudsql.iam_authentication flag; G003 e2 says azurerm_service_plan has no zone-redundancy switch.
• Provider constraints that admit a new major in 4 of 8 planned attempts (B1), such as >= 5.0 on S3 (2/3) and >= 5.20.0, < 7.0.0 on Cloud SQL.
• IAM user errors the rubric does not see. G002 e2 passes IAM_USER where the provider expects CLOUD_IAM_USER; G002 e3 keeps the .gserviceaccount.com suffix in user names. The judge caught both (Internal logic 1).

Characteristic patterns

• Very long transcripts. Median 71,659, 108,600 and 124,719 output tokens per attempt, the most in the field on every fixture and two to three times Claude Fable 5.2. This volume runs three attempts into the time limit and drives the cost.
• Leftover scratch files in 4 of 9 attempts: a probe/main.tf creating hardcoded rg-probe resources (G003 e1, File layout 1), two empty probe files and an empty scratch_allocated_ip_range.tf.
• Settings derived from a concept. G002 e1 derives networking, availability and backup retention from environment; G003 e3 maps a tier input to SKU, zone capability and instance limit (excerpt below).

Representative excerpt

G003/glm-5.3-e3/locals.tf lines 33–49

  tiers = {
    small  = { sku = "S1", zone_capable = false, instance_limit = 10 }  # 1 vCPU / 1.75 GB
    medium = { sku = "P1v3", zone_capable = true, instance_limit = 30 } # 2 vCPU / 8 GB
    large  = { sku = "P2v3", zone_capable = true, instance_limit = 30 } # 4 vCPU / 16 GB
    xlarge = { sku = "P3v3", zone_capable = true, instance_limit = 30 } # 8 vCPU / 32 GB
  }
  tier = local.tiers[var.tier]

  # Zone spreading on by default wherever the SKU supports it. Premium v3 plans
  # are zone-redundant in zone-capable regions by platform default (the old
  # opt-in flag is gone from the API); zone_balancing_enabled keeps instances
  # evenly spread across the zones those tiers occupy.
  zone_spreading = coalesce(var.zone_redundant, local.tier.zone_capable)

  # A zone-redundant plan needs at least 3 instances to actually land in all
  # three zones, so the floor is raised rather than silently under-delivering.
  effective_min_instances = local.zone_spreading ? max(var.min_instances, 3) : var.min_instances

From the full-credit App Service attempt: a four-value tier input maps to SKU, zone capability and instance limit, and the instance floor rises to 3 when zones are in use. The judge marked the zone-spreading comment inaccurate, since zone_balancing_enabled is itself the plan's zone-redundancy setting.

Results · Methodology · Scoring criteria