DEV Community

PSBigBig
PSBigBig

Posted on

After the pricing debates: open-core vs zero-meter, and why I shipped a one-file reasoning layer

#webdev #ai #programming #beginners

After the pricing debates: open-core vs zero-meter, and why I shipped a one-file reasoning layer

Context
Recent conversations in the automation space resurfaced a familiar friction in open-core models. The code is public, the community contributes, then pricing lands where autonomy used to live. People accept paid features and support. They push back when the meter sits between them and their own infrastructure.

My position
I built the opposite kind of thing. WFGY ships as a tiny PDF or TXT. You attach it to GPT or Claude and you are done. There is no server, no account, no feature gate, no per-execution counter. It is MIT. If you wanted to pay me, you could not. That constraint is deliberate. It removes the meter entirely.

Side-by-side for engineers

Dimension Common open-core pattern WFGY approach
Artifact Server app plus gated enterprise features A single PDF or TXT file
License OSS core with commercial tiers MIT end to end
Billing surface Seats and advanced features, sometimes usage on self-host None. Text cannot be metered in practice
Lock-in vectors Dashboards, hosted features, support channels Zero. No account, no telemetry, no API dependency
Time to first result Deploy, secure, scale About 60 seconds in a fresh chat
Failure handling Product specific Problem Map with 16 reproducible failure modes and fixes
Who pays for heavy use You pay infra and possibly usage counters You only pay the LLM you already use
Reproducibility Varies by tier and environment Same file for everyone which makes results easy to verify

This is not a value judgment on any project. It is a design choice about where the meter lives.

What WFGY actually is

A math-based reasoning overlay for LLMs packaged as a tiny document. The document encodes operators for stability, constraint keeping, multi-path progression, collapse and recovery, and attention damping. It does not replace your model. It shapes it.

Reproduce in about 60 seconds

  1. Open a fresh GPT or Claude chat
  2. Upload the MIT PDF: https://doi.org/10.5281/zenodo.15630969
  3. Paste this prompt: 
Instruction: You are in exploration mode. The attached PDF supplies formal operators (ΔS, λ_observe, E_resonance, BBMC/BBPF/BBCR/BBAM). Do not merely analyze or summarize the PDF. Execute its math and procedures on the task.

Q1: Answer normally first. Then, re-answer using WFGY’s logic. Report both, and rate Depth, Accuracy, and Understanding for each.

NOTE: If this chat does not contain the WFGY PDF and formulas, refuse to run “using WFGY” to avoid a hallucinated imitation.
Enter fullscreen mode Exit fullscreen mode

What you will usually observe
Tighter chains, fewer detours, stronger constraint keeping, and an explicit bridge then recovery when the chain stalls.

Evidence and receipts

I am especially interested in counterexamples. If WFGY does not help on your case, share a short trace and I will map it to the right fix or say it is out of scope.

Why I chose a zero-meter artifact

  • Trust. If the instrument is a file, there is nothing to revoke or throttle
  • Reproducibility. The same artifact across teams makes comparisons honest
  • Alignment. I only win if the math helps you. If it does not help, you close the tab. No sunk-cost traps

Notes on the broader debate

Open source is not only a license. It is also the placement of constraints. When the constraint lives at the billing surface on self-host, engineers feel it immediately. When the constraint is removed and the artifact is plain text, users keep power regardless of my future choices. That is the point.

License and privacy
MIT. No registration. No tracking. No ads. No analytics.

If this saves you time, a GitHub star helps others find it. If not, no worries.

Top comments (0)