DEV Community: Meso Francis

Go Now Reads Your Container's CPU Limit. It Still Can't Read Your Memory Limit.

Meso Francis — Tue, 13 Oct 2026 14:36:48 +0000

If you run Go on Kubernetes, there's a good chance two things have bitten you without leaving a single error in your logs: latency spikes you can't explain, and pods that die with OOMKilled while your heap graphs looked fine.

Those are two different problems with two different fixes. Recent Go versions quietly solved one of them. The other is still your job.

One quick correction before we start, because I've seen it repeated in a few places: container-aware GOMAXPROCS didn't arrive in a late patch release. It shipped in Go 1.25, and everything newer (1.26, 1.27.x) inherits it. What matters in practice is not just which toolchain you build with, but what your go.mod says. More on that trap in a minute.

The problem: Go counted the node, not your pod

Say your pod has limits.cpu: "2" and lands on a 32-core node. Before Go 1.25, the runtime asked the OS how many CPUs exist, got 32, and set GOMAXPROCS=32. So you had a scheduler happily running up to 32 threads of Go code in parallel, inside a container that was only paid for 2 CPUs' worth of time.

Linux enforces CPU limits with CFS bandwidth control. Your limit becomes a quota: for cpu: 2, that's 200 ms of CPU time per 100 ms period. Thirty-two busy threads can burn that 200 ms in about 6 ms of wall-clock time. After that the kernel does the blunt thing: it pauses the whole container until the next period starts.

From the outside this looks like random tail latency. No panic, no error, no log line. Your p50 is great and your p99 is haunted.

What Go 1.25 changed

The runtime now reads the cgroup CPU quota at startup and sets the default GOMAXPROCS to the lower of the machine's CPU count and your container's CPU limit. A few details worth knowing, because they're where people get surprised:

It reads the limit, not the request. requests.cpu is just a scheduling hint and a weight under contention. Go ignores it.
Fractions round up. A limit of 0.5 gives you GOMAXPROCS=1, and 2.5 gives you 3.
It keeps watching. The runtime re-checks the limit about once a second, so if something resizes your pod's CPU limit in place, GOMAXPROCS follows without a restart.
Any manual setting wins. If the GOMAXPROCS env var is set, or your code calls runtime.GOMAXPROCS(n), the automatic behavior steps aside.
No limit, no change. With no CPU limit set, you get the usual NumCPU default.

If you were pulling in go.uber.org/automaxprocs for this, you can most likely delete it.

The `go.mod` trap

This is the one I'd put in a code review checklist. Go gates new runtime behavior behind the language version in go.mod. If your module still says:

go 1.24

then building with a shiny new toolchain does not turn this on. The documented defaults for containermaxprocs and updatemaxprocs are the old behavior for language versions 1.24 and below. Bump the go line to 1.25 or later, or set the GODEBUG settings explicitly.

And if you ever need the old behavior back, you have the escape hatches:

GODEBUG=containermaxprocs=0   # ignore the cgroup limit at startup
GODEBUG=updatemaxprocs=0      # don't re-check the limit periodically

What it doesn't fix

Don't over-credit it. GOMAXPROCS limits how many threads run Go code in parallel. It doesn't cap everything your process does with CPU. Cgo calls, threads blocked in syscalls, and background work still draw from the same quota. And GOMAXPROCS equal to your limit is a good default, not a guarantee of zero throttling: a bursty service can still hit the quota inside a single period.

So measure. The number I'd put on a dashboard is the throttled-period ratio:

sum(rate(container_cpu_cfs_throttled_periods_total{container="my-service"}[5m]))
/
sum(rate(container_cpu_cfs_periods_total{container="my-service"}[5m]))

If that sits near zero, you're fine. If it's climbing under load, either the limit is too tight for the work or something other than Go code is eating your quota.

Now the part Go did not fix: memory

Here's the asymmetry that trips people up. Go learned to read the CPU limit. It did not learn to read the memory limit.

GOMEMLIMIT defaults to effectively unlimited. The Go runtime documentation still describes the default as math.MaxInt64, which disables the limit, and the 1.27 docs say the same. So your garbage collector paces itself against heap growth (that's GOGC's job), with no idea that a cgroup wall stands at 512 MiB.

The result is the classic story: under load the heap grows, nothing tells the GC to work harder, the container crosses its limit, and the kernel's OOM killer ends the process. No Go panic. Just exit code 137 and OOMKilled in kubectl describe pod.

GOMEMLIMIT is a soft limit. As the runtime approaches it, the GC runs more aggressively and the runtime gets more eager to return memory to the OS. It's a pressure valve, not a wall. Two honest caveats:

It covers memory the Go runtime manages (heap, stacks, runtime structures). It excludes things like cgo allocations and the binary's own mappings, but those still count toward the container limit. That's why you set it below the limit rather than at it.
If your live data genuinely exceeds the limit, no setting helps. The GC will work harder and harder and you'll just trade an OOM kill for a slow, GC-bound death. The fix there is a bigger limit or less memory.

How to set it

The rule of thumb I follow: GOMEMLIMIT at roughly 85 to 90 percent of the container memory limit, leaving headroom for everything the runtime doesn't track.

The simplest option is to be explicit and keep the two numbers next to each other in your manifest:

resources:
  requests:
    cpu: "1"
    memory: 512Mi
  limits:
    cpu: "2"
    memory: 512Mi
env:
  - name: GOMEMLIMIT
    value: "460MiB"   # ~90% of the 512Mi limit

You might be tempted to use the Kubernetes downward API (resourceFieldRef: limits.memory) so the value follows the limit automatically. It gives you the raw limit, though, and there's no way to multiply it by 0.9 there. Setting GOMEMLIMIT equal to the limit leaves the GC no room to act before the kernel does.

If you want it derived automatically, a small library handles the ratio and cgroup v1/v2 for you:

import _ "github.com/KimMachineGun/automemlimit" // sets GOMEMLIMIT from the cgroup limit, 90% by default

(It's a no-op if GOMEMLIMIT is already set. AUTOMEMLIMIT adjusts the ratio.) Either approach is fine. Pick one and be consistent, because the failure mode of forgetting is silent.

A 10-line sanity check

Don't trust configuration you haven't observed. Log this at startup and look at it in a real pod:

import (
    "log"
    "runtime"
    "runtime/debug"
)

func logRuntimeLimits() {
    log.Printf("NumCPU=%d GOMAXPROCS=%d GOMEMLIMIT=%d",
        runtime.NumCPU(),
        runtime.GOMAXPROCS(0),
        debug.SetMemoryLimit(-1), // negative = just report the current limit
    )
}

Healthy output in a pod limited to 2 CPUs on a big node: GOMAXPROCS=2 while NumCPU shows the node's count, and a GOMEMLIMIT that's a real number rather than 9223372036854775807. If you see that giant number, your memory limit isn't set and the GC is flying blind.

My checklist

Set the go line in go.mod to 1.25 or later, so container-aware GOMAXPROCS actually turns on.
Set a CPU limit on latency-sensitive services. Go can only match a limit that exists. (Whether every workload should have one is a long-running Kubernetes debate. For Go services where tail latency matters, I'd rather have a predictable limit than none.)
Set GOMEMLIMIT to about 90% of the memory limit, explicitly or via a library.
Set memory requests equal to limits, so memory is never over-committed on the node.
Alert on the throttled-period ratio and on OOMKilled restarts, not just on CPU and heap graphs.
Log GOMAXPROCS and the memory limit at startup so the config is visible in every environment.

The short version

Go 1.25 closed a decade-old gap: your scheduler now sizes itself to the CPU you were actually given. That removes a whole class of mysterious tail latency. Memory is the one the runtime still leaves to you, and it costs one environment variable to fix. Set it, check it, and spend your debugging time on something more interesting than exit code 137.

If you've seen different behavior on your own clusters, especially around throttling after the upgrade, I'd like to hear about it in the comments.

Your Game Engine Isn't Dead: What Decart's Oasis Actually Proved

Meso Francis — Mon, 21 Sep 2026 12:46:55 +0000

AI-generated games run at playable framerates. But 'no physics engine' is the wrong takeaway. Here's what neural rendering really changes for developers.

In October 2024, Decart and Etched released Oasis, a Minecraft-like game with a striking claim: there is no physics engine, just a foundation model. You press WASD, and a network generates the next frame.

The headline takeaway was "engines are obsolete." I think that's the wrong lesson. The right one is stranger and more useful.

What is actually happening

Oasis does next-frame prediction. It anticipates the next frame from keyboard and mouse input, trained on millions of hours of gameplay footage. Both parts are Transformer-based: a ViT autoencoder and a DiT backbone.

Nothing in there simulates gravity. The network has learned what usually happens next when a player jumps or breaks a block. That is statistical imitation of physics, not physics.

Engine pipeline vs neural world model loop

The 2024 reality check

Early reviews were harsh. Critics noted 360p resolution, about 20 FPS, and heavy hallucination: digging could teleport you to the surface. Objects didn't persist, and builds couldn't be saved. Decart itself said the tech was still in early development.

That's the core weakness. With no explicit state, there is nothing to save, load, diff or debug.

The field moved fast

Google's Genie 3 generates navigable worlds at 24 FPS and 720p, staying consistent for a few minutes. The catch: visual memory reaches back only about a minute.
Oasis 2.0 shifted toward transforming game worlds and styles in real time at 1080p, 30fps. That is closer to a neural skin over an existing game than a replacement for one.
Oasis 3 dropped the "AI game" pitch. It is now an interactive world model for physical AI, with an API, action-conditioned training and multi-camera output for robotics. Latency is under 200 ms at 22 FPS. The pattern is that the money moved from "replace the engine" to "simulate worlds where engines are too expensive to author": robotics, autonomy, training environments.

Engine vs world model

	Traditional engine	Neural world model
State	Explicit, inspectable	Implicit, in the frame context
Determinism	Yes	No
Persistence	Save/load is trivial	Unsolved past minutes
Authoring	Code and assets	Data and prompts
Edge cases	You write them	You hope they appear in training data
Cost per frame	Cheap	Datacenter GPUs

Where I think this lands

Hybrid pipelines. The engine owns state and rules. The neural layer owns look and feel (restyling, lighting, upscaling).
Simulation, not shipping games. Where correctness is approximate and diversity matters, generated worlds win.
Persistence research. Long-horizon consistency remains unsolved, and implicit frame-by-frame models are brittle over extended play. Whoever fixes this changes the whole picture.

Try it yourself

Oasis published model weights on Hugging Face and code on GitHub. Run it, dig a hole, look away and look back. You'll learn more about implicit state in five minutes than from any launch post.

Takeaway

Neural rendering isn't deleting the physics engine. It's showing us a second way to represent a world: explicit and exact, or implicit and approximate. The interesting engineering is in combining them.

Grok 4.6 available now on Gemini Enterprise Agent Platform

Meso Francis — Thu, 27 Aug 2026 01:10:02 +0000

SpaceXAI’s Grok 4.6 is now available in Public Preview as a fully managed model in Model Garden on Gemini Enterprise Agent Platform. You can learn more on the model card on Model Garden.

Why Grok 4.6
Grok 4.6 is SpaceXAI’s most capable model, released in August 12, 2026. From SpaceXAI:

Grok 4.6 builds on Grok 4.5 with a particular focus on long-running agents and more ambitious interactive and visual work. It stays with complex tasks across many steps, whether researching a topic, analyzing information, working across a codebase, or turning an idea into a polished application or work artifac

What the managed endpoint gives you
Serverless: No provisioning, no scaling policies, no patching. Pay only for the tokens you use, at the same rates offered by SpaceXAI.

Two OpenAI-compatible surfaces: Chat Completions for standard requests, and the Responses API for agentic loops that need server-side state.

Enterprise Readiness: One project, one bill, and one IAM policy under one roof. Partners can not access data sent through our endpoint.

Get started
Enable the model on its Model Garden card, then call it through the OpenAI-compatible Chat Completions API. Here is a complete request against the global endpoint:

curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/endpoints/openapi/chat/completions \
-d '{
"model": "xai/grok-4.6",
"messages": [
{
"role": "user",
"content": "Who are you?"
}
]
}'
Preview details
Grok 4.6 is offered at the Preview launch stage, on the global endpoint. Function calling, structured output, and reasoning are supported; reasoning_effort is not, so the model runs at its default effort. Provisioned Throughput and batch inference are not available for this model at launch.

Quota is fixed rather than dynamic. Each project starts at 13 QPM, 188,000 input TPM, and 16,000 output TPM on the global endpoint, and increases are available on request.

Pricing matches SpaceXAI’s direct rates and tiers on context length: $2.00 per million input tokens and $6.00 per million output tokens up to 200K tokens of context, doubling to $4.00 and $12.00 above it. Cached input is $0.50 per million, or $1.00 past the 200K mark.

What’s next

How I Organize and Ship Small Open‑Source Projects

Meso Francis — Wed, 19 Aug 2026 13:36:37 +0000

Practical habits, repo structure, and workflows that keep small projects healthy and approachable

Why small projects succeed (and why many don’t) Every open‑source project starts with an idea. What separates projects that quietly rot from those that attract contributors and users isn’t always technical sophistication — it’s clarity. Clear goals, a consistent structure, minimal friction for contributors, and reliable automation make it easy for people (including future-you) to understand, use, and improve your work.

In this post I’ll share a practical, opinionated workflow I use for small projects: how I design the repository, automate tests and releases, write docs, and manage issues and contributions. These are the same habits that help me keep projects shipping and lower the cost of maintenance.

Goals I optimize for

Fast time-to-first-success: a visitor should be able to clone, run, and see something work in under 5 minutes.
Low cognitive overhead: a clear layout and a short README so folks know what the project does quickly.
Safe automation: CI catches obvious problems and automates releases so manual steps are minimized.
Contributor friendliness: clear CONTRIBUTING.md and issues that are starter-friendly.

Repository layout (one page of truth) A consistent layout reduces friction. Here’s a minimal, language-agnostic structure I use:
Text

README.md
LICENSE
CHANGELOG.md
CONTRIBUTING.md
CODE_OF_CONDUCT.md
/.github
/workflows
ci.yml
release.yml
src/
(project source)
tests/
(unit / integration tests)
examples/
(small runnable examples)
docs/
(long-form docs if needed)
package.json / pyproject.toml / Cargo.toml (as applicable)

Key files explained

README.md: the single place a new visitor will read. Include: 1-sentence summary, badges (CI, coverage), install/run example, links to docs and contributing.
CONTRIBUTING.md: step-by-step for opening issues, running tests, and submitting PRs.
CHANGELOG.md: keep a short changelog using conventional commits or a manual summary.
.github/workflows: CI and release automation.

Make README work for newcomers Top-of-README should answer the three most important questions:

What does it do? (one sentence)
Who is it for? (one sentence)
How do I get started? (one quick example)

Example intro snippet:
Markdown

TinyWidget

TinyWidget is a small library that converts CSV to JSON in streaming fashion.

Run: npx tinywidget input.csv > out.json (or python -m tinywidget input.csv).

Automate the boring stuff: CI, formatting, and tests Set up CI early. My baseline includes:

Linting and formatting check (fail fast)
Unit tests on PRs
A smoke test on main (quick integration check)
Automated releases on tagged commits (optional)

A minimal GitHub Actions CI flow:

Trigger on pull_request and push to main
Steps: checkout → install deps → run format/lint → run tests

This reduces subjective feedback in reviews and keeps the main branch reliable.

Make it easy to try (examples and scripts) Nothing beats a short example that demonstrates value. Add an examples/ folder with runnable code and a small README that explains what each example shows.

Also include simple convenience scripts in package.json / Makefile:

make test
make lint
make run-example

Document the mental model, not every line Good docs explain the mental model: what the system is, its main components, and how the pieces interact. Keep API reference in a separate area (docs/ or generated docs); README should be about value and quick start.

Be deliberate about issues and labels An issue tracker is both roadmap and to-do list. Keep issue types clear:

good-first-issue: small entry-level tasks
bug: reproducible problems
enhancement: feature requests
question: usage questions

Write at least one good-first-issue when you publish — it invites people to contribute.

Release strategy: keep releases frequent and predictable For small projects I prefer semantic versioning and frequent releases for visible progress. Automate releases with:

a release workflow that runs on tag push or merges to main
generate changelog entries from PR summaries or conventional commits
attach binaries/artifacts when relevant

This reduces the “stalls” that happen when release tasks pile up.

Maintainability: tests and dependency hygiene

Keep a test suite that runs quickly; fast tests make CI practical.
Use dependabot or a scheduled job to update dependencies.
Pin CI environment versions to avoid surprises.

Code review and PR etiquette

Limit PR size. Small, focused PRs are reviewed and merged faster.
Describe the “why”, not just the “what”.
Prefer descriptive commit messages and squash when merging if history will get noisy.

Community: be friendly and consistent

Add a brief Code of Conduct.
Acknowledge contributors in the changelog or release notes.
Be explicit about how you triage issues (labels, stale bot policy).

Example README snippet (Quickstart)
Markdown

Quickstart

Clone: git clone https://github.com/yourname/project.git
Install: npm install
Run: npm start

Measuring success (simple signals)

Stars and forks are vanity metrics — watch for: PRs from others, issues filed by users, people using examples, or real-world forks and badges in other projects.
If you get repeat questions, add docs or an FAQ to prevent duplicate issues.

Common pitfalls and how to avoid them

Overengineering: ship the smallest solution that solves a real problem.
No examples: users won’t take the time to build one.
No automation: manual releases, tests, and checks create friction that kills momentum.

Final checklist before publishing a repo

README: 1-sentence description + quickstart
CONTRIBUTING.md and CODE_OF_CONDUCT.md present
CI: lint + tests
At least one example that runs locally
At least one good-first-issue

Wrap-up Small projects win when they’re easy to understand and easy to contribute to. Use clear structure, reliable automation, and a small set of human-friendly documents to lower the activation energy for users and contributors.