DEV Community: Methodox Technologies, Inc.

DevLog 20260426: Divooka Mandelbrot Benchmark – Putting Our Scripting Language to the Test

Charles Zhang — Mon, 27 Apr 2026 03:31:48 +0000

Today we released the first public version of DivookaBenchmark_Mandelbrot — a standardized benchmark suite built specifically to measure the real-world performance of Divooka against a wide range of languages and runtimes.

The benchmark computes the Mandelbrot set at 2000 × 2000 resolution with a maximum of 1000 iterations per pixel, then verifies correctness using a 32-bit checksum (target: 689833081). We run each implementation five times and record average time, min/max, peak memory, and distribution size.

Why This Benchmark Matters

One of our core beliefs is that a modern scripting language needs a "decent (high) performance". This benchmark was designed to prove that point in a reproducible way.

It exercises heavy integer and floating-point math, tight loops, branches, and memory writes — exactly the kind of workload where interpretation overhead shows up quickly. This particular benchmark doesn't test function calls directly.

The goal is not to produce the an optimized Mandelbrot renderer, but to compare a simple, fixed algorithm across different languages and runtimes, then use the result to understand where Divooka currently stands.

We included implementations (or equivalent ports) for:

C++
C# (.NET 10, including AoT/trimmed)
JavaScript (multiple browsers + Node.js)
Go, Java, Julia, Python 3.13, Ruby, Prolog, GNU Octave
And of course, multiple execution modes of Divooka 0.75.2 (compiled, Aviator, Neo Editor, Stewer)

We even tested AI-generated versions from ChatGPT, Gemini, Grok, and Kimi to see how reliable and performant LLM-produced result is in practice.

Key Results (on Windows 11, i7-13700KF)

Fastest overall: JavaScript in Edge/Chrome/Brave (~1,296 ms, very low memory)😲
Fastest native: C++ (~1,308 ms)👍
Strong managed contender: C# AoT (~1,355 ms)
Divooka compiled: 3,639 ms — comfortably beating pure interpreters like Python (~47 s) and Ruby (~49 s) ⚡
Divooka Aviator: 6,711 ms 🥰
Divooka Neo Editor: significantly higher overhead (estimated multi-hour range for full runs) 🥹

The gap between Divooka's compiled mode and the top-tier JITs (especially V8) is still noticeable, but the improvement over classic interpreted scripting languages is clear. This reinforces why we’ve been investing heavily in our compilation pipeline and runtime optimizations.

AI-generated implementations varied wildly — some produced correct checksums but took 26 seconds to several minutes, while others failed entirely or fell back to calling Python under the hood. Deterministic engineering still wins.

What We Learned

JIT is not optional for competitive scripting performance.
Tooling and editor overhead can dominate if not carefully managed (something we're actively addressing).
Even simple, well-defined tasks like Mandelbrot reveal meaningful differences in language/runtime design.

The full repository is now public:

https://github.com/MethodoxTech/DivookaBenchmark_Mandelbrot

It includes all source implementations, PowerShell automation scripts, result tables, and artifacts. Feel free to clone, run it yourself, or contribute additional language ports.

This benchmark will become part of our regular performance regression suite as Divooka evolves. Future runs should show steady gains as we refine the compiler and reduce runtime overhead.

Current Results

Results from best runs of respective platform:

Rank	Language / Runtime	Size	Best Time
1	JavaScript Web, Edge / Chrome / Brave	3 KB	1295.80–1302.80 ms
2	C++	15 KB	1308.00 ms
3	C# AoT	911 KB	1355.35 ms
4	C# .NET 10	16.5 MB	1357.47 ms
5	JavaScript Node.js	2 KB + 98.2 MB	1406.20 ms
6	Go	2 KB + 224 MB	1425.01 ms
7	Julia	2 KB + 1 GB	1511.20 ms
8	JavaScript Web, Firefox	3 KB	1513.00 ms
9	Java OpenJDK 17.0.11	301 MB + small files	1587.79 ms
10	Divooka 0.75.2, Compiled	71.914 MB	3639.24 ms
11	Divooka 0.75.2, Aviator Run	8 KB + 2.16 GB + 776 MB	6710.84 ms
12	Python 3.13.5	2 KB + 139 MB	47127.70 ms
13	Ruby 3.2.2	1 KB + 907 MB	49489.82 ms
14	Prolog SWI, optimized	2 KB + 42.8 MB	314687.84 ms
15	GNU Octave 7.3.0	2 KB + 2.07 GB	2464913.29 ms
16	Divooka 0.75.2, Neo Editor estimate	8 KB + 2.67 GB	~95.8 hr

Limitations

This benchmark only tests a narrow case.

It does not test UI programming, data manipulation, graph execution, external libraries, async workloads, recursion-heavy workloads, or large real-world applications.

It also does not fully normalize warm-up behavior. Browser JavaScript likely benefits from highly optimized JIT behavior, and other runtimes may have different startup / warm-up costs.

GNU Octave is probably optimized for matrix-oriented workloads, not naive scalar loops.

Python is rarely used this way in performance-sensitive numerical code; normally people use NumPy, Numba, Cython, PyPy, or native extensions.

English is The Worst Programming Language

Charles Zhang — Sun, 26 Apr 2026 03:47:34 +0000

In the world of software engineering, we obsess over programming languages: their syntax, their type systems, their performance characteristics, their paradigms. We debate Rust versus Go, Python's readability versus C++'s control, Haskell's purity versus JavaScript's chaos. Yet we rarely acknowledge the elephant in the room — or rather, the language we all use every day that makes every other language look like a model of crystalline precision: English.

English is, without question, the worst programming language ever created. It is not merely flawed; it is fundamentally unsuited for the reliable transmission of complex ideas. Anyone who has ever tried to communicate a non-trivial technical concept to another human being knows this instinctively. The ambiguities, the contextual dependencies, the endless opportunities for misinterpretation — English excels at all of them.

If you have spent any time in meetings, code reviews, specification documents, or even casual Slack threads, you have felt the pain. And if you have any background in mathematics, physics, or formal logic, the contrast becomes almost comically stark.

Precision: The Foundation of Reliable Computation (and Communication)

At its core, a good programming language is a formal system designed for unambiguous execution. Every valid program has exactly one meaning under the language's semantics. A compiler or interpreter will produce the same behavior every time, assuming the same inputs and environment. This is not an accident; it is the entire point.

Mathematics and physics adopted formal languages for the same reason. When Newton or Leibniz developed calculus, they didn't just wave their hands and say "the rate of change, you know, kinda like speed but for curves." They created notation — symbols, rules of manipulation, axioms — that allowed precise statements like:

This expression has one, and only one, interpretation among those who understand the formal system. There is no room for "well, depending on what you mean by derivative" or "in my experience, sometimes it's 2x plus or minus a bit."

Physics follows suit. Maxwell's equations in differential form are not poetic suggestions:

These are not open to "opinions-based" interpretation. Misunderstand a sign or a vector component, and your electromagnetic device will quite literally fail to function. Engineers and physicists spend years learning to think within these formalisms precisely because natural language is too sloppy for the phenomena they describe.

Formal languages exist because human natural languages are terrible at edge cases, scope, and unintended interpretations. We invented predicate logic, set theory, lambda calculus, and programming languages to escape the swamp of ambiguity.

English, by contrast, is the swamp.

The Many Ways English Fails as a Specification Language

Consider something as seemingly simple as a requirement: "The system shall process transactions quickly."

What does "quickly" mean? Under 100ms? Under 500ms? Does it depend on load? On hardware? On network conditions? Is this a hard guarantee or a soft target? English offers no mechanism to distinguish these.

Now imagine trying to implement a sorting algorithm based on an English description:

"Sort the list in ascending order, but put the most important items first, unless they're duplicates, in which case keep the original order for those."

Good luck. Is "important" defined? What constitutes a duplicate? Does "original order" refer to stable sort semantics? English leaves all of this to intuition, shared context, and — inevitably — arguments in code review.

Real-world examples abound in software projects:

"Handle errors gracefully" — Does this mean log them? Retry? Notify the user? Crash the process? Return a default value?
"Make the UI intuitive" — Intuitive to whom? A power user? A complete novice? Someone from a different cultural background?
"The cache should be consistent" — Eventual consistency? Strong consistency? What about partition tolerance?

These are not edge cases. They are the norm. Experienced engineers learn to translate vague English requirements into precise specifications, often using formal tools (user stories with acceptance criteria, UML, TLA+, property-based testing) precisely because English alone is insufficient.

Ambiguity at Every Level

English is ambiguous at the lexical, syntactic, semantic, and pragmatic levels.

Lexical ambiguity (multiple meanings for the same word): "Bank" can mean a financial institution, the side of a river, or to rely on something. Context usually helps, but in technical documents, context can itself be contested.

Syntactic ambiguity (parsing issues): Classic example — "I saw the man with the telescope." Did I use the telescope to see the man, or did the man have the telescope? Programming languages avoid this with strict grammar rules and operator precedence.

Semantic ambiguity: "The function should return the largest value." Largest by what metric? In what ordering? For floating-point numbers, what about NaN or signed zeros?

Pragmatic ambiguity: What is left unsaid. In a conversation between colleagues who have worked together for years, massive amounts of information are implied. New team members, or an AI trying to implement from a spec, have no access to that shared mental model.

Compare this to Python, often praised for readability:

def process_data(data: List[float]) -> Optional[float]:
    if not data:
        return None
    return max(data)

Even without types, the behavior is unambiguous to anyone who knows Python's semantics. max([]) raises an exception, but here we explicitly handle the empty case. The return type hint further constrains expectations.

English has no equivalent of type hints, no compiler to catch inconsistencies, no unit tests for prose.

Why We Put Up With It (And Why We Shouldn't)

English has undeniable strengths. It is expressive, flexible, and culturally rich. It can convey emotion, nuance, humor, and poetry in ways that formal languages cannot. Shakespeare didn't write in lambda calculus for a reason.

But when the goal is reliable transmission of executable ideas — specifications, APIs, requirements, designs — those strengths become liabilities. Flexibility is another word for underspecification.

Anyone with real experience communicating complex ideas knows the pattern:

Write what seems like a clear English description.
Send it to a colleague.
Receive back an implementation that is technically correct but completely misses the intent.
Spend hours in discussion clarifying what was "obviously" meant.
Repeat.

This is why mature software organizations invest heavily in:

Precise requirements documents with measurable acceptance criteria
Formal methods (where the cost justifies it — e.g., aerospace, finance, medical devices)
Contract testing, property-based testing, and exhaustive specification
Code as the single source of truth, with comments used sparingly

The very existence of these practices is an admission that English is inadequate.

In physics and mathematics, we don't tolerate "it's approximately true, in the usual sense." We define terms rigorously. We prove theorems. We build models whose predictions can be falsified experimentally. The precision of the language enables the precision of thought and the reliability of results.

Programming aspires to the same rigor. That's why we have static type systems, formal verification tools like Coq or Lean, and languages with strong guarantees (memory safety, data-race freedom, etc.).

English remains the worst because it resists all such discipline. It evolves organically, embraces exceptions, and thrives on interpretation. It is a living, messy, human thing — wonderful for literature, conversation, and persuasion; disastrous for programming.

A Humble Remark

We don't need to abandon English. We need to recognize its limitations and use better tools where precision matters.

Next time you write a technical specification, ask yourself: Could this be misinterpreted in a way that leads to incorrect behavior? If the answer is yes (and it almost always is), add precision — through examples, edge cases, invariants, or even pseudocode.

Treat English as a high-level, lossy compilation target rather than the final executable specification.

Because in the end, the computer doesn't care about your opinions, your intent, or what "everyone knows" you meant. It executes precisely what you told it — in a real programming language.

And humans, despite our intelligence, are not much better than computers when the specification is written in the worst programming language of all: English.

We just hide our bugs better, and argue about them longer.

DevLog 20260319: Metaprogramming (Teaser)

Charles Zhang — Thu, 19 Mar 2026 20:16:19 +0000

Quick Comment

Following Document-Level Main Module, the possibility really opens up...

This is very different from our earlier hard-coded "Stats" node.

DevLog 20260319: Towards OOP - Document-Level Default Module and Module-Level Members and Behaviors

Charles Zhang — Thu, 19 Mar 2026 20:16:08 +0000

Revisiting Flappy Bird – The Pain Point

Remember our Flappy Bird example from mid-2025?

The long chain of variable initializations was needed for two main reasons:

No way to declare variables before using them
More critically - no way to define custom data structures that could group related values together and be instantiated with a single node.

In retrospective it seems obvious: we just need proper structured data containers. But building the scaffolding to support this properly in a visual, node-based system is a bit more involved.

Searching for a Solution

I spent a long time trying to bring OOP concepts into Divooka. A huge amount of effort went into DiOS (Divooka Open Standards), with the hope that a complete standard would naturally solve these kinds of problems. But standardization work is slow and deep - just like making Divooka itself feature-complete.

Then, while working on something completely unrelated and taking a short break from this topic, it suddenly clicked.

The key insight: start simple and approach it from a functional/declarative angle first, before jumping into inheritance, encapsulation, polymorphism, and all those good stuff.

I'm really excited - we finally have meaningful progress.

The Divooka Way

To claim our goal as "everything is a node" is a bit too strong, but I strongly prefer keeping almost everything on the graph.

This aligns with how we already handle structured primitives - direct value setting of compound inputs. That way, there's still hope that users can drop down to raw node programming when they need full control (and thus keep everything programmable).

Traditional property panels (like Unreal Blueprints' object definition GUIs) are out - they break the pure graph paradigm.

Instead, the solution is declarative, similar to how TerraGen works: the mere presence and connection of certain nodes defines meaning.

This feels awesome for several reasons:

We can make full use of the 2D graph layout - place things exactly where we want them visually
It stays completely coherent with Divooka's graphical paradigm
No need for separate "class editor" UIs

What's Been Implemented So Far

Current working pieces:

Graphs can now act as modules
Support for module-level data members and behavior members
A main module tied to the document, with existing graphs serving as associated behaviors

Module-scoped instance node – in Events context

Module-scoped instance node – in Dataflow context

Top-level module behavior graphs

This immediately unlocks:

Clean access to (top-level) module instances
Shared event and dataflow instance data
A unified programming and document model for subgraphs (still a work-in-progress)
In procedural contexts (Glaze! especially): we now have proper data containers - no more awkward giant variable lists or forced tuples! (Compare to the old Flappy Bird screenshot)
Much simpler and more natural state storage/access in Glaze! and procedural graphs

This is a big deal - for a system that's gearing up for real production use, it feels like crossing a major milestone in usefulness and core abstractions.

Current Limitations & Remaining Work

Still plenty to fix/polish:

A bunch of bugs and edge cases
Proper serialization support
Smooth context switching between graphs
Subgraph consolidation / better nesting UX

Looking Ahead

This is a solid foundation, but there's still a long road:

Full modularization support
Modules inside modules (nesting)
Module inheritance / composition patterns / polymorphism
Base DOM exposed as the "main module" for metaprogramming API
Detailed documentation: how it all fits together, recommended usage patterns, expected behaviors, pitfalls
Module-level scoped instances (deeper/finer control)

Overall - I am very happy with the direction. It feels like Divooka is finally getting the abstraction power it deserves while staying true to its visual, graph-first philosophy.

I am hyped for what we will achieve.

References

A Detective Story: The Case of The Dead Office Guy (Upcoming Game Release)

Charles Zhang — Fri, 06 Mar 2026 19:29:11 +0000

Overview

In the quiet town of Baytown, an unremarkable man lies dead under suspicious circumstances. Rumors ripple through the streets. Secrets long buried begin to surface. The whole community is buzzing - some in dread, others gripped by dark fascination.

A Detective Story is a compact detective simulator that brings generative AI to the heart of interactive fiction.

Step into the role of detective in this small-scale murder investigation. Interrogate a cast of AI-powered townsfolk, each with their own motives, fragmented memories, and the potential to lie or mislead. Explore the map to uncover physical evidence and hidden clues. Piece it all together before time runs out.

Game Guide

Your mission: Solve the murder as efficiently as possible - minimize days elapsed and questions spent.
Bringing suspects to the station costs valuable time (days). Choose your interviews with care.
These are informal interrogations - no formal oaths, no truth serum. Witnesses and suspects may deceive, omit, or hide the truth.
You have only 3 questions per interview. Make every one count.
Stay in character for maximum immersion: Ask about alibis, relationships, timelines, strange sightings, and contradictions.
Cross-check stories, hunt inconsistencies, and link conversations to evidence found on the map.

Hardware Requirements

A Detective Story is lightweight and runs smoothly on modest hardware. It requires at least 10 GB of system RAM (DRAM) - with no heavy VRAM demands.

DevLog 20260225: Divooka Visual Programming - Direct Value Setting of Compound Inputs

Charles Zhang — Wed, 25 Feb 2026 17:46:45 +0000

Finally, it arrived! Well, not exactly here yet, but getting closer.

Overview

Divooka intends to make visual programming simple and accessible - the accessible part is achieved both through wide availability and the general-purpose nature of the programming system, but the simple part is what we spend lots of effort thinking hard trying to improve.

In the past, dealing with complex configuration takes the form of either "explosion" of arguments or dedicated Make XXX construction functions:

The problem arises due to the direct exposure of all input arguments in visual programming. Both approach makes the canvas look busy, with the former a common approach in existing systems - using a struct sounds good on paper but still requires a complex looking construction node. This is a common problem in visual programming systems, below shows how it's done in Blender and ComfyUI.

You do get used to it after a while, but a busy looking canvas remains a busy-looking canvas. In Blender, you can sort of "collapse" a node:

As Blender is constantly improving, we can also now collapse property groups as shown in the earlier screenshot.

As a syntax purist and (unfortunately) very conscious about my working space, my eyes can't tolerate messiness. I kind of like how Houdini approaches this.

Essentially they offload all the complexity to the properties panel - this has the huge benefit of making everything look very clean. But the downside is Houdini rely heavily on scripting expressions (like Excel).

TerraGen and World Machine mixes the approach:

In both cases, connections represent flow of terrain data only and additional configurations are offloaded to property panels. In TerraGen especially, this allows those properties to be animated. The downside, once again, is whatever is offloaded to property panels are no longer programmable using nodes.

Our Approach

Our proposed solution for Divooka looks like this: fundamentally all properties remain as node inputs, but compound values (especially value types) should just allow "editing in place" through a property panel. If more complex programming is needed, one can easily fall back to Make XXX nodes again.

Future Work

There is still remaining work on type check, hierarchical compound types, arrays, and serialization, and also node rendering.

Conclusion

As usual with all the exciting language features of Divooka we intend to introduce, there are lots of details to take care of here.

DevLog 20260224 Divooka - Node-Level Automatic Dispatch (Runtime Execution Behavior)

Charles Zhang — Tue, 24 Feb 2026 22:20:52 +0000

Overview

Anything useful done with a program eventually involves file I/O and some form of repetition.

In Divooka, the dataflow context already makes it very easy to "just get a single thing done." That part feels good. But handling loops? That's where things start to get awkward.

One challenge lies on the GUI side — especially around lambdas and subgraphs. We do have foundational support (as shown here and here), but let's be honest: it's not smooth yet.

So the question becomes: how do we make repetition feel natural without introducing heavy conceptual overhead?

The Plan

There are several well-established ways to achieve looping behavior in a functional or visual programming context:

Subgraph context - Used in tools like Blender, vvvv, and Houdini. A specialized node group or frame defines loop entry and exit boundaries.
Lambda callbacks - Evaluation is handled via callback-style execution.
Expressive recursion - As seen in text-based functional languages, requiring explicit termination conditions to avoid stack overflow.

All of these approaches are powerful and necessary in certain contexts. But they also introduce additional constructs into the language model. For advanced workflows, that's fine. For simple operations, it can feel unnecessarily complex.

I wanted something lighter.

Array Coercion

Divooka already supports Array Coercion — a scalar value can be passed into an input expecting a collection.

This avoids the need to manually "wrap" a scalar into an array just to satisfy a function signature - I still remember the pain of handling arrays in Unreal Blueprint.

Scalar-to-array coercion keeps graphs clean and avoids clustering.

To take this to the next level, I've been giving it much thought on how the reverse might work: if we can coerce scalars into arrays — what if we also let nodes automatically dispatch when arrays are passed in?

Automatic Dispatch (Node-Level)

The core design question was:

Should an array input implicitly turn the entire downstream chain into a loop?
Or should the dispatch behavior stay localized to the node itself?

Eventually it seemed localizing things to the node made far more sense.

For example:

string String.Replace(string, string, string)

If any input is provided as an array instead of a scalar, the node automatically promotes itself to:

string[] String.Replace(string[], string[], string[])

The node executes element-wise.

Now, I can rename a folder of files with roughly three nodes:

Enumerate files
Regex replace
Rename file

No explicit loop node. No subgraph. No lambdas.

In this example, Duplicate as Array returns a strongly typed string[], enabled by generics support.

One important rule: All array inputs must align in size with the source array. The dispatch is index-based and deterministic.

Full Example

What used to require explicit iteration logic now becomes implicit behavior at the node boundary. The graph remains readable. The mental model stays simple.

Conclusion

This is still early work. Integration with the rest of Divooka's features is ongoing, and edge cases are being worked through.

So far so good.

Weekly Update 2026-01-11

Charles Zhang — Mon, 12 Jan 2026 01:29:00 +0000

This week was mostly about tightening up the foundations of our tools rather than pushing new features. A lot of our older experiments were starting to show their age, so we spent time cleaning things up and getting the core systems into better shape.

What Happened This Week

Refactoring Neo + Parcel NExT review

We continued working through refactors on Neo and reviewing the Parcel NExT implementation. Some of the earlier experimental frontend work had spread across multiple assemblies, so small API changes ripple everywhere. Slow, but necessary.

WPF + Nodify wrestling

A surprising amount of time went into understanding how WPF resource dictionaries, theming, and Nodify's API actually want to behave together. After digging through the quirks, we finally have a clearer picture of how to keep styling and view models consistent. Didn't get as far into custom styling as we hoped, but at least the fundamentals are sorted out.

Serialization groundwork

Started wiring up the basics for text-based JSON serialization of Divooka graphs/documents. Also began work on package reference records and figuring out how packages get identified and loaded at runtime. All early steps, but important ones.

Graph editor + GUI cleanup

Made some initial passes at reorganizing the graph editor. Small changes now, but they'll help us build better tools on top later.

Fantasy Planet Painter update

Spent a little time polishing and updating the Steam submission for Fantasy Planet Painter.

Methodox Threads

We also pushed out an early public release of Methodox Threads, our lightweight branching text environment for managing non-linear AI conversations. The new v0.7 build adds integrated Gen-AI generation directly inside each document pane, configurable providers, and a simple JSON-backed structure for exporting or versioning thought trees. It's essentially a cleaner way to explore tangents, run parallel prompts, and keep complex LLM work organized. Download is available on itch.io.

Closing Thoughts

Not a "big features" week, but a surprisingly productive one in terms of future stability. Refactors aren't glamorous, but they make everything that comes next a lot smoother.

Release Note: Methodox Threads (v0.7)

Charles Zhang — Mon, 12 Jan 2026 01:14:34 +0000

Overview

Version 0.7 introduces full Gen-AI generation capabilities, including per-document prompt-driven content generation, provider configuration, OpenAI integration, and asynchronous multi-editor execution with UI-level busy indicators. This release establishes the foundation for a extendable, multi-provider LLM workflow while maintaining the existing document layout and editing model.

New Features in v0.7

Configurable AI Provider Framework

A new Configure… dialog provides a unified interface for system-level and provider-specific settings:

System Tab

Edit the global System Prompt used for all generations.

OpenAI Tab

API key (masked)
Optional custom endpoint
Preset model list:
- gpt-4o-mini
- gpt-4o
- o3-mini
- Other → reveals a custom model name field
Support for model overrides when presets become outdated
Automatic load/save of configuration in a user-specific app directory

Additional provider tabs (Gemini, DeepSeek, Ollama, Grok) are included as placeholders for future integrations.

Gen-AI Generation Workflow

Each document now supports prompt-based content generation:

Users set a Prompt on any document.
Selecting Edit → Generate triggers generation for the focused document.
Generation uses:
- Global System Prompt
- Document Prompt

Per-Editor Async Generation

Each document editor generates independently in parallel.
Editors become temporarily read-only during generation.
A semi-transparent overlay displays Generating… with an indeterminate progress bar.
Sibling/Child creation buttons remain active.
Generated text is written directly into the document’s Content field.

OpenAI Integration (First Provider Implementation)

A new abstraction layer encapsulates provider calls.
Version 0.7 includes the first concrete backend:

OpenAI Chat Completion Backend

Uses the official OpenAI SDK.
Supports both default and custom endpoints.
Converts internal document structures into Chat API messages.
Returns full assistant text as document content.

This abstraction enables drop-in integration of additional providers in future versions.

Configuration Persistence

All provider and system settings are automatically stored as JSON in the user-local app directory:

Loaded when opening the Configure dialog
Saved on dialog close
Ensures persistent environment across editor sessions

Limitations

No document deletion or rearrangement
Markdown preview remains basic
Only OpenAI is implemented; other providers are placeholders
Generation does not yet stream partial output

References

Introducing Methodox Threads: Tame the Chaos of Branching AI Conversations

Charles Zhang — Mon, 12 Jan 2026 01:13:12 +0000

Tired of losing brilliant tangents in endless LLM chats?
Frustrated when editing a prompt wipes out your entire history, or when long threads become impossible to navigate?

You're not alone. Every generative AI user - from casual brainstormers to researchers, writers, and prompt engineers - hits the same wall:

Linear chat interfaces simply weren't built for nonlinear thinking.

That's why we built Methodox Threads.

Threads is a linear-yet-branching text environment crafted for managing complex ideas and AI conversations - especially those that naturally fork into tangents, nested explorations, and parallel paths.

And with the new v0.7 release, Threads becomes more than an organizational tool. It a generative workspace for chat management.

Core Experience at a Glance

Multi-pane, tree-like layout Each document lives in its own dedicated, scrollable editor. The whole structure remains visible, so you can see the big picture while diving deep into any branch.
Natural branching From any node, spawn siblings (parallel directions) or children (deeper explorations). Build clear, persistent hierarchies without losing context.
Integrated Gen-AI generation (new in v0.7!) Add a Prompt to any document and generate AI-assisted content directly into that pane. Includes:
- Per-document generation
- Parallel, asynchronous execution
- Read-only “Generating…” overlay during output
- Global system prompt
- Configurable AI providers (OpenAI available now; Gemini, DeepSeek, Ollama, Grok coming soon)
- Custom API endpoints and custom model names
- Secure, auto-saved per-user configuration Your entire AI workflow now runs inside the branching editor itself.
Iteration-friendly writing environment Full Markdown editing, inline notes, JSON/Markdown export, and a distraction-free dark UI. Refine AI outputs, rewrite prompts, annotate ideas - without ever resetting a thread.
Portable & future-proof A clean JSON structure under the hood, with markdown Gen-AI folder import/export support for v0.6+ projects. Version-control your thought trees with ease.

Threads lets you shape AI conversations the way your mind naturally works: branching, revisiting, exploring alternatives, and layering insights - all without friction.
Picture exploring what-ifs in a worldbuilding document, generating multiple stylistic takes side-by-side, or running parallel reasoning chains for research - all visible at once, never buried in scrollback.

For a deeper dive into the design motivations and architecture, check out our dev log “Motivations for Methodox Threads”.

Get Started

Threads is available now as an early public release from Methodox Technologies.
Download it today and start turning chaotic AI interactions into structured, generative thought trees.

→ https://methodox.itch.io/threads
→ Follow @methodox for updates, tips, and early access to upcoming provider integrations, streaming AI output, and full multi-model workflows.

Introducing Methodox Threads: Tame the Chaos of Branching AI Conversations

Charles Zhang — Mon, 12 Jan 2026 01:13:12 +0000

Tired of losing brilliant tangents in endless LLM chats?
Frustrated when editing a prompt wipes out your entire history, or when long threads become impossible to navigate?

You're not alone. Every generative AI user - from casual brainstormers to researchers, writers, and prompt engineers - hits the same wall:

Linear chat interfaces simply weren't built for nonlinear thinking.

That's why we built Methodox Threads.

And with the new v0.7 release, Threads becomes more than an organizational tool. It a generative workspace for chat management.

Core Experience at a Glance

Multi-pane, tree-like layout Each document lives in its own dedicated, scrollable editor. The whole structure remains visible, so you can see the big picture while diving deep into any branch.
Natural branching From any node, spawn siblings (parallel directions) or children (deeper explorations). Build clear, persistent hierarchies without losing context.
Integrated Gen-AI generation (new in v0.7!) Add a Prompt to any document and generate AI-assisted content directly into that pane. Includes:
- Per-document generation
- Parallel, asynchronous execution
- Read-only “Generating…” overlay during output
- Global system prompt
- Configurable AI providers (OpenAI available now; Gemini, DeepSeek, Ollama, Grok coming soon)
- Custom API endpoints and custom model names
- Secure, auto-saved per-user configuration Your entire AI workflow now runs inside the branching editor itself.
Iteration-friendly writing environment Full Markdown editing, inline notes, JSON/Markdown export, and a distraction-free dark UI. Refine AI outputs, rewrite prompts, annotate ideas - without ever resetting a thread.
Portable & future-proof A clean JSON structure under the hood, with markdown Gen-AI folder import/export support for v0.6+ projects. Version-control your thought trees with ease.

For a deeper dive into the design motivations and architecture, check out our dev log “Motivations for Methodox Threads”.

Get Started

Threads is available now as an early public release from Methodox Technologies.
Download it today and start turning chaotic AI interactions into structured, generative thought trees.

→ https://methodox.itch.io/threads
→ Follow @methodox for updates, tips, and early access to upcoming provider integrations, streaming AI output, and full multi-model workflows.

DevLog 20260110: Motivations for Methodox Threads - A Conversation Management Tool

Charles Zhang — Sat, 10 Jan 2026 20:02:39 +0000

Hey folks, Charles here from Methodox. As a developer deeply embedded in the generative AI space, I've spent the last couple of years wrestling with the limitations of LLM interfaces. Today, I want to dive into the motivations behind our latest project, Methodox Threads - a linear, branching text environment built to tame the chaos of long, tangled conversations. This isn't just another note-taking app; it's a structured canvas designed for iterative thinking, especially when collaborating with AI models. I'll keep this log developer-focused, touching on the architecture and implementation choices, while highlighting why this solves a universal pain point for anyone using gen AI tools.

The Problem: Chaos in Conversation Management

If you've ever dived deep into a conversation with an LLM like Grok, ChatGPT, or Gemini, you know the drill: things start linear, but soon you're branching into tangents, exploring "what-ifs," and iterating on ideas. The trouble? Existing interfaces suck at handling this complexity.

OpenAI's ChatGPT: They pioneered branching, which is a step up, but in long threads, navigation becomes a nightmare. Scrolling through endless history to find that one pivotal response? Forget it - context gets buried, and resuming a branch feels like archaeology.
Grok (xAI): The side navigation pane is a nice idea on paper, but in practice, it falls flat for multi-branching. Creating parallel explorations requires awkward workarounds, and the UI doesn't scale for deep hierarchies.
Gemini (Google): Editing a prompt erases the previous version entirely - no versioning, no undo. It's like the tool assumes your first draft is always perfect, which is laughable for creative or analytical work.

Worse still, none of these platforms let you edit the AI's responses natively. For developers doing prompt engineering or users in creative writing, this is a deal-breaker. You spot an inconsistency or want to tweak for better flow? You're stuck regenerating from scratch, praying the model stays consistent (spoiler: it often doesn't). OpenAI's Canvas tries to address iterative editing, but it's hampered by the underlying AI's memory lapses and lack of true state management.

This isn't just a dev gripe - it's a widespread issue. Casual users brainstorming ideas, researchers tracking hypotheses, or writers building narratives all hit the same wall: conversations sprawl, branches get lost, and productivity tanks. In a world where gen AI is democratizing creativity, we need tools that empower structured exploration without the friction.

My Journey: From Hacks to a Dedicated Tool

I've been hacking at this problem since the early days of gen AI. Inspired by tools like Kobold AI (which excels at local, scriptable story generation), I started building lightweight local management systems. Early prototypes used simple folder structures to mimic threads - each "branch" as a subfolder with text files for prompts and responses. Others adopted custom JSON formats for serialization, allowing easy versioning via Git.

These worked okay for personal use but lacked visual intuition. Exporting/importing conversations was manual, and scaling to nested tangents felt clunky. That's how I conceived Methodox Threads: born from my startup's focus on AI-enhanced workflows, it's a purpose-built app that evolves these ideas into a robust, user-friendly system.

From a dev perspective, Threads is architected around a tree-like data model (think hierarchical nodes in a graph database, but lightweight and in-memory for speed). Each node represents a thread segment:

Core Structure: A root document spawns children (nested explorations) and siblings (parallel branches). This is implemented with a recursive node class in our backend (built on Avalonia for cross-platform desktop use), easily exportable to JSON format.
UI Layout: Multi-pane editors, each fully scrollable and synchronized. We use a canvas-based layout with customizable pane width and height and automatic height adjustments for children documents - useful when dealing with deep hierarchies of varying complexities.
Features for Iteration:
- Markdown support via a lightweight parser (no rendered preview at this moment, but syntax highlighting is a work in progress).
- Document-wise notes and project README for meta-commentary (e.g., "This branch assumes v2 prompt").
- Project serialization to JSON or export to Markdown in folders, making it Git-friendly for version control.
Distraction-Free Design: No bloat - just a clean canvas. You can create branches either from the menu or through the hover buttons; In the future we may provide keyboard shortcuts for branching (e.g., Ctrl+B for new sibling) and drag-and-drop reorganization, drawing from IDEs like VS Code.

The goal is to enable deep dives without losing the forest for the threads. For general users, this means organizing a chatbot session on "world-building for a sci-fi novel" into branches like "Character Arcs," "Plot Twists," and "World Lore" - all visible at a glance. For devs, it's a playground for prompt chaining, where you can fork a thread to test API variations without derailing the main flow.

Why Build This?

At its core, Threads addresses the cognitive load of unstructured AI interactions. Gen AI users - whether hobbyists or pros - crave persistence and flexibility. Developers like us need it for debugging prompts, prototyping agents, or managing multi-model experiments (e.g., comparing Grok vs. GPT outputs side-by-side). The general public benefits from a tool that makes AI feel less like a black box and more like a collaborative partner, especially in fields like research, writing, or ideation.

We're charging a very small courtesy cost to support the continued development of this tool, since developing such an interface is easy for anyone with GUI dev experience - but continuously improving it is what makes it truly usable.

Future Plans: From Manual to Seamless AI Integration

Right now, Threads is a powerhouse multi-pane text editor, but populating it requires manual copy-pasting from your LLM of choice. That's fine for bootstrapping, but we're gearing up for true integration.

API Endpoints First: We'll start with the OpenAI API, allowing users to "continue" a thread by sending the full branch context plus a system prompt. Imagine right-clicking a node and selecting "Query GPT" - it appends the response as a child node, preserving history.
Prompt Engineering Tools: Built-in templating for system prompts.
Multi-Model Support: Expand to Grok, Gemini, and local models via Ollama. Devs can plug in custom endpoints.
Version Control Friendly Exports: Exporting to scattered Markdown files is very useful since internally many older conversations were archived this way and it looks nicer on Git diff than JSON.
AI-Assisted Structuring: Use lightweight ML to suggest branches or summarize threads (like how Grok works).

We're iterating fast so file formats and exact usage pattern may change, and will spend more time on this if receive plenty user interest. If you're a dev interested in sharing ideas or a user with feedback, hit us up at Methodox (contact@methodox.io). Stay tuned for more updates!

Let's make AI conversations manageable for everyone.