HackerTrans
TopNewTrendsCommentsPastAskShowJobs

codingmoh

no profile record

Submissions

Show HN: Made a little Artemis II tracker

artemis-ii-tracker.com
154 points·by codingmoh·3 माह पहले·61 comments

Serving 100s of LLMs on 1 GPU with LoRAX [video]

youtube.com
2 points·by codingmoh·पिछला वर्ष·0 comments

AI-assisted coding for teams that can't get away with vibes

blog.nilenso.com
3 points·by codingmoh·पिछला वर्ष·0 comments

Show HN: An AI tutors that teaches AI

vivaverbalis.com
5 points·by codingmoh·पिछला वर्ष·2 comments

Fame and Frustration on the New Media Circuit

vulture.com
1 points·by codingmoh·पिछला वर्ष·0 comments

You are the heir to something greater than Empire

noahpinion.blog
6 points·by codingmoh·पिछला वर्ष·1 comments

Nutrition Beliefs Are Just-So Stories

cremieux.xyz
4 points·by codingmoh·पिछला वर्ष·0 comments

[untitled]

2 points·by codingmoh·पिछला वर्ष·0 comments

Show HN: Open Codex – OpenAI Codex CLI with open-source LLMs

github.com
106 points·by codingmoh·पिछला वर्ष·37 comments

Ask HN: Why don't we have a functional DSL for data+embedding+API pipelines?

21 points·by codingmoh·पिछला वर्ष·21 comments

Ask HN: My recent Show HN post is not becoming visible, why?

1 points·by codingmoh·पिछला वर्ष·4 comments

Show HN: Use Natural Language to Run Terminal Commands (Ghost in the Shell)

github.com
6 points·by codingmoh·पिछला वर्ष·4 comments

Show HN: Built a Simple AI Code Reviewer in 3 Hours

ai-code-reviewer.replit.app
1 points·by codingmoh·2 वर्ष पहले·0 comments

comments

codingmoh
·3 माह पहले·discuss
thank you, I'll consider that
codingmoh
·3 माह पहले·discuss
Okay, sorry, I meant to make to emulate physical monitor
codingmoh
·3 माह पहले·discuss
I did not use claude code, but codex, and I am fetching space weather from NOAA SWPc, trajectory, distance, speed, and comms delay are computed from NASA's published Artemis II mission plan parameters, not pulled live from NASA telemetry. Also, the current discrepancy is likely caused by the orbital phase and reference model being used. tracker shows about 192,000 km, while NASA's AROW shows about 80,000 miles, which is roughly 129,000 km. it is off by around 60,000 km. difference can happen because the spacecraft is in a elliptical orbit and different trackers may be using different assumptions, interpolation methods,... or reference points for the trajectory
codingmoh
·3 माह पहले·discuss
Hey, I've responded before, I need to update the visualization: Iam fetching space weather from NOAA SWPC.

Trajectory, distance, speed, and comms delay are computed from NASA's published Artemis II mission plan parameters, not pulled live from NASA telemetry.

Also, the current discrepancy is likely caused by the orbital phase and reference model being used.

Right now the tracker shows about 192,000 km, while NASA's AROW shows about 80,000 miles, which is roughly 129,000 km. So yes, that is off by around 60,000 km. Difference can happen because the spacecraft is in a elliptical orbit and different trackers may be using different assumptions, interpolation methods,... or reference points for the trajectory.
codingmoh
·3 माह पहले·discuss
I am fetching space weather from NOAA SWPC.

Trajectory, distance, speed, and comms delay are computed from NASA’s published Artemis II mission plan parameters, not pulled live from NASA telemetry.

Also, the current discrepancy is likely caused by the orbital phase and reference model being used. Right now the tracker shows about 192,000 km, while NASA’s AROW shows about 80,000 miles, which is roughly 129,000 km. So yes, that is off by around 60,000 km.

difference can happen because the spacecraft is in a elliptical orbit and different trackers may be using different assumptions, interpolation methods, .. or reference points for the trajectory.
codingmoh
·पिछला वर्ष·discuss
oh wow - that's cool! - Thanks so much for sharing!
codingmoh
·पिछला वर्ष·discuss
In theory, it seemed perfect for flexible manufacturing: same machine, same material, endless outputs. But in practice, it hit limits in speed, material properties, and post-processing. You still can’t print a high-tolerance metal part at scale and cost-effectively replace traditional machining. It’s amazing for prototyping or niche parts
codingmoh
·पिछला वर्ष·discuss
Thanks, I'll have a look
codingmoh
·पिछला वर्ष·discuss
Hey, that is a very good question, I have answered that before. I hope you don't mind, if I simply copy paste my previous answer:

Technically you can use the original Codex CLI with a local LLM - if your inference provider implements the OpenAI Chat Completions API, with function calling, etc. included.

But based on what I had in mind - the idea that small models can be really useful if optimized for very specific use cases - I figured the current architecture of Codex CLI wasn't the best fit for that. So instead of forking it, I started from scratch.

Here's the rough thinking behind it:

   1. You still have to manually set up and run your own inference server (e.g., with ollama, lmstudio, vllm, etc.).
   2. You need to ensure that the model you choose works well with Codex's pre-defined prompt setup and configuration.
   3. Prompting patterns for small open-source models (like phi-4-mini) often need to be very different - they don't generalize as well.
   4. The function calling format (or structured output) might not even be supported by your local inference provider.
Codex CLI's implementation and prompts seem tailored for a specific class of hosted, large-scale models (e.g. GPT, Gemini, Grok). But if you want to get good results with small, local models, everything - prompting, reasoning chains, output structure - often needs to be different. So I built this with a few assumptions in mind:

   - Write the tool specifically to run _locally_ out of the box, no inference API server required.
   - Use model directly (currently for phi-4-mini via llama-cpp-python).
   - Optimize the prompt and execution logic _per model_ to get the best performance.
Instead of forcing small models into a system meant for large, general-purpose APIs, I wanted to explore a local-first, model-specific alternative that's easy to install and extend — and free to run.
codingmoh
·पिछला वर्ष·discuss
Thanks for bringing that up - it's exactly why I approached it this way from the start.

Technically you can use the original Codex CLI with a local LLM - if your inference provider implements the OpenAI Chat Completions API, with function calling, etc. included.

But based on what I had in mind - the idea that small models can be really useful if optimized for very specific use cases - I figured the current architecture of Codex CLI wasn't the best fit for that. So instead of forking it, I started from scratch.

Here's the rough thinking behind it:

   1. You still have to manually set up and run your own inference server (e.g., with ollama, lmstudio, vllm, etc.).
   2. You need to ensure that the model you choose works well with Codex's pre-defined prompt setup and configuration.
   3. Prompting patterns for small open-source models (like phi-4-mini) often need to be very different - they don't generalize as well.
   4. The function calling format (or structured output) might not even be supported by your local inference provider.
Codex CLI's implementation and prompts seem tailored for a specific class of hosted, large-scale models (e.g. GPT, Gemini, Grok). But if you want to get good results with small, local models, everything - prompting, reasoning chains, output structure - often needs to be different.

So I built this with a few assumptions in mind:

   - Write the tool specifically to run _locally_ out of the box, no inference API server required.
   - Use model directly (currently for phi-4-mini via llama-cpp-python).
   - Optimize the prompt and execution logic _per model_ to get the best performance.
Instead of forcing small models into a system meant for large, general-purpose APIs, I wanted to explore a local-first, model-specific alternative that's easy to install and extend — and free to run.
codingmoh
·पिछला वर्ष·discuss
Thank you so much!
codingmoh
·पिछला वर्ष·discuss
I want to add support for qwen 2.5 next
codingmoh
·पिछला वर्ष·discuss
Thanks so much!

Was the model too big to run locally?

That’s one of the reasons I went with phi-4-mini - surprisingly high quality for its size and speed. It handled multi-step reasoning, math, structured data extraction, and code pretty well, all on modest hardware. Phi-1.5 / Phi-2 (quantized versions) also run on raspberry pi as others have demonstrated.
codingmoh
·पिछला वर्ष·discuss
Hey, this is really cool! Curious how good the multi-language support is. Also - pretty wild that you trained the whole thing yourselves, especially without prior experience in speech models.

Might actually be helpful for others if you ever feel like documenting how you got started and what the process looked like. I’ve never worked with TTS models myself, and honestly wouldn’t know where to begin. Either way, awesome work. Big respect.
codingmoh
·पिछला वर्ष·discuss
I saw pretty good reasoning quality with phi-4-mini. But alright - I’ll still run some tests with qwen2.5-coder and plan to add support for it next. Would be great to compare them side by side in practical shell tasks. Thanks so much for the pointer!
codingmoh
·पिछला वर्ष·discuss
fair jab - haha; if we’re gonna go small, might as well go fully local and open. At least with phi-4-mini you don’t need an API key, and you can tweak/replace the model easily
codingmoh
·पिछला वर्ष·discuss
I went with Phi as the default model because, after some testing, I was honestly surprised by how high the quality was relative to its size and speed. The responses felt better in some reasoning tasks-but were running on way less hardware.

What really convinced me, though, was the focus on the kinds of tasks I actually care about: multi-step reasoning, math, structured data extraction, and code understanding.There’s a great Microsoft paper on this: "Textbooks Are All You Need" and solid follow-ups with Phi‑2 and Phi‑3.
codingmoh
·पिछला वर्ष·discuss
I know exactly what you mean—it’s the same cycle I’ve seen in countless projects, with every project spiraling into a brittle pipeline that’s hard to maintain. Despite all the promising ideas, we never seem to nail down a universal solution that’s both simple and robust. - There must be a way, and sooner or later it will be figured out.
codingmoh
·पिछला वर्ष·discuss
Yeah, I agree. DSLs tend to become a maintenance burden over time! transducers let you compose data transformations independently of the data source (in-memory, async, etc.), which sidesteps a lot of the pitfalls that a full DSL might introduce. Thanks so much for highlighting this!
codingmoh
·पिछला वर्ष·discuss
No, I haven’t looked into Snakemake or Nextflow yet, but they seem intriguing -amazing, thanks for the suggestion!