Leaderboard

I use VSCode and have been a subscriber to GitHub Copilot for a few years. I didn't pay much attention to the plan I was on until I started using agentic coding in ~October 2025. I then realized what made GitHub Copilot a ridiculously good value, as others discovered as well, was that it works on a "per-request" billing model. In short, if you knew what you were doing (I didn't realize this fully at the time), you could use a high-end model like Opus 4.5, which costs 3 credits, and if just have it rip for HOURS on a task and it would only cost 3 requests (lower end models would be 1 request). With the cheapest plan on GitHub Copilot, it is (well, now WAS), $10/month which gave you 300 requests. A lot of people took advantage of this... imagine paying $10/month and getting like $5000/$10,000 worth of value (ie, what would be the real cost of per-token billing) out of it per month! Absolutely insane. Microsoft understandably put an end to that last week because they were losing their shirts: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/ In short, they are one of the first to go per-token/per-usage billing and I suspect others like Anthropic and OpenAI will eventually follow suit. It's only a matter of time given the economics of it all. However as you may know, the Chinese AI labs are extremely competitive with their AI offerings and have both monthly plans and token-based plans (generally 90% less cost) and of course, they release the models outright. Because of what Microsoft did, I've been experimenting with the various Chinese models via OpenRouter (and still using VSCode GitHub Copilot "Bring Your Own Key" which they support), so it's basically the same experience. However there seems to be a lot of advancements in high density, low parameter models (Qwen3.6 27B, Deepseek V4 Flash) which can be run on consumer hardware at good speeds and output that is not far behind something like Sonnet or Opus, or at least catching up quickly. I haven't owned a discreet GPU in many many years (I don't game), but I believe with a RTX 5090 and 64-128GB of RAM, it can be done. Don't quote me on any that however... I haven't dived into this world yet and don't yet have an understanding of all the settings that determine how well an LLM runs and how it affects its intelligence. I'd be interested to hear anyone who is playing with this idea: What models are you using? What hardware? What software are you using to run it?

Hi everyone, I made a small fieldtype module for storing product dimensions: https://github.com/mxmsmnv/FieldtypeDimensions FieldtypeDimensions lets you store length, width, height and optionally weight in a single field. It’s mainly useful for product/catalog/e-commerce pages where dimensions are needed for display, shipping or filtering. Supports different units (mm, cm, m, in, etc. for length and g, kg, lb, etc. for weight) and stores values internally in mm/grams. The module also supports multilingual setups — admin field labels are available in 20+ languages and can be configured globally. Basic usage example: $dim = $page->dimensions; echo $dim; // 120 × 80 × 50 mm, 1.5 kg echo $dim->lengthIn('cm'); echo $dim->weightIn('kg'); Selectors: $pages->find("template=product, dimensions.length>100"); $pages->find("template=product, dimensions.weight>500"); More details in the README. Feedback and suggestions are very welcome.

Thanks Adrian! Since you're in Canada — if you ever deal with cross-border shipments to the US or Europe, the unit conversion comes in handy. Canadians get the best of both worlds — metric by default but imperial just across the border. 😄

Hi @adrian, great question — happy to clarify. Both modules store L×W×H, but the focus is different: FieldtypeObjectDimensions (juergen) — geometry-oriented: auto-calculates and stores area and volume, useful when you need spatial calculations. FieldtypeDimensions (mine) — shipping/e-commerce-oriented. The reason it exists: I've been building a package forwarding platform (think Qwintry-style — customers ship packages to a US warehouse, we consolidate and forward internationally). That platform, AltaPost, never launched at scale, but the logistics logic stuck with me. When I needed a dimensions field for product catalogs in ProcessWire, the obvious missing piece was weight — you can't quote a shipping rate without it. A lot of our shipments went to Europe, so we constantly needed to show the same package in both metric and imperial at once — 120 × 80 × 50 mm / 4.7 × 3.1 × 1.9 in, 1.5 kg / 3.3 lb. That's why the conversion API exists: no manual math in templates. Main differences: Weight field — fourth subfield alongside L×W×H, optional per-field Unit conversion API — $dim->lengthIn('in'), $dim->weightIn('lb') for passing values directly to shipping APIs (GoShippo, EasyPost, FedEx rates) or displaying both metric and imperial simultaneously Normalized storage — always saves in mm/grams internally; changing display unit never requires data migration 28 admin languages — useful when ProcessWire itself is configured with multiple languages and you want field labels to appear natively for each editor If you need area/volume stored and searchable — @Juergen module is the better fit. If you need weight + unit conversion for shipping integrations — this one covers that case.

I was experimenting with Ollama using its cloud models the other day, on its $20/month plan. I had good results. For my next project, I am considering using Kimi-K2.6, GLM 5+, and others. You can use Opencode or Claude for it: `ollama launch claude --model minimax-m2.5:cloud`

When setting $config->advanced = true you can specify in a specific template whether you want the name field to appear in the content tab. Is it maybe your case?

ProcessTranslatePage 1.5 + 1.6 Two new versions released — improved glossary handling and a second translation provider. 1.5 — Better glossary management The module now detects free DeepL accounts (limited to one glossary) and warns instead of showing an error. Existing glossaries on your account are shown as a dropdown so you can select one manually, and there's a new "Delete glossary" option in the settings that removes it from DeepL while keeping the entries in the language fields. 1.6 — Added Google Cloud Translation option My main motivation here was that I just discovered DeepL has discontinued new free API plans, so Google Cloud Translation is now available as an alternative. Both providers support the same field types and write modes. Setup for Google requires a GCP service account; the full steps are in the readme. Glossary support remains DeepL-only for now, as Google's glossaries require a Cloud Storage bucket which seemed a little bit too much effort for the effect. Locale codes (DE, de, EN-GB, en_gb …) are normalised automatically on runtime now, so the format in the language fields doesn't matter anymore.

Hi everyone, A small but practical module — manage your robots.txt directly from the ProcessWire admin, no FTP or SSH needed. GitHub: https://github.com/mxmsmnv/RobotsTxt What it does: Visual editor under Setup → Robots.txt with dark theme and monospace font Two-column layout — preset sidebar on the left, editor on the right 10 built-in rule presets — click any card to append rules to the editor: Allow all / Block all crawlers Hide admin panel (/processwire/) Block uploaded file assets Block AI training bots (GPTBot, CCBot, anthropic-ai, Google-Extended, FacebookBot, Omgilibot) Sitemap reference, Crawl-delay, Block query strings, Google only, Bing only Rules overview — parses the file after saving and renders a human-readable table with color-coded Allow/Disallow/Crawl-delay badges Status bar with file path, size, and last-modified date File locking (LOCK_EX) on write, CSRF protection, role-based access via robots-manager permission Automatic path detection via $config->paths->root Requirements: ProcessWire 3.0.200+, PHP 8.2+ Screenshot: MIT License.