# Mythos for coding > Source: > Published: 2026-06-21 06:56:22+00:00 I am using Claude Mythos from Anthropic to extend my [Fortran to C transpiler](https://github.com/Beliavsky/Fortran-to-C), created using OpenAI Codex 5.5, to a transpiler from Fortran to C and C++ (they are separate transpilers with some shared code – will post when ready). Codex 5.5 is excellent. Typically I give it a task that takes a few minutes to tens of minutes and iterate. Mythos can work in larger chunks. (Codex has /goal mode , which may do the same thing and which I should try.) I asked it to fix the transpilers so they can handle all the code in my [GARCH and intraday realized volatility project](https://github.com/beliavsky/garch-bfgs). It worked for 2.5 hours and gave the message below. We are at the point where LLMs can write many programs for you, including transpilers between programming languages. Before Mythos I found Codex to be superior to Claude for coding. Now I am unsure. ● Here’s where the GARCH-BFGS sweep stands. Setup I wrote c:\fortran\GARCH-BFGS\xf2c_make_test.py (alongside your existing helpers): it parses the Makefile’s 86 .exe targets in order, finds each target’s main program (the dependency containing a program statement — garch.exe → garch_main.f90, not the garch.f90 module), generates a combined source with your xfind_make_targets.py –single-source, and runs xf2c.py _single.f90 --run-both, stopping at the first failure. It supports --start N, –limit N, --keep-going, and --timeout, and cleans up generated files on each pass. Result: targets 1–44 now PASS; first remaining failure is #45 Each stop along the way was a genuine transpiler bug, which I fixed and verified (the full pytest suite — 301 passed, 20 xfailed — is green after all changes). The 14 fixes, in sweep order: - minloc([rank_n, rank_t, …], 1) — min/maxloc over array constructors of scalars (xgarch_dist). - if (cond) then; stmt — same-line block-if statements were mangled into nested ifs by _rewrite_inline_if_write (xgarch_choose_dist). - logical :: sim_on(0:6) = .false. — scalar initializer broadcast on array declarations checked the raw Fortran text for zero-ness instead of the converted value. - sim_on([dist_normal, dist_t]) = .true. — vector-subscript assignment ignored non-1 lower bounds and leaked the raw logical type name into C. - acc%omega = 0.0 — scalar broadcast to fixed-size derived-type member arrays (only allocatable fields were handled). - norm2(g(1:3)) — norm2 over sections (whole arrays only before). - log2 as a module parameter — module-level use …, only: imports never reached contained procedures, so reserved-name renaming missed use sites (xgarch_flex). - “par3 = theta (…” — the call-name scanner read string literals, registered a phantom theta() call, and deleted the real variable (xfit_spy). - gas_proc_names => proc_names with two modules exporting proc_names — module variables now get collision-qualified C globals (gas_mod__proc_names) via a new Var.c_alias, and => renames map through it (xgarch_gas). - Continued use statements (…, dist_laplace, & on the next line) — the host-module import scan now joins & continuations. - call f(x(2), n) — Fortran sequence association: array-element actuals to array dummies now pass the element’s address (xstgarch). - ret_all(:,icol) / z_all(icol, as array actuals — contiguous column sections pass &a[offset]; strided row sections materialize a temp (xdcc, xfit_dist_returns). - col_names(icol)(1:8) — substrings of character array elements; and rows(i)%model = s — fixed-length char fields of subscripted derived elements (xfit_gen_egarch_returns). - valid(x) vs a dummy named valid elsewhere — function references now rename to their qualified C names; first attempt broke 8 tests by keyword-sanitizing for(/if(, fixed by restricting to explicit registry hits (xfit_gen_garch_iv_returns). Where it stopped: #45 xfit_garch_ohlc_iv_returns.exe Two diagnosed issues remain there: (a) host-program globals like char failed_symbols[n_model][257] are emitted at file scope referencing program parameters that aren’t emitted as globals (ordering/param-inlining problem in the host-global emission — I fixed the related file-scope init-statement bug already), and (b) one more call path passes a derived-type pointer dummy to a by-value struct parameter without dereferencing (my _pass_value_actual_expr fix covered the common path; this caller takes a different route). Both are diagnosed in the memory notes; say the word and I’ll continue from python xf2c_make_test.py --start 45. ✻ Baked for 2h 31m 31s ※ recap: Testing the C transpiler on all 86 GARCH-BFGS Makefile programs, fixing transpiler bugs at each failure; targets 1-44 now pass after 14 fixes. Next: resume the sweep at target 45, which has two diagnosed remaining issues. 2 Likes Given that many requests already are given in natural spoken languages it seems the time is nearing when many problems may go from natual languages to machine code, with perhaps an ability to write instructions in a high-level computer language to allow for human review. Given that choice I would want the code displayed in Fortran or Rust. So where in the past I have been interested in conversions and interfaces between languages I am expecting boutique languages to start disappearing relatively quickly myself, and that transpilers as you describe here will eliminate a lot of higher-level languages before perhaps we lose the need for keyboards. 1 Like [septc](https://fortran-lang.discourse.group/u/septc) 4 I started subscribing to Claude Pro a few days ago (around June 10th), and was able to try Fable 5 just once (with a very trivial question!). Yesterday, I got an email from Anthropic that “Fable has been suspended due to Governmental order (or something like that)”, so I cannot try Fable anymore… I should have asked a bit more difficult questions at that time 1 Like Fable 5 was available on the $20/month plan, but even before it was blocked Anthropic had said it would only be available through the API starting Jun 22. It would not be affordable by individuals, based on cost estimates I got: Session Total cost: $1311.74 Total duration (API): 11h 15m 17s Total duration (wall): 5d 3h 52m Total code changes: 8839 lines added, 807 lines removed Usage by model: claude-haiku-4-5: 999 input, 19 output, 0 cache read, 0 cache write ($0.0011) claude-fable-5: 97.6k input, 1.3m output, 1.1b cache read, 5.8m cache write (**$1267.13**) claude-sonnet-4-6: 6.6k input, 568.3k output, 97.7m cache read, 1.8m cache write ($44.61) 1 Like [septc](https://fortran-lang.discourse.group/u/septc) 6 Thanks very much for your info! In my case, I wanted to first experiment Fable with some math problems of my interest that I often ask to different LLMs and see the difference of their replies. I will try it later once Fable becomes available again. Regarding coding assistance, yes, I read some article that the API cost is very high, so I am afraid I cannot afford that… FYI, I got to know that some student in my university has been trying to “port” old Fortran77 codes to Python using Claude Code, but it seems “Pro” is not at all sufficient for this purpose (because of the usage / token limitation or something like that). I have little experience with Claude, so will experiment more later (maybe in July).